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
<?xml version="1.0"?>
<!DOCTYPE module PUBLIC
"-//Puppy Crawl//DTD Check Configuration 1.2//EN"
"http://www.puppycrawl.com/dtds/configuration_1_2.dtd";>
<!--
Checkstyle configuration that checks the sun coding conventions from:
- the Java Language Specification at
http://java.sun.com/docs/books/jls/second_edition/html/index.html
- the Sun Code Conventions at http://java.sun.com/docs/codeconv/
- the Javadoc guidelines at
http://java.sun.com/j2se/javadoc/writingdoccomments/index.html
- the JDK Api documentation http://java.sun.com/j2se/docs/api/index.html
- some best practices
Checkstyle is very configurable. Be sure to read the documentation at
http://checkstyle.sf.net (or in your downloaded distribution).
Most Checks are configurable, be sure to consult the documentation.
To completely disable a check, just comment it out or delete it from the file.
Finally, it is worth reading the documentation.
-->
<module name="Checker">
<property name="severity" value="warning"/>
<!-- Checks that a package.html file exists for each package. -->
<!-- See http://checkstyle.sf.net/config_javadoc.html#PackageHtml -->
<module name="PackageHtml"/>
<!-- Checks whether files end with a new line. -->
<!-- See http://checkstyle.sf.net/config_misc.html#NewlineAtEndOfFile -->
<module name="NewlineAtEndOfFile"/>
<!-- Checks that property files contain the same keys. -->
<!-- See http://checkstyle.sf.net/config_misc.html#Translation -->
<module name="Translation"/>
<module name="TreeWalker">
<!-- Checks for Javadoc comments. -->
<!-- See http://checkstyle.sf.net/config_javadoc.html -->
<module name="JavadocMethod"/>
<module name="JavadocType"/>
<module name="JavadocVariable"/>
<module name="JavadocStyle"/>
<!-- Checks for Naming Conventions. -->
<!-- See http://checkstyle.sf.net/config_naming.html -->
<module name="ConstantName"/>
<module name="LocalFinalVariableName"/>
<module name="LocalVariableName"/>
<module name="MemberName"/>
<module name="MethodName"/>
<module name="PackageName"/>
<module name="ParameterName"/>
<module name="StaticVariableName"/>
<module name="TypeName"/>
<!-- Checks for Headers -->
<!-- See http://checkstyle.sf.net/config_header.html -->
<!-- <module name="Header"> -->
<!-- The follow property value demonstrates the ability -->
<!-- to have access to ANT properties. In this case it uses -->
<!-- the ${basedir} property to allow Checkstyle to be run -->
<!-- from any directory within a project. See property -->
<!-- expansion, -->
<!-- http://checkstyle.sf.net/config.html#properties -->
<!-- <property -->
<!-- name="headerFile" -->
<!-- value="${basedir}/java.header"/> -->
<!-- </module> -->
<!-- Following interprets the header file as regular expressions. -->
<!-- <module name="RegexpHeader"/> -->
<!-- Checks for imports -->
<!-- See http://checkstyle.sf.net/config_import.html -->
<module name="AvoidStarImport"/>
<module name="IllegalImport"/> <!-- defaults to sun.* packages -->
<module name="RedundantImport"/>
<module name="UnusedImports"/>
<!-- Checks for Size Violations. -->
<!-- See http://checkstyle.sf.net/config_sizes.html -->
<module name="FileLength"/>
<module name="LineLength"/>
<module name="MethodLength"/>
<module name="ParameterNumber"/>
<!-- Checks for whitespace -->
<!-- See http://checkstyle.sf.net/config_whitespace.html -->
<module name="EmptyForIteratorPad"/>
<module name="MethodParamPad"/>
<module name="NoWhitespaceAfter"/>
<module name="NoWhitespaceBefore"/>
<module name="OperatorWrap"/>
<module name="ParenPad"/>
<module name="TypecastParenPad"/>
<module name="TabCharacter"/>
<module name="WhitespaceAfter"/>
<module name="WhitespaceAround"/>
<!-- Modifier Checks -->
<!-- See http://checkstyle.sf.net/config_modifiers.html -->
<module name="ModifierOrder"/>
<module name="RedundantModifier"/>
<!-- Checks for blocks. You know, those {}'s -->
<!-- See http://checkstyle.sf.net/config_blocks.html -->
<module name="AvoidNestedBlocks"/>
<module name="EmptyBlock"/>
<module name="LeftCurly"/>
<module name="NeedBraces"/>
<module name="RightCurly"/>
<!-- Checks for common coding problems -->
<!-- See http://checkstyle.sf.net/config_coding.html -->
<module name="AvoidInlineConditionals"/>
<module name="DoubleCheckedLocking"/> <!-- MY FAVOURITE -->
<module name="EmptyStatement"/>
<module name="EqualsHashCode"/>
<module name="HiddenField"/>
<module name="IllegalInstantiation"/>
<module name="InnerAssignment"/>
<module name="MagicNumber"/>
<module name="MissingSwitchDefault"/>
<module name="RedundantThrows"/>
<module name="SimplifyBooleanExpression"/>
<module name="SimplifyBooleanReturn"/>
<!-- Checks for class design -->
<!-- See http://checkstyle.sf.net/config_design.html -->
<module name="DesignForExtension"/>
<module name="FinalClass"/>
<module name="HideUtilityClassConstructor"/>
<module name="InterfaceIsType"/>
<module name="VisibilityModifier"/>
<!-- Miscellaneous other checks. -->
<!-- See http://checkstyle.sf.net/config_misc.html -->
<module name="ArrayTypeStyle"/>
<module name="FinalParameters"/>
<module name="GenericIllegalRegexp">
<property name="format" value="\s+$"/>
<property name="message" value="Line has trailing spaces."/>
</module>
<module name="TodoComment"/>
<module name="UpperEll"/>
</module>
</module>
-------------------------------------------------------------------------
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
