This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Declaring and initializing instance variables

 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What's the best practice as far as instance variables initialization is concerned ?
Given a class with these instance variables :

what's the best way of coding it ?

Thank you in advance for your comments.
Best,
Phil.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think there's any clear industry standard or agreement on best practices here; different people will have different opinions. Personally I prefer #3. I note that the Sun style guide doesn't say either way (not for member variables), but they do have several examples in which member variables are not explicitly initialized to anything when they're declared. I don't actually see any examples in which members are explicitly initialized on declaration. But Josh Bloch uses both styles in his book; that's good enough for me.
More or my own opinions: extressly initializing fields to default values is pointless, IMO; and coddling junior coders by wrting "= null" or "= 0" just delays them from understanding how defaults work. For non-defulat values, I favor initializing them ASAP. Meaning, at declaration time unless you need to wait - most commonly, if you need a constructor argument to initialize the field properly, you need to do it in the constructor.
I make extensive use of "final" whenever possible. Even if the containing class is not immutable overall; even if the field is a reference to a mutalbe object - if it's possible for me to declara field final, I will. This allows the compiler to help me out by making sure that the darn thing really is initialized somewhere. And also it may prevent me from reassigning a value later without realizing it. Obviously if I find I need to change a field later, I can remove the final. But until I know that a field must be mutable, my default assumtion is that it shouldn't be. This has proved fairly useful when dealing with initialization issues.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jim,

Thanks for your reply. I do prefer #3 too but I didn't mention my own preference to avoid any influence on answers. So I am pretty sure now that Mark's answer is sincere.
My problem is that as I was a java newbie when I started with this project, I've currently a mix of all 4 possible ways of coding... And before I apply #3 everywhere (just for consistency), I wanted to make sure it is a correct way of doing.
I note that the Sun style guide doesn't say either way

Yes, and rather surprisingly IMO.
More or my own opinions: extressly initializing fields to default values is pointless, IMO; and coddling junior coders by wrting "= null" or "= 0" just delays them from understanding how defaults work. For non-defulat values, I favor initializing them ASAP. Meaning, at declaration time unless you need to wait - most commonly, if you need a constructor argument to initialize the field properly, you need to do it in the constructor.

Agreed 100%. I'd add that avoiding to expressly initialize fields to default values makes the code easier to read ... simply because there is less to be read. Same with the constructors which will be shorter on average.
Now more surprising that the lack of any "official" rule, it seems that Sun has no clear rule at all in that matter (or that Sun's engineers don't follow it) :
(UPPERCASED comments below are mine )
In LinkedList.java :

In StringTokenizer.java :

I make extensive use of "final" whenever possible. Even if the containing class is not immutable overall; even if the field is a reference to a mutalbe object - if it's possible for me to declara field final, I will. This allows the compiler to help me out by making sure that the darn thing really is initialized somewhere. And also it may prevent me from reassigning a value later without realizing it. Obviously if I find I need to change a field later, I can remove the final. But until I know that a field must be mutable, my default assumtion is that it shouldn't be. This has proved fairly useful when dealing with initialization issues.

Mmh... I don't but your arguments are correct. I should think of it a little bit more. I currently use the final keyword only when I really need it : to declare constants and when I need to access some local variable from an anonymous inner class. The only pros I see in my way of doing is that when you see some "static final" in my code you know immediately that I am declaring a constant (so if by chance I forgot to uppercase its name you see it too ), while any "final" keyword used within a method means that some anonymous inner class is coming very soon in the next few lines. Those are probably little pros compared with what you just explained.
Just one more question. Do you call super() yourself within constructors or do you let the compiler doing it for you ? I call super() myself but I wonder now if it's OK, seeing (I just checked a few sources) that Sun's engineers don't.
Best,
Phil.
PS: Andrew, it would be great if you could give me your own opinion about this too. Just to get adviced by both moderators ... Thanks in advance.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now more surprising that the lack of any "official" rule, it seems that Sun has no clear rule at all in that matter
What's wrong with that? Not everything needs to be specified in a rule. Option 3 is a mishmash of two styles anyway, so why should they spend time trying to define it more precisely? Look at it this way - the official rule is that you can do whatever you want in this department.
Do you call super() yourself within constructors or do you let the compiler doing it for you ?
I usually let the compiler do it, but I don't care much either way..
I call super() myself but I wonder now if it's OK, seeing (I just checked a few sources) that Sun's engineers don't.
Calling it yourself is just fine, IMO.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, I prefer option #3, just because Jim does (Have you bought Rush in Rio yet, Jim?). and I option #1 is my second choice. I prefer to declare values at the moment it is needed. But if you look at my GUI code, all but the Menu items are all assigned values immediately before the c'tor.
Mark
[ October 21, 2003: Message edited by: Mark Spritzler ]
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Mark. Just because I forgot to tell them, my own preferences are #3-#4-#1-#2.
Best,
Phil.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Phil
My preferred way is 4 then 3.
I understand the argument for not coddling junior programmers, but it is not just that - there is also the case that if I explicitly declare the variable has it's default value then you know what my intent is. It doesnt matter whether either person is a junior or senior programmer - as long as the variable is not declared, there is the possibility that the person reading my code will spend time determining whether the default value is the correct value or not.
I am influenced by my years of writing C code, and getting burnt because C does not have default values. And there is nothing worse than trying to track down a bug that is always repeatable when running live, but cannot be repeated in the debugger, just because the debugger sets default values that are not set in the runtime environment.
Regards, Andrew
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Andrew.
I am influenced by my years of writing C code, and getting burnt because C does not have default values.

I didn't think of it (because it's so far awy now - I stopped with C/C++ in '95 when I started with Delphi), but my few hundreds of thousands of C++ lines may still influence my way of coding.
It seems that is a question of personal taste (except that nobody seems to like #2).
Consistency is probably the most important thing in that matter. Afterall, the whole project is supposed to be coded by the same programmer. So if I don't refactor a bit, there is a risk that the grader will not understand that I am not now the same java programmer as I was when I started the project.
Best,
Phil.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic