* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2003-11-09 06:35]: > Alain Javier Guarnieri del Gesu <[EMAIL PROTECTED]> wrote on 09/11/2003 > 02:30:23 PM: > > > * John Keyes <[EMAIL PROTECTED]> [2003-11-09 02:02]: > > > > > >>For example, I would like to use the sun coding standard as the > > > >>base for my coding standard and I want to change some of the > > > >>settings. > > > > > > > >a) Be warned, the sun_checks.xml do not implement the sun coding > > > > standard. > > > > > > Why not? It's bad that it doesn't work as advertised. > > > > Read the Sun coding standards. They don't AvoidInlineConditionals, > > for example. The Sun coding standard says nothing about > > DesignForExtension, since design is not an aspect of formatting. > > Correct your RedundantThrows and then there is no way to javadoc a > > method that might throw both an IOException and a > > FileNotFoundException. Loath FinalParameters.
> if you have an alternative checkstyle file for the sun_checks.xml, I'm > happy to replace the existing one. > > Patches are always welcome. I created a checkstyle.xml using sun_checks.xml in which I commented out the modules that I though did not match the Sun standards along with a comments explaining the decision. I'd suggest turning off AvoidInlineConditionals, DesignForExtenion, FinalParameters, and RedundantThrows. Many of the Sun interfaces do use the RedundantModifier public. I'm not sure if Sun code trys to avoid HiddenField s, I'll have to pay attention. How do I get this to you? Oh, gee wizz, here it is: -- checkstyle .xml -- <?xml version="1.0"?> <!DOCTYPE module PUBLIC "-//Puppy Crawl//DTD Check Configuration 1.1//EN" "http://www.puppycrawl.com/dtds/configuration_1_1.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"> <!-- 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"> <property name="cacheFile" value="${checkstyle.cache.file}"/> <!-- Checks for Javadoc comments. --> <!-- See http://checkstyle.sf.net/config_javadoc.html --> <module name="JavadocMethod"/> <module name="JavadocType"/> <module name="JavadocVariable"/> <!-- 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. --> <property name="headerFile" value="${checkstyle.header.file}"/> </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"/> <!--+ | Trust Jalopy to handle this, if it doesn't wrap there's | little I can do. <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="NoWhitespaceAfter"/> <module name="NoWhitespaceBefore"/> <module name="OperatorWrap"/> <module name="ParenPad"/> <module name="TabCharacter"/> <module name="WhitespaceAfter"/> <module name="WhitespaceAround"/> <!-- Modifier Checks --> <!-- See http://checkstyle.sf.net/config_modifiers.html --> <module name="ModifierOrder"/> <!--+ | Carps on the specification of public for methods in | interface, and public static final for members in | interfaces. I'm so used to putting them in there, I'll | have to think hard about whether I want this | information taken out. (If had my druthers, there | would be a package keyword to explicity state package | visibility. I suppose I don't go the trouble of | declaring a method abstract in an interface, but then | one can see that it is abstract because it lacks a | body. Then one could see that it is public, because it | lacks a body. Oh, well, old habits die hard. <module name="RedundantModifier"/> | Decided to accept this nit-picker after all. +--> <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"/> <!--+ | Ugh! I suppose this is standard, but I don't like have | so many braces when Jalopy will emphasize the | one-liner with indentation. <module name="NeedBraces"/> +--> <module name="RightCurly"/> <!-- Checks for common coding problems --> <!-- See http://checkstyle.sf.net/config_coding.html --> <!--+ | Oh, give me a break! The Sun coding standards advocate | the use of inline conditionals for clarity. <module name="AvoidInlineConditionals"/> +--> <module name="DoubleCheckedLocking"/> <!-- MY FAVOURITE --> <module name="EmptyStatement"/> <module name="EqualsHashCode"/> <!--+ | There are only so many names to go around. That's why | have the this keyword. <module name="HiddenField"/> +--> <module name="IllegalInstantiation"/> <module name="InnerAssignment"/> <module name="MagicNumber"/> <module name="MissingSwitchDefault"/> <!--+ | Then how are you supposed to document them? <module name="RedundantThrows"/> +--> <module name="SimplifyBooleanExpression"/> <module name="SimplifyBooleanReturn"/> <!-- Checks for class design --> <!-- See http://checkstyle.sf.net/config_design.html --> <!--+ | Sound advice, sure, but not a stricture. | | This puppy carps if a method is not declared final | when it is not abstract, nor is it empty. Apparently, | it is too much to expect a sub-class to call the super | method. True, it is difficult to determine where and | when to call the super method, but there are some | cases when it is pretty obvious. The method clone | comes to mind. | | Whitebox or not, inheritence still makes sense in some | clases. As rule though, I'm going to declare methods | and classes final until I determine it should be | otherwise. It will discipline me to think of | inhteritence as an interface. (Still, the original | spec left inheritence on by default, what what the | thinking behind this?) <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"/> <!--+ | This is making me hate Java. What's the point? If there is | an error because you twiddled a parameter and your | methods are small, you are going to be awful close to | the source of the error. It doesn't prevent you from | modifying an Object ala C++ const, which is a tricker | source of error. In fact, it is going to look awful | strange when I find calling set methods on final | parameters. | | Function signatures become as illegable as C++ | function signatures for little benifit. It's not like | you are recieving the sort of garuntee you get from | const, one that effects the caller. | | A function signature become difficult to read for the | benifit of a compiler check that is effective for the | next few lines. This is a waste of language. | | public void setSize(final int newSize) { | this.size = newSize; | } | | It is rather like adding a keyword: | | thenextvariabledeclarationwillbeoftype int; | int i; | | Hey, just in case! | | Heck, if checkstyle is so smart, why can't is make | sure I don't assign a value to a parameter ifself? | | Addendum: Can't seem to find anyone that is | enthusiastic about final parameters. Here is an | interesting discussion of the final keyword: | | http://renaud.waldura.com/doc/java/final-keyword.shtml <module name="FinalParameters"/> +--> <module name="GenericIllegalRegexp"> <!--+ | Jalopy already takes care of this for code, but | adds a single space charcater after the star in an | empty line of a Javadoc comment, which causes | checkstyle to carp. <property name="format" value="\s+$"/> +--> <property name="format" value=".[^*]\s+$"/> <property name="message" value="Line has trailing spaces."/> </module> <module name="TodoComment"/> <module name="UpperEll"/> </module> </module> <!-- vim: set et ts=2 sw=2 tw=78 ai: --> -- checkstyle .xml -- -- Alain Javier Guarnieri del Gesu - [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
