wood burning stoves*
The moose likes Beginning Java and the fly likes Programming practises query Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Programming practises query" Watch "Programming practises query" New topic
Author

Programming practises query

Sean Clark
Rancher

Joined: Jul 15, 2009
Posts: 377

Hey,
In my workplace we use checkstyle to ensure that all the coding conforms to the coding standards and I have a couple of queries.

Here is a very simple piece of code:



This code will bring up 3 checkstyle errors, I'd like your opinion on the usefullness of these and any other opinions that you have.

1) 'id' hides a field. This is annoying as it has meant that I have had to change all the variables in my setters after generating them, which is rather pointless. i can see how in some cases it is a good idea to highlight this.
2) Parameter 'id' should be final. Again I can see how this would be helpful, but to me it just seems like more code.
3) Method setId is not designed for abstraction - needs to be abstract final or empty.

Any comments would be appreciated
Sean


I love this place!
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

Sean Clark wrote:
1) 'id' hides a field. This is annoying as it has meant that I have had to change all the variables in my setters after generating them, which is rather pointless. i can see how in some cases it is a good idea to highlight this.


This is one of those rules I typically take as a suggestion, not a rule :-) For large/complex methods it makes sense, and I do my best to follow it (really when the method is more than 3-5 lines) so as to improve the clarity of code.

For short methods like setters I typically ignore it.


2) Parameter 'id' should be final. Again I can see how this would be helpful, but to me it just seems like more code.


I really like the mark all parameters as final rule, I try to always follow this unless I am being particularly lazy. If you are letting your IDE generate this code, see if you can't modify its code generating template to add final, that way you don't have to manually change it.

You may be able to change the code template to modify the name of the parameter as well, avoiding #1.


3) Method setId is not designed for abstraction - needs to be abstract final or empty.


Another good one to know, and follow. If the class itself isn't final, then it is a good idea that methods with real functionality be made final - which protects them from unwanted modification by child classes which could break them (maliciously or ignorantly). Not always the right thing to do, but good to do as the default, then remove the final modifier later if you find a compelling reason why the method should be overriden by a child class.


Steve
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

(1) I've waffled on this one over the years. These days I often append underscores to parameter names--some people absolutely *hate* this. But I look at source code in many ways, and don't want to rely on IDE functionality for trivially indicating parameters, so for me both works great, and eliminates the problem. The problem with turning this warning off is that it's almost *always* an error to name a variable the same as a property, or at the very least unnecessarily confusing. (Of course, I sometimes use leading underscores for property names, which also drives people batshit crazy.)

(2) Meh. If I'm really concerned about making something final I mark it final--but I don't have that rule on any longer. IMO it's bad practice to set parameter values to something else and/or *may* indicate somebody misunderstanding how Java works, but I only rarely worry about this one anymore. That said, most of my methods are very short--it's a very rare occasion this ever creates a problem. YMMV.

(3) I only care about this if I'm writing something for consumption. I'm much more careful about APIs, but even then I tend towards being open--but as an oldbie Smalltalk and Lisp programmer, where *everything* was open, it might not always be the best approach: it's been my observation there are a lot more stupid/dangerous/incompetent/unaware programmers these days that might actually *need* protection from themselves.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Programming practises query