Paul, Please see my comments below.
Paul wrote: "I think a good set of standards to follow are the Sun Java Code Conventions. It's a fairly short (ish) standard and avoids all the variable prefix and class prefix stuff. http://java.sun.com/docs/codeconv/CodeConventions.pdf"; I agree with you. This would be a simple standard to use. Paul wrote: "So here is my argument for following code conventions and import/code formatting guidelines. If two developers are making a set of changes to some files and they both auto format the code but using different conventions when they go to merge their changes with the other developer the diff tool will highlight a whole bunch of changes for them to review that are just due to the difference in formatting. So by following the same formatting rules merging changes should be easier." I think this is the best argument I have heard for following a code style standard so far. Paul wrote: "I would encourage (not enforce) developers to use Checkstyle http://checkstyle.sourceforge.net/ to flag as warnings where the code differs from coding practices that we as a group decide upon. We can create a config file for checkstyle containing that can be used by the checkstyle plugin for Eclipse, JBuilder, Netbeans, IntelliJ IDEA, Emacs JDE, Vim etc." This is an excellent idea and I plan to follow up with your recommendation if Stefan has no strong objections. Would you be willing to help me set up the Checkstyle configuration file for the Sun Jave Code Conventions? I will then place a copy of it on the SurveyOS SourceForge site for the other developers. I have never used Checkstyle, but I will get it installed in Eclipse and will put some simple instructions on the wiki for others. The Sunburned Surveyor On 5/30/07, Paul Austin <[EMAIL PROTECTED]> wrote: > > I think a good set of standards to follow are the Sun Java Code > Conventions. It's a fairly short (ish) standard and avoids all the > variable prefix and class prefix stuff. > > http://java.sun.com/docs/codeconv/CodeConventions.pdf > > In terms of package imports I don't ever manually type imports any more, > I either use Ctrl-Space to auto add the import when typing a class name > and use the organize imports functionality in eclipse. > > Same for code formatting, I take the Eclipse Sun Code Conventions rule > and have it auto format as I type or reformat after cut and paste. > > So here is my argument for following code conventions and import/code > formatting guidelines. > > If two developers are making a set of changes to some files and they > both auto format the code but using different conventions when they go > to merge their changes with the other developer the diff tool will > highlight a whole bunch of changes for them to review that are just due > to the difference in formatting. So by following the same formatting > rules merging changes should be easier. > > I would encourage (not enforce) developers to use Checkstyle > http://checkstyle.sourceforge.net/ to flag as warnings where the code > differs from coding practices that we as a group decide upon. We can > create a config file for checkstyle containing that can be used by the > checkstyle plugin for Eclipse, JBuilder, Netbeans, IntelliJ IDEA, Emacs > JDE, Vim etc. > > Those are my thoughts, > Paul > > Sunburned Surveyor wrote: > > One of the topics discussed in an earlier thread today was code format > > standards or code style standards.Using tools that will allow us to > > automatically enforce a coding standard was suggested. Using these > > tools to convert existing source code from other JUMP "brands" to our > > style for OpenJUMP was also a suggestion. > > > > I'm really excited that others would be interested in this type of > > consistency and quality for our source code of OpenJUMP. I don't want > > us to loose that momentum! > > However, I'm concerned about implementing such a code style standard > > for a couple of reasons: > > > > [1] I don't think we want to get into a situation where we are > > dictating what IDE, if any, our contributing developers use. I would > > want to make sure that any tools and/or plug-ins that we use for > > automatic code formatting were free from dependencies on a particular > > IDE. > > > > [2] Do we really need to have our contributing developers worry about > > where they put the curly brace in the code? As was mentioned in the > > discussion, I think there are other more important things we can do to > > improve the quality and usability of our code. I'm thinking of things > > like Javadoc comments, other source code comments, change logs, unit > > tests and the like. I'd much rather fight for a requirement that all > > public methods have an intelligent Javadoc comment or something > > similar to that, than push for a standard variable naming convention > > or rules geverning the placement of parentheses and curly braces. > > > > [3] How on Earth would we ever get our developers to agree on a common > > coding standard? I can just imagine the discussions: > > "Should all interfaces and exceptions should share a common prefix in > > their class name?" "Should we ever allow passing a method call as a > > parameter to a method call?" > > > > I just don't think we could all agree on this stuff, do you? I don't > > think it would be worth the bickering to me. Maybe we could just adopt > > an existing standard, but then we would all have to read an learn it, > > and it would probably be different from what we used at work, and > > we're probably to lazy to do it, and… > > > > In summary, if the source code a developer contributes is functional, > > and I can understand what it does when I read it, I am happy. > > Everything else is gravy. I know a lot of open source projects have a > > code style standard, but I think our community is too diverse and > > lacks the strong central authority necessary to make this level of > > control successful. > > > > I am still open to further discussion on this topic. :] If we can > > address some of these basic concerns I am more than willing to learn a > > new tool or coding style. When I say this I speak only for myself, not > > for the other developers or for the project iteself. > > > > The Sunburned Surveyor > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
