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
