|
Every developer knows you should have a one, exact, coding standard in your company. Every developer also knows you have to fight to get your rules into the company standard. Every developer secretly despairs when starting a new job, afraid of the crazy coding standard some power-mad architect has dictated. It’s better to throw coding standards out and allow free expression. The small win you get from increased conformity does not move the needle. I expect everyone to write good clean code. You decide what that means.
|
|
|
|
|
Coding standards are pointless . They simply massage the ego of whoever writes them . Write the tests first , pass the tests , then re factor . Coding standards are irrelevant.
|
|
|
|
|
Totally disagree.
There are different levels of coding standards.
1. How files and projects are organised and named
2. How namespaces, classes and all objects and variables are named
3. How code is organised within files (eg Adhering to StyleCop, how different sections are laid out)
4. How you code within a method (eg do you always ensure input params are checked? Output is checked?
5. How you format code. Braces on new or the same line? Wrap at 100 chars? Braces around all code blocks even if they are 1 line?
6. How you comment code.
7. How you handle error conditions. Do you throw exceptions or rely on passing around state?
8. How you handle return values - do you allow nulls, or do you always return an object, for example?
and on it can go.
These aren't nice to haves. These standards massively reduce the effort needed to scan large projects. Once someone understands the conventions in place in one part, they can move to any other part and understand how things are laid out and what to expect.
Standards such as how errors are handled ensure consistency in the code, and standards such as commenting ensure sufficient comments are placed where they are needed, and no more.
Coding Standards are like building or wiring standards. They reduce mistakes.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
10!
I'd much rather work at a place with a standard than one without.
|
|
|
|
|
Much of what you are talking about I would term good design practices - no problem with those . To me only 3 and 5 are coding standards . And in the case of these I would much rather that time was spent on designing , and testing than these . If having or not having a curly brace on a single line block is your biggest issue then you are very lucky .
I have yet to see a project yet where 3 and 5 have been a significant issue. However I have been involved with hundreds of arguments with developers as to what the style should be . And invariably it boils down to 'my style is best' . I have lost count of the number of times we ended up with ' I think X' ' ' No I think Y' arguments . When in reality the time would have been better spent thinking about the design , process or testing .
|
|
|
|
|
There's a difference between coding style and coding standards.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Tabs or spaces? Which do you prefer? What about your colleagues? Are they all the same?
If any one of you prefers a different indentation type, then good luck with your code check ins and merges - not all repositories are forgiving of whitespace changes.
|
|
|
|
|
I was also a big advocate of strict coding stadards. I was nit-picking on every single curly brace and intendation and totally missing the big picture. Then I got into same realization as the blog's writer that the most important thing is to be consistent and get something delivered to the customer!
Now I'm much happier without having to worry about the semicolon placements and all. I know that my teammates will do a good job
|
|
|
|
|
How can you be consistent if there is no standard? Consistency is achieved through standards. Even if those standards are then unwritten standards, they are still standards.
|
|
|
|
|
I meant that it's quite impossible to have a single coding standard that everyone sticks to. So it's everyone's responsibility to write code that's predictable in their own way. I think that's the message the OP's article wants to tell.
For example in C# naming member variables is usually done by prefixing them with an underscore. If you don't like that then fine, but don't mix different prefixes around in different places of your program.
|
|
|
|