On Tue 14 Dec 2004 12:15, Ben Evans <[EMAIL PROTECTED]> wrote: > 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.
Not entirely true. These discussions give the more experienced programmers a chance to explain *why* the applied coding standards were chosen in the first place. Once they (try to) understand that, adapting to it might be much easier for them. As an example here, we have 5 coders, and all like to use a different style (in fact one of them does not care at all about style, which is even worse). We had a *huge* discussion about the style we wanted here for corporate stuff, and we made compromises to make as many people as happy as possible. That works. We can all read, understand, and - most important - maintain each others code now, which includes C, perl, sh, and 4GL code. Also important is to choose styles that match the people that *stay* with the company. Here, the avarage coder already works for over 10 years with this firm, and if we would let our styles be guided by someone we would hire for a few month to help us through busy times, that would be very counterproductive. My stance is to enforce clean and styled code from the very beginning, because chances are high that working code won't be changed afterwords just to meet the coding standards (exceptions I just met was C code for which the most recent change was back in 1998 and was - for available compiler reasons on that platform - not yet in strict ANSI with prototypes etc. I had to rewrite all function headers to meet the newer strictnesses, and modified some cruft to meet the current standards, making the code free of all warnings for gcc -Wall and HP's C-ANSI-C, which is also very strict). Perl scripts written for production cannot be shipped without use strict and use warnings. Period. In case of disagreement, I decide :) > 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. -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.5, & 5.9.x, and 809 on HP-UX 10.20 & 11.00, 11i, AIX 4.3, AIX 5.2, SuSE 9.1, and Win2k. http://www.cmve.net/~merijn/ http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
