Jon, Thanks for making the suggestion about the Javadoc style standard. I believe that this would also be something good to suggest developers follow.
The Sunburned Surveyor On 6/1/07, Jonathan Aquino <[EMAIL PROTECTED]> wrote: > Speaking of Sun code conventions, Sun has a super guide on How To Write > JavaDoc at http://java.sun.com/j2se/javadoc/writingdoccomments/#styleguide > > Jon > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of Sunburned Surveyor > > Sent: Friday, June 01, 2007 8:07 AM > > To: List for discussion of JPP development and use. > > Subject: Re: [JPP-Devel] Code Style Standards > > > > > > 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 > > > ------------------------------------------------------------------------- > 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
