Le 24/08/2012 03:29, Becksfort, Jared a écrit : >>> [...] >>> >>> 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 > > Hello, > > I recently contributed my first patch last month and have a couple > more to go, so I figure I can add something to the discussion of > formatting being a barrier to entry. I was initially a bit surprised > at how much I code I needed to reformat, but I expected there to be > some. In retrospect, the initial patch I turned in was a bit sloppy. > Importantly, though, Gilles paid attention enough to the issue I was > patching and provided me with some pretty good feedback that > eventually resulted in committed code. Now as I prepare a couple of > new patches, I don't think the style is a significant deterrent. It > definitely would be a deterrent though if patches were just rejected > outright with little feedback. I realize that requires a bit of a > commitment on the part of the main developers, so I guess you will > have to decide how much of a hassle it is. If there are tons of new > contributors, it might be too much effort, but I imagine that a lot > of the code comes from repeat contributors and the main developers. > > I realize not everyone uses Eclipse, but you can pretty easily set up > code formatting for individual projects. It also allows for code > styles to be exported and imported. Maybe it would be helpful to > make a code style available for download.
There is one here for eclipse: <http://people.apache.org/~luc/Apache-commons.xml>. Luc > > Jared > > Email Disclaimer: www.stjude.org/emaildisclaimer Consultation > Disclaimer: www.stjude.org/consultationdisclaimer > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
