Could you pretty please send it as an attachment. Email ruins line ends and wraps stuff unnecessarily.... -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Alain Javier Guarnieri del Gesu <[EMAIL PROTECTED]> wrote on 10/11/2003 04:54:42 AM: > * [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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
