Women in Technology

Article:		Seven Low-Cost Ways to Improve Legacy Code
Subject:		Heuristics vs Rules
Date:		2004-06-09 14:57:57
From:		Kevin O'Neill
One issue I have when presenting these sort of things to junior developers (or even seniors who have lost their way :)) is to make them understand that these this represent "rules of thumb" as apposed to "rules of law". I'm interested in the following statement. Every parameter to a method should be declared final unless the parameter is intended to be an out or in-out parameter. Now am I a big user of final but I don't understand how it effects out or in-out parameters. Even if the instance reference is declared final it's contents can be modifed. In fact for out or in-out parameters (ie parameters whose internal structure you are going to modify) you should always declare them as final to ensure that method code does not change the refered to instance. Or is there something that I'm missing?

Showing messages 1 through 3 of 3.

• Heuristics vs Rules
  2004-10-27 15:39:47  dubwai [View]
  
  
  No, you are not missing anything. Making the parameter final has no effect on anything but the method body. Generally I don't bother with setting variables final except in setters or constructors (i.e. when the parameter and a member could be confused) but I guess if you are paranoid it makes sense to always do it.
  
  Regardless, Java is always pass by value so the author's comment is very odd. I'm actually quite concerned by it. Any intermediate Java developer knows there's no 'out parameters' in Java. At least not directly.
• Heuristics vs Rules
  2004-10-28 08:23:12  Robert Simmons, Jr. | [View]
  
  
  That is correct. Using final affects only the compile phase. If you choose to call this "paranoid" that is your choice but it has saved me COUNTLESS hours of debugging and it is a rather easy habit to acquire. I put it to you, "do you loose anything by making them final"? Since the answer is clearly no, there is no reason not to take advantage of cheap insurance.
  
  As for my comment, I can see how it would be confusing and should be cut. I cant think of a way to rephrase it to get across the meaning which would be pretty redundant given the previous sentence. Basically I meant that the only time you shouldnt make it final is when you have some reason for wanting ti to be that way on purpose. Those instances are very rare in my experience.
  
  Thanks for the comments and corrections. =)
• Heuristics vs Rules
  2004-10-28 08:37:52  dubwai [View]
  
  
  No you don't lose anything by doing it and in fact I've decided that if we could go back an design Java from the ground up, all parameters should be implicitly final. The only advantage that non-final parameters give is that you can reuse them as locla variables. That is, there's really no meaningful advantage at all.
  
  Marking the parameter final is a useful technique. It's the only way to compile check that you are not making the "setting the parameter instead of the member" mistake that 'every' developer has made. But I've never had it help me when the method is not setting a member of the class or instance. I'm not really sure how it would.