Women in Technology

Article:		Seven Low-Cost Ways to Improve Legacy Code
Subject:		Heuristics vs Rules
Date:		2004-10-28 08:23:12
From:		Robert Simmons Jr. (Kraythe)
Response to: Heuristics vs Rules
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. =)

Showing messages 1 through 1 of 1.

• 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.