This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Oracle is, of course, wrong on this one. Declaring variables as close as possible to their use makes it easier to spot refactoring opportunities. Maintaining vertical locality is very useful for readability and comprehension.
David Newton wrote:Oracle is, of course, wrong on this one. Declaring variables as close as possible to their use makes it easier to spot refactoring opportunities. Maintaining vertical locality is very useful for readability and comprehension.
I agree. The whole "declare your variables at the start of the block" is a remainder from the "old" C days, where you couldn't declare variables anywhere you wanted.
I agree with Marc here. Even I declare the variables at the beginning of a code block, it allows me, and most of the times others, to "read" my code properly without disrupting from the flow of the program.
It might be an ancient method, however, works perfectly fine for me.
Don't walk as if you rule the world, walk as if you don't care who rules it...
But it *doesn't* allow you to read the "flow" properly--that's the point. Unless your method is very, very small, you have more information to hold in your head as you read, otherwise you'll flip back up to the declarations to see the type, or to check if it's initialized, or... It also obfuscates the meaning of code chunks: if all the variables are declared at the top you have one less way of reasoning about the dependencies of the code you're reading. This reduces the ease of refactoring, in at least two ways: (1) it reduces the chances of spotting groups of functionality that could be extracted, and (2) If using an IDE to extract the method it'll pass in variables declared at the top of the method rather than having them be a local in the extracted method, creating more manual work.
And how does declaring it where it's used, which adds either (a) nothing, or (b) a single word, to the token stream break the flow?
If the method is, say, ~10 lines long, I could almost argue it's fine declaring them at the top. Almost. Mostly all it does is add unnecessary noise to method, reduces the ability to reason, and creates additional manual labor during refactoring.
Well, if you are using Eclipse, then you have an option of sorting the members. It will be found under the Source Menu. Eclipse comes with a predefined sorting order - Of Course you can modify it to match whichever standards you are following
This sorting will sort the members of a class and not the lines inside a method though. From the default configuration from sorting of Eclipse, you'll find the static members are placed before instance variables.
Roughly the structure is
static initialization blocks
By instance xxx I refer to the non static members of a class.
SCJP 1.5 | SCWCD 5 | SCJP 6.0
[url]http://a2zjava.webs.com[/url] - Online training for Java/JSPs and Servlets/SCJP/SCWCD