> > [...] > > Think about it from the standpoint of a new contributor. How long > does it take to prepare and get a patch committed for a) the new > contributor and b) the committer who ends up applying the patch. > More rules means more time. It is that simple. Either the new > contributor has to keep fixing his or her patch so it complies with > all of the rules or the committer applying it does that. In either > case, friction is introduced. Fewer rules means less friction, > which IMO is more important than cosmetics.
There is friction if everyone wants to stick with his own style. And there is friction when one has to read poorly written code, just the same as if you'd have to read a document with one word in black, then one in red, followed by one in italic, then one in bold, one in a 12-points font, one in 14-points font, one in times and one in roman, etc. There is reason for formatting rules: make a pleasant read. People have to make a little effort e.g. to type LaTeX code so that the _reader_ can be more confortable. [And the effort is much less when writing Javadoc.] The actual style is not so important as having a _single one_ (per project, per programming language). Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
