On Tue, Dec 14, 2004 at 05:35:53AM -0500, Michael G Schwern wrote: > Tripped across this on WardsWiki just now. #5 is my favorite as its often > forgotten in the noise. > > http://www.c2.com/cgi/wiki?UncleBobOnCodingStandards > > On coding standards: > > 1. Let them evolve during the first few iterations. > 2. Let them be team specific instead of company specific. > 3. Don't write them down if you can avoid it. Rather, let the code be > the way the standards are captured. > 4. Don't legislate good design. (e.g. don't tell people not to use goto) > 5. Make sure everyone knows that the standard is about communication, and > nothing else. > 6. After the first few iterations, get the team together to decide.
For small to medium sized systems, built by a small team of very bright people, this might work. For large systems, particularly ones which evolve and grow over time, which have large numbers of interacting subsystems and/or which have a mixture of bright and not-so bright people this is very bad advice. > 1. Let them evolve during the first few iterations. Given that the code will be imperfectly and incompletely refactored, Rule 1 ensures that code which is not in accord with standard will persist in the codebase > 2. Let them be team specific instead of company specific. In systems with a large number of interacting subsystems, this makes obtaining an architectural overview much harder, as developers must constantly switch between styles. Worse still, this raises the possibility of subtle bugs due to the same syntactic convention having different semantics in code written by different teams. Might I offer: > 2a. Allow each team to choose their own cutesy name for each pattern they use, > which best embodies how the team feels about that particular pattern. ... > 3. Don't write them down if you can avoid it. Rather, let the code be > the way the standards are captured. This ensures that new starters are at best unproductive and at worst positively harmful. New people have enough to do to get up to speed. A treasure hunt for the coding standards shouldn't be one of them. > 4. Don't legislate good design. (e.g. don't tell people not to use goto) Not everyone who touches every codebase can be trusted to know what good design is. This should, of course, be caught at the hiring stage, but not every organisation is so fortunate. > 5. Make sure everyone knows that the standard is about communication, and > nothing else. But not every standard has the same expressive power. One aspect of this is reducing the documentation load on the developer. As documentation will be the first part of any project to go over the side, rule 5 and rule 2 and rule 3 are inconsistent. > 6. After the first few iterations, get the team together to decide. Inviting junior programmers and their frequently One True Way outlook to those type of design discussions is unlikely to be productive. I'm a little ray of sunshine today. It's not that I think Agile methods don't work, but for a methodology that has so much to say about project Scope, I think some discussion of the scope of applicability of the methods might be worthwhile. Ben
