You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by John Keyes <jb...@mac.com> on 2003/11/09 01:49:07 UTC
Checkstyle Configuration
Hi,
Is it possible to override configuration settings in the
current Checkstyle plugin like it was possible when
properties files were used? 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.
I notice that the turbine config just redefines all of the
sun settings as well as the ones they wanted to change.
I think it would be a neat feature to support configuration
importing. Then the turbine config could look like this:
<?xml version="1.0"?>
<!DOCTYPE module PUBLIC
"-//Puppy Crawl//DTD Check Configuration 1.1//EN"
"http://www.puppycrawl.com/dtds/configuration_1_1.dtd">
<modules>
<import href="sun_checks.xml"/>
<module name="TreeWalker">
<!--
************************************************************** -->
<!-- Checks that are different from the sun coding conventions
ones -->
<!--
************************************************************** -->
<property name="tabWidth" value="4"/>
<module name="LeftCurly">
<property name="option" value="nl"/>
</module>
<module name="RightCurly">
<property name="option" value="alone"/>
</module>
<module name="LineLength">
<property name="ignorePattern" value="@version"/>
</module>
<module name="MemberName">
<property name="format" value="^f[A-Z][a-zA-Z0-9]*$"/>
</module>
</module>
</modules>
Modules defined in the 'importing' document override those defined in
the
'imported' one.
-John K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Checkstyle Configuration
Posted by John Keyes <jb...@mac.com>.
I'll broach the subject with the Checkstyle developers. I asked here
first to see if anyone had any dealings in the matter. I wasn't
suggesting Maven should solve the hierarchical configuration issue
just wondering what people thought of the idea. I'll raise the
thread on the Checkstyle list and see what they have to say on
the matter.
Thanks for everyone's input.
-John K
On 9 Nov 2003, at 02:48, __matthewHawthorne wrote:
> The way I see it, Maven doesn't want to get involved with configuring
> Checkstyle. It just calls Checkstyle for you with a user provided
> file, or a default. Adding some heirarchical configuration loader for
> Checkstyle sounds nice, but then Maven would have to consider doing
> the same for a lot of other plugins. It seems easiest and most
> efficient to keep things separate.
>
> However, this may be a nice workaround:
>
> I like the Checkstyle plugin for Eclipse. I believe that the defaults
> that it uses are based on the Sun standards. You can create a copy of
> the default, rename it, customize it to your liking, and then export
> it to an xml file. Perhaps you could then use this file in Maven?
>
> Hope this helps.
>
>
>
>
> John Keyes wrote:
>>>> Is it possible to override configuration settings in the
>>>> current Checkstyle plugin like it was possible when
>>>> properties files were used?
>>>
>>>
>>> maven.checkstyle.properties=my-checkstyle.xml
>> Yes but I have to specify all of the rules again in that file. I
>> think it should be extensible.
>>>> 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.
>>> b) Have you seen Jalopy? http://jalopy.sourceforge.net/
>>> There is a 'jalopy' goal.
>> Yeah, but it doesn't haven any relevance to this discussion.
>> I just like the idea of being able to import a base standard
>> and customize that as I see fit.
>> -John K
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Checkstyle Configuration
Posted by __matthewHawthorne <ma...@phreaker.net>.
The way I see it, Maven doesn't want to get involved with configuring
Checkstyle. It just calls Checkstyle for you with a user provided file,
or a default. Adding some heirarchical configuration loader for
Checkstyle sounds nice, but then Maven would have to consider doing the
same for a lot of other plugins. It seems easiest and most efficient to
keep things separate.
However, this may be a nice workaround:
I like the Checkstyle plugin for Eclipse. I believe that the defaults
that it uses are based on the Sun standards. You can create a copy of
the default, rename it, customize it to your liking, and then export it
to an xml file. Perhaps you could then use this file in Maven?
Hope this helps.
John Keyes wrote:
>>> Is it possible to override configuration settings in the
>>> current Checkstyle plugin like it was possible when
>>> properties files were used?
>>
>>
>> maven.checkstyle.properties=my-checkstyle.xml
>
>
> Yes but I have to specify all of the rules again in that file. I
> think it should be extensible.
>
>>> 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.
>
>> b) Have you seen Jalopy? http://jalopy.sourceforge.net/
>> There is a 'jalopy' goal.
>
>
> Yeah, but it doesn't haven any relevance to this discussion.
> I just like the idea of being able to import a base standard
> and customize that as I see fit.
>
> -John K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Checkstyle Configuration
Posted by di...@multitask.com.au.
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 <ja...@ajgdg.com> wrote on 10/11/2003
04:54:42 AM:
> * dion@multitask.com.au <di...@multitask.com.au> [2003-11-09 06:35]:
> > Alain Javier Guarnieri del Gesu <ja...@ajgdg.com> wrote on
09/11/2003
> > 02:30:23 PM:
> >
> > > * John Keyes <jb...@mac.com> [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 - javi@ajgdg.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Checkstyle Configuration
Posted by Alain Javier Guarnieri del Gesu <ja...@ajgdg.com>.
* dion@multitask.com.au <di...@multitask.com.au> [2003-11-09 06:35]:
> Alain Javier Guarnieri del Gesu <ja...@ajgdg.com> wrote on 09/11/2003
> 02:30:23 PM:
>
> > * John Keyes <jb...@mac.com> [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 - javi@ajgdg.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Checkstyle Configuration
Posted by Alain Javier Guarnieri del Gesu <ja...@ajgdg.com>.
* John Keyes <jb...@mac.com> [2003-11-09 04:22]:
> >>Yes but I have to specify all of the rules again in that file. I
> >>think it should be extensible.
> >
> >I don't see why. Its a configuration file. Create your own
> >configuration. It is just as easy to copy the file and edit it.
>
> Of course you can. I just think its a step backwards in
> comparison to the previous version.
I didn't know the previous version. My apologies for the pedantic
comment.
> >>>>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.
>
> Well then the file should not be called sun_checks.xml, it is just
> another user configuration. The sun coding standard support
> should do exactly what it says on the tin and nothing more.
The sun_checks.xml file is not the Sun coding standards. It is
really a show of force. It enables every nit-picker in
Checkstyle so that Checkstyle can strut its stuff. Some of the
nit-pickers contradict each other. Some are design strictures,
not coding standards. Some of them are bang opposite of the Sun
convention.
Coming back to AvoidInlineConditionals :
http://checkstyle.sourceforge.net/config_coding.html#AvoidInlineConditionals
"Rationale: Some developers find inline conditionals hard to read,
so their company's coding standards forbids them."
The Sun standards actually advocate the use of inline conditionals
to clarify return statements:
http://java.sun.com/docs/codeconv/html/CodeConventions.doc9.html#570
Tinned Sun code? Jalopy is the answer. My jaw-dropped when I first
ran it. Forgive me my enthusiasm. I'm still enamoured of this
application. And Maven supports Jalopy so well, too!
Checkstyle does check formatting, but it also seeks structural
problems, and Javadoc errors. The name sun_checks.xml might be a
misnomer in any case. Perhaps, better names might be
relaxed_checks.xml and rediculous_checks.xml.
--
Alain Javier Guarnieri del Gesu - javi@ajgdg.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Checkstyle Configuration
Posted by John Keyes <jb...@mac.com>.
>> Yes but I have to specify all of the rules again in that file. I
>> think it should be extensible.
>
> I don't see why. Its a configuration file. Create your own
> configuration. It is just as easy to copy the file and edit it.
Of course you can. I just think its a step backwards in
comparison to the previous version.
>>>> 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.
Well then the file should not be called sun_checks.xml, it is
just another user configuration. The sun coding standard
support should do exactly what it says on the tin and nothing
more.
>>> b) Have you seen Jalopy? http://jalopy.sourceforge.net/
>>> There is a 'jalopy' goal.
>
>> Yeah, but it doesn't haven any relevance to this discussion. I
>> just like the idea of being able to import a base standard and
>> customize that as I see fit.
>
> It is relevent. With Jalopy your code will comply to the Sun coding
> standards. Is that now what you want?
>
> "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."
I know how to resolve the issue, I am just highlighting an area
of weakness (IMO) with the current version.
Cheers,
-John K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Checkstyle Configuration
Posted by di...@multitask.com.au.
Alain,
if you have an alternative checkstyle file for the sun_checks.xml, I'm
happy to replace the existing one.
Patches are always welcome.
--
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 <ja...@ajgdg.com> wrote on 09/11/2003
02:30:23 PM:
> * John Keyes <jb...@mac.com> [2003-11-09 02:02]:
>
> > >>Is it possible to override configuration settings in the
> > >>current Checkstyle plugin like it was possible when
> > >>properties files were used?
> > >
> > >maven.checkstyle.properties=my-checkstyle.xml
>
> > Yes but I have to specify all of the rules again in that file. I
> > think it should be extensible.
>
> I don't see why. Its a configuration file. Create your own
> configuration. It is just as easy to copy the file and edit it.
>
> > >>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.
>
> > >b) Have you seen Jalopy? http://jalopy.sourceforge.net/
> > > There is a 'jalopy' goal.
>
> > Yeah, but it doesn't haven any relevance to this discussion. I
> > just like the idea of being able to import a base standard and
> > customize that as I see fit.
>
> It is relevent. With Jalopy your code will comply to the Sun coding
> standards. Is that now what you want?
>
> "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."
>
> --
> Alain Javier Guarnieri del Gesu - javi@ajgdg.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Checkstyle Configuration
Posted by Alain Javier Guarnieri del Gesu <ja...@ajgdg.com>.
* John Keyes <jb...@mac.com> [2003-11-09 02:02]:
> >>Is it possible to override configuration settings in the
> >>current Checkstyle plugin like it was possible when
> >>properties files were used?
> >
> >maven.checkstyle.properties=my-checkstyle.xml
> Yes but I have to specify all of the rules again in that file. I
> think it should be extensible.
I don't see why. Its a configuration file. Create your own
configuration. It is just as easy to copy the file and edit it.
> >>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.
> >b) Have you seen Jalopy? http://jalopy.sourceforge.net/
> > There is a 'jalopy' goal.
> Yeah, but it doesn't haven any relevance to this discussion. I
> just like the idea of being able to import a base standard and
> customize that as I see fit.
It is relevent. With Jalopy your code will comply to the Sun coding
standards. Is that now what you want?
"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."
--
Alain Javier Guarnieri del Gesu - javi@ajgdg.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Checkstyle Configuration
Posted by John Keyes <jb...@mac.com>.
>> Is it possible to override configuration settings in the
>> current Checkstyle plugin like it was possible when
>> properties files were used?
>
> maven.checkstyle.properties=my-checkstyle.xml
Yes but I have to specify all of the rules again in that file. I
think it should be extensible.
>> 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.
> b) Have you seen Jalopy? http://jalopy.sourceforge.net/
> There is a 'jalopy' goal.
Yeah, but it doesn't haven any relevance to this discussion.
I just like the idea of being able to import a base standard
and customize that as I see fit.
-John K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Checkstyle Configuration
Posted by Alain Javier Guarnieri del Gesu <ja...@ajgdg.com>.
* John Keyes <jb...@mac.com> [2003-11-09 00:49]:
> Hi,
>
> Is it possible to override configuration settings in the
> current Checkstyle plugin like it was possible when
> properties files were used?
maven.checkstyle.properties=my-checkstyle.xml
> 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.
b) Have you seen Jalopy? http://jalopy.sourceforge.net/
There is a 'jalopy' goal.
I use both.
--
Alain Javier Guarnieri del Gesu - javi@ajgdg.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org