This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes checkstyle messages Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "checkstyle messages" Watch "checkstyle messages" New topic
Author

checkstyle messages

Javier Corral
Greenhorn

Joined: May 23, 2007
Posts: 24
Hi,

I'm reviewing my code with checkstyle and it shows me a lot of messages which I understand but I'm not sure if it's needed to trouble for them.

- A parameter hides a field. It means a name of parameter is equal to a name of a field in the class. Would I decrease my mark if I don't avoid it?.
- Are needed javadoc comments for inherited methods as ActionPerformed(), or for private fields, or when declaring static final Strings which are used as text labels?.
- import ".*" should be avoided?
- Method is not designed to be extended needs to be abstract, final or void.?

Many thanks for advance.
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

I'll give you my opinions (I got 100% in documentation and used checkstyle..).

- A parameter hides a field. It means a name of parameter is equal to a name of a field in the class. Would I decrease my mark if I don't avoid it?.


I disabled that, I don't agree with checkstyle. once you come up with a good name for variable, why change it.. "this.name = name;" is good to me.


- Are needed javadoc comments for inherited methods as ActionPerformed(), or for private fields, or when declaring static final Strings which are used as text labels?.

- I left undocumented inherited methods from my own code (only documented once). I however documented methods inherited from the API (such as ActionPerformed).
- I did not document private fields (except 2-3 fields with normal java comments).
- All my static final fields were also private, so I did not javadoced them.


- import ".*" should be avoided?


I agree with checkstyle here, no wildcard in imports. You want to know exactly on which classes you are depending. In eclipse, right click on your project -> source -> reorganise imports. I believe it will do the trick.

Might as well do "source->Format".


- Method is not designed to be extended needs to be abstract, final or void.?


According to checkstyle (my understanding), any class which is not meant to be sub-classed should be final (not sure what they check for that).
I disabled that.

Regards,
Alex

[ February 05, 2008: Message edited by: Alex Belisle Turcot ]
[ February 05, 2008: Message edited by: Alex Belisle Turcot ]
Javier Corral
Greenhorn

Joined: May 23, 2007
Posts: 24
Thank you, It's been a great help for me.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: checkstyle messages
 
Similar Threads
CheckStyle Rule : Making final to the local variables
checkstyle and hidden field?
Programming practises query
checkstyle help
Checkstyle