Hey Christophe, >Aral, stop promoting that or I'll tickle you through my voodoo doll ! > > I know I never should've agreed to the Mattel action figure -- I knew this would happen!
>Now seriously, I am pro convention all the way, but the most important >thing is that it is a convention in the team you are working in. > I disagree: I don't believe that the various different conventions offer enough advantages to outweigh the (a) time spent bringing in/adjusting new team members who are not familiar with those conventions (b) educating new developers and (c) wasting bandwidth/time/etc. in religious debates about them, etc. At the end of the day, I'd prefer it if the compiler checked for things like brace placement and use (or non-use) of semi-colons, etc. These are, mostly, very subjective/personal preferences that should really not be an issue. Ken Arnold argues the point better than I can here. I highly recommend reading his "Style is Substance" post which I originally read in the excellent "The Best Software Writing" book compiled by Joel Spolsky. http://www.artima.com/weblogs/viewpost.jsp?thread=74230 To quote his article: " I'll state it right out: For almost any mature language (C, Java, C++, Python, Lisp, Ada, FORTRAN, Python, Smalltalk, sh, javascript, ...) coding style is an essentially solved problem, and we ought to stop worrying about it. And to stop worrying about it will require worrying about it a lot first, because the only way to get from where we are to a place where we stop worrying about style is to enforce it /as part of the language/." "Here is the logic in its most simple form: *Premise 1: For any given language, there are one or a few common coding styles.* Typically one is set by the founder(s) or earliest documenter, but others will evolve over time. But even for C there are only a handful of commonly used styles, ignoring trivial variations. *Premise 2: There is not now, nor will there ever be, a programming style whose benefit is significantly greater than any of the common styles.* Get real. Discovering a style that improves your productivity or code quality by more than a few percent over the common styles is about as likely as discovering a new position for sex. [Astronauts need not apply, unless they want to invite me along.] *Premise 3: Approximately a gaboozillion cycles are spent on dealing with coding style variations.* Think about it: How many reformatter/pretty-printers projects are there on sourceforge <http://sf.net> alone? How many options does any given IDE (including emacs) have for formatting code? How many cycles are spent deciding on a style, documenting it, enforcing it, and updating it? How many history logs for CVS, Clearcase, etc., have a lot of noise from varying format changes? How many brain cycles are spent on arguing about this topic? *Premise 4: For any non-trivial project, a common coding style is a good thing.* I really think this is pretty well agreed on. How constraining the style is varies, but having several folks hacking on the same code with conflicting coding styles introduces more pain than any single style imposes on any single person. Every project I know of has a style, if not spelled out at least by custom. *Conclusion: Thinking of all the code in the entire world as a single "project" with a single style, we would get more value than we do by allowing for variations in style."* Read the full article here: http://www.artima.com/weblogs/viewpost.jsp?thread=74230 Aral _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
