Paul, I have installed the Checkstyle plug-in for Eclipse and I will be giving it a spin with the XML file you provided.
Thanks, The Sunburned Surveyor On 6/1/07, Paul Austin <[EMAIL PROTECTED]> wrote: > The Eclipses checkstyle plugin comes with the config for the Sun > conventions, which I have attached to this email. > > I recommend that you get the Eclipse plugin > http://eclipse-cs.sourceforge.net/ and then set enable this > for a project to check that you want to use all those rules (some of them > you may not like) and then create a copy of it using the configuration page > and disable those rules you don't want and save that file as the one for > OpenJump. > > Paul > > > Sunburned Surveyor wrote: > 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
