Program Structure

What is the suggested way a program should be structured?
I read that attributes first then methods.

According to Oracle's conventions for Java...

Put declarations only at the beginning of blocks. (A block is any code surrounded by curly braces "{" and "}".) Don't wait to declare variables until their first use...

Ref: http://www.oracle.com/technetwork/java/codeconventions-141270.html#16817

And welcome to the Ranch!

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.

What is "refactoring"?

Try google.

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.

Wait... Are you suggesting there might be differences of opinion regarding "standards"?

Okay, so I don't declare them all up front either (and sometimes feel "wrong" doing that). But at least Oracle's document provides a starting point for questions like this.

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.

-Ninad

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.

Just make sure whatever you do:

1) You do it consistently.
2) You follow whatever conventions your teacher/boss/company tells you to follow.

fred rosenberger wrote:Just make sure whatever you do:

1) You do it consistently.
2) You follow whatever conventions your teacher/boss/company tells you to follow.

Now that I can do...and I guess as long it does not hamper the efficiency and quality you can continue as you are doing.

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 fields
static initialization blocks
static methods
instance fields
initialization blocks
Constructors
instance methods

By instance xxx I refer to the non static members of a class.