What sort of best practices coding do you use?
-
I would agree most places don't have best practices. Only one place I've worked at actually does code reviews and that was because they were using the agile programming methodology. It would be nice to work at a place that actually does code reviews because I think it would make people think twice before putting in kludges or failing to comment complicated sections.
Dustin Metzgar wrote:
or failing to comment complicated sections.
How about failing to comment any sections? I've been unfortunate enough to have to maintain such code.:mad: The code I'm maintaining now also has next to no comments.:mad:
Kevin
-
We're a C++ shop, mostly doing non-UI stuff. We tend to work to Herb Sutter and Alexei Alexandrescus C++ Coding Standards[^]. They are enforced through code review. I think we're the exception rather than the rule - and that's because we're an adjunct to a safety critical software team that works to DO178B level A, so has very stringent standards (we code safety-critical stuff with SPARK Ada[^]).
A quick look at the site - I see you have some Design by Contract stuff in there.:) I wish C#, C++ etc. could have such things - properly integrated. Maybe some of that Spec# stuff will get rolled into C# some time soon?
Kevin
-
A quick look at the site - I see you have some Design by Contract stuff in there.:) I wish C#, C++ etc. could have such things - properly integrated. Maybe some of that Spec# stuff will get rolled into C# some time soon?
Kevin
Kevin McFarlane wrote:
I see you have some Design by Contract stuff in there
SPARK actually goes further than that - suitably annotated, it can prove things like absence of run-time exceptions for integer-based arithmetic (that's integers and fixed-point numbers). It's being used more and more in security related software, because there's a formal, provable semantics for the language...assuming the compiler and processor don'r screw up, of course :)
-
Kevin McFarlane wrote:
I see you have some Design by Contract stuff in there
SPARK actually goes further than that - suitably annotated, it can prove things like absence of run-time exceptions for integer-based arithmetic (that's integers and fixed-point numbers). It's being used more and more in security related software, because there's a formal, provable semantics for the language...assuming the compiler and processor don'r screw up, of course :)
I think Spec# has a bit more stuff than DbC too. Not sure how it would compare to SPARK. Anyway, why do you think most of the newer languages did not bother to integrate DbC? Seems like such a good idea to adopt.
Kevin
-
Do you/your company enforce best practices? Do you do code reviews to enforce them, or use FxCop or other automated means? If you don't adhere to any best practice document/utility, why not? Would you agree or disagree that most of us don't use coding best practices? Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithWe don't have a formal standard, but we do use PC-Lint extensively (funny, that!). To support that, we use books such as "Effective C++", "More Effective C++", "Imperfect C++" etc. pretty heavily. As a micro-ISV we're pragmatic about it: if anyone points out what they think is a bad practice in our code, we look into it and refactor it if appropriate. In the long term such changes can add-up to significant improvements. I find much of it is common sense, once you have a source that discusses relevant issues. Of course, for a larger team a more formalised approach may be better, but I've yet to see a team that does it well without descending into "my way is best" politics.
Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
I think Spec# has a bit more stuff than DbC too. Not sure how it would compare to SPARK. Anyway, why do you think most of the newer languages did not bother to integrate DbC? Seems like such a good idea to adopt.
Kevin
-
Do you/your company enforce best practices? Do you do code reviews to enforce them, or use FxCop or other automated means? If you don't adhere to any best practice document/utility, why not? Would you agree or disagree that most of us don't use coding best practices? Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithI like Guidance Explorer, MSDN & I need to check if the latest FxCop passes its own tests
_________________________________________ Give a man a fish you've fed him for a day. Teach a man to fish and you've fed him for life."... I guess I should write an article rather than giving out tips.
-
Do you/your company enforce best practices? Do you do code reviews to enforce them, or use FxCop or other automated means? If you don't adhere to any best practice document/utility, why not? Would you agree or disagree that most of us don't use coding best practices? Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithWe tries to adhere to the recommendations in "Code Complete", except for comments below module level -- They are traded for "Self Documenting Code"... Jupp, sometimes you get rather cumbersome names ( = refactoring time).
-
Dustin Metzgar wrote:
or failing to comment complicated sections.
How about failing to comment any sections? I've been unfortunate enough to have to maintain such code.:mad: The code I'm maintaining now also has next to no comments.:mad:
Kevin
I used to place inline comments, but I stopped doing so, simply because if something isn't able to be understood by reading the variable/method names and summary, examples, params, exceptions, etc in the class/method header documentation (C# shop here), then I refactor it until it is simple to understand... What's the saying...if debugging is twice as hard as coding, then by definition if your code is as clever as you can write it, you will not be able to debug it. Did I mention that GhostDoc is a god-send? :)
-
Do you/your company enforce best practices? Do you do code reviews to enforce them, or use FxCop or other automated means? If you don't adhere to any best practice document/utility, why not? Would you agree or disagree that most of us don't use coding best practices? Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithOn our shared source repo we are Nazis and you had better be sure what you check-in is at least as good as the crap of the Gods. Otherwise we rely more on testing and informal, periodic code reviews. We do have Fxcop equivalents but they won't break the build.
regards, Paul Watson Ireland FeedHenry needs you
eh, stop bugging me about it, give it a couple of days, see what happens.
-
I really hate this fucking keyboard...
Truth is the subjection of reality to an individuals perception
And you code with it?
regards, Paul Watson Ireland FeedHenry needs you
eh, stop bugging me about it, give it a couple of days, see what happens.
-
Do you/your company enforce best practices? Do you do code reviews to enforce them, or use FxCop or other automated means? If you don't adhere to any best practice document/utility, why not? Would you agree or disagree that most of us don't use coding best practices? Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
Do you/your company enforce best practices? Do you do code reviews to enforce them, or use FxCop or other automated means? If you don't adhere to any best practice document/utility, why not? Would you agree or disagree that most of us don't use coding best practices?
Hmm... well, my last company didn't have an enforcement policy on following best practices, but it did document many of the processes we considered were good on our development wiki. We also practiced some agile... err... practices, embracing a variable subset of Extreme Programming based on our own judgement. This meant pair programming, test-first design (probably the best thing since sliced bread (and coffee)), opportunistic refactoring, javadoccing and commenting as much as we felt was needed (mostly, not a lot of comments at all), extreme planning (another nice approach to breaking down problems) and using source-control with mostly-continuous integration. Nobody can do everything, so as always, it was a case of comprimising and optimising the variables based on our own evolving heuristic assumptions. However, we didn't do any code reviews during my 6-month stay, although it was always on the cards. Since we had a small team, I think the more experienced permanent cadre guys felt too busy/pressured to get around to it. I've never heard of FxCop - I'll check it out... I'd agree wholeheartedly about the good/bad coders bit. If people are at a poor standard of coding, there's no amount of process improvement/documentation/practices that will make their code good, short of training them up to speed. This needs to be recognised and worked on for real. I think it's usually a fixable problem if the programmer is at all smart and enjoys programming - otherwise they just shouldn't be in this business. :) Oisín
-
In-house crap coders - you can train them to do better. Out-sourced coders - there are too many variables. See earlier thread from Marc Clifton and my replies to him.
Richard A. Abbott wrote:
In-house crap coders - you can train them to do better.
Not necessarily. Some "programmers" are completely untrainable as far as best practices, standards, and style are concerned.
Grim
(aka Toby)
MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL GO
(0 row(s) affected)
-
Do you/your company enforce best practices? Do you do code reviews to enforce them, or use FxCop or other automated means? If you don't adhere to any best practice document/utility, why not? Would you agree or disagree that most of us don't use coding best practices? Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithI have been a Software QA (OMG :omg:) for about 15 years, and 4 companies now. In all of that time, I have only seen one company use formal code reviews that include style and comment checks (they built safety systems for Nuclear Power Plants), in addition to functional checks. While it did take an investment of additional time by both the Developers and QA staff, the end result is that a majority of issues were found before they became expensive to fix. Like any other enforced standard, company or industry wide, it takes a certain amount of time for all involved to "get used" to following them, but once this happens it becomes second nature.
-
God didn't create evil, because evil is not a thing, but that's a discussion for the Soapbox[^] :-). We use XP loosely (is there any other way?). Mostly the attitude here is hire good people and make sure there is nothing in their way. Of course we can do that because we have 6 developers. The more people you hire the more walls you need to build to make sure the general programmer is pointing in the right direction. I like working in a small shop, where I can take a break and read Code Project. -- modified at 10:05 Tuesday 17th October, 2006
Tanks for your support
Pat O
Blog_ _ _
/*\== /*\== /*\== -
I used to place inline comments, but I stopped doing so, simply because if something isn't able to be understood by reading the variable/method names and summary, examples, params, exceptions, etc in the class/method header documentation (C# shop here), then I refactor it until it is simple to understand... What's the saying...if debugging is twice as hard as coding, then by definition if your code is as clever as you can write it, you will not be able to debug it. Did I mention that GhostDoc is a god-send? :)
Good comments tell why a thing was done, not what was done. If the only way a programmer can understand the code is from a comment either the programmer needs some work, or the code does. On the other had, I recently created a backwards for loop (Starts at the end of the Bitmap it is copying and moves back to the origin), because it results in faster code on the ARM processor we are currently using. I commented that so when we change processors (the hardware guys tell me we never will, but I don't believe them), I can re-evaluate the code. Also so someone else doesn't come along and make the code simpler by rewriting the for as a more standard 0 to length for loop. These cases are rare and so comments should be also.
Tanks for your support
Pat O
Blog_ _ _
/*\== /*\== /*\==
<ooo> <ooo> <ooo> -
There is code review at the company I work for and it is good and bad. Almost everyone who does .Net programming is on a code review team. Each team is a mix of experienced senior level developers, mid-level developers, and then novices. This approach works well as everyone is learning from everyone else. However, it is detrimental in a way because each group looks at different items more closely than others and as a result application have more trouble meshing will with other applications than they should have. Also, there are two types of comments that code reviewers make. Critical items and recommended. A developer can choose to ignore recommended comments depending on how difficult or time consuming a change, or how lazy the programmer is. The critical items however can only be overturned by two managers. In ways, code review does slow down development but if done right, everyone learns from everyone else and applications follow a certain standard company wide.
Our company code 'review' is little short of a joke. Some months after the code has gone live the code base receives an anonymous review. The reviewer divides the project into an arbitrary number of sections and reviews each section against 16 language independent 'rules', 9 of which relate to commenting. (Yes the same rules apply to batch files, sql statements, stored procedures/triggers, vbscript, VB6, Vb.Net, asp etc). Each rule is scored for each section and if the rule does not apply, is assumed to be success. A rule is violated by any section is scored as 0. A rule passed by all sections it is scored as 1. The rule scores are then summed to give an overall score for the project, between 0 and 16. The DBA always scores well as only 4 rules apply to him so even if he fails all the rules that apply he still gets a score of 12! The poor programmer who has his work in 16 source files, each evaluated separately, each failing a single, different rule, ends up with a score of zero, although each individual source file scored 15! To make matters worse the review scores contribute to ones annual review.
-
Do you/your company enforce best practices? Do you do code reviews to enforce them, or use FxCop or other automated means? If you don't adhere to any best practice document/utility, why not? Would you agree or disagree that most of us don't use coding best practices? Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithI would agree. Even though code is a very logical product, coding is a very creative process. That said, applying best practices in a coherent and consistent manner can do wonders for the "art".
-
I used to place inline comments, but I stopped doing so, simply because if something isn't able to be understood by reading the variable/method names and summary, examples, params, exceptions, etc in the class/method header documentation (C# shop here), then I refactor it until it is simple to understand... What's the saying...if debugging is twice as hard as coding, then by definition if your code is as clever as you can write it, you will not be able to debug it. Did I mention that GhostDoc is a god-send? :)
The problem is that typically code with next to no comments also has bad method names and long methods. My approach these days is to write summary comments for almost all methods. I don't necessarily comment the args unless unclear. When developing code I often use inline section summary comments. Many of these get removed by refactoring as the comments become new method names. Also I make heavy use of the "replace conditinal with boolean refactoring." Also I find the most common deficiency in code is lack of "why" comments as the other guy says.
Kevin
-
Do you/your company enforce best practices? Do you do code reviews to enforce them, or use FxCop or other automated means? If you don't adhere to any best practice document/utility, why not? Would you agree or disagree that most of us don't use coding best practices? Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithWe use all the perfmons we could, and test objects appart to get an idea of the speed. (Always focus on speed, not resources :rolleyes:) We look FxCop but we know there is a lot of things that we could not implement, time is money, so what we do is putting better in the next project (learning from the mistakes). The important thing is we have design our libraries explaining almost everything for the new people, and there are updated on every project. So in a few projects more will complete all fxcop specifications for our global libraries like database connection, then phase 2 will be clrprofiler tunning :-D
Alejandro Daza Ingeniero de Sistemas Universidad Nacional de Colombia