2010/12/13 Olivier Grisel <[email protected]>: > > I agree with SF that columns soft and hard limits really helps > readability a lot: this is really the only valid reason. > > Also I can not stress enough the importance of using existing widely > used code conventions: If we use the conventions that most people use > in other project they will feel at home when reading our code base. > This is really important to attract new contributors and blend well > with the rest of the community.
So what do we do about the code conventions? I think this is really important that we are consistent both internally (inside the stanbol project) and external (with established project that might be related to us such as apache solr and mahout). Please try to apply the formatter to a project for testing: Save the following as a file named Mahout-Eclipse-Codeformatter.xml on your HDD: https://cwiki.apache.org/confluence/download/attachments/74839/Mahout-Eclipse-Codeformatter.xml?version=1&modificationDate=1266109560000 Ensure that you have no local changes on your stanbol source tree, then go to eclipse and right click on the one of the stanbol projects: Properties > Java Code Style > Formatter click "Enabled project specific settings" and then "Import..." and select the Mahout-Eclipse-Codeformatter.xml file and apply. Then go to a class of this project and format it using the keyboard shortcut "Shift-Ctrl-F". See the results and then revert your changes with "svn revert" (do not check in formatting before we reach a consensus). This formatter uses 2 spaces for indenting and 110 columns wrapping. Though I tend to prefer the conventions we use in nuxeo by personal taste, I think it is more important to be consistent with what the majority is using in the apache community. The real value of code conventions lies in there ability to be shared with many projects. Could people who voted -1 (or expressed negative comments on this), please give feedback or propose an alternative eclipse formatter file? We really need to reach a consensus soon on this. I think that the current state on the code base is really messy and we need to agree on some style conventions before starting the big package name refactoring. -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel
