What sort of best practices coding do you use?
-
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
-
Marc Clifton wrote:
I guess that's where places like Code Project come in
So we need a CodeReview forum!!
ed ~"Watch your thoughts; they become your words. Watch your words they become your actions. Watch your actions; they become your habits. Watch your habits; they become your character. Watch your character; it becomes your destiny." -Frank Outlaw.
Brilliant idea... but Some things are more subjective than others, best practices for you might not be best practices for someone else, I know my code is noobish, but finding your own rule set for programming is important, then sticking to it. I fear that a CodeReview forum would just become a R18 flaming forum, and no conclusions will really be reached. for (int iq = 0;iq > -1;iq++);
-
Brilliant idea... but Some things are more subjective than others, best practices for you might not be best practices for someone else, I know my code is noobish, but finding your own rule set for programming is important, then sticking to it. I fear that a CodeReview forum would just become a R18 flaming forum, and no conclusions will really be reached. for (int iq = 0;iq > -1;iq++);
True enough. It would probably dwarf the SoapBox! :laugh:
ed ~"Watch your thoughts; they become your words. Watch your words they become your actions. Watch your actions; they become your habits. Watch your habits; they become your character. Watch your character; it becomes your destiny." -Frank Outlaw.