Plus, and don't forget about this,
otherwise you'll end up spending lifetimes
to fix your program in case there is error.
If variables are declared at the top of the methods,
then all the error conditions and variable values
could be seen if you set a breakpoint in correct place
cause they won't go out of scope.
Especially if you have the exceptions in that method,
as if they are hit, you are COMPLETELY out to lunch,
and it would take you lifetimes to figure out WHY
that exception was hit if you are using declarations
deep inside the method. I even avoid using things like
for (int nInd = 0; nInd < limit; nInd++)
Instead, i do
int nInd;
for (int nInd = 0; nInd < limit; nInd++)
{
...
}
So, if i have an error condition inside for loop,
i can see which exact element caused it,
even if i am thrown out of the scope of the loop
by some exception.
I absolutly hate "code reviews".
It simply means that there is some smart ass,
sitting on the top of a bunch of dummies,
telling them how screwed up they are,
and all it produces at the end
is guilt, leading to fear
to lose onse skin.
Instead of those stupid "code reviews",
you just work within a group and maintain
a constant feedback and exchange the ideas.
I know plenty of those rules. But as far as end product goes,
those "rules" do not cover about the most subtle issues,
and especially the maintainability and future code modifications.
Long subject.
I know, I know.
:---}
It is called scitsophrenia.
In one situation you think like this,
and in another situation you think like that.
No wonder...
Yep. I like those "shoulds",
the byproducts of a rigid mind.
Now, on what basis should we limit the scope of variables?
What does it improve?
Not that I do not see what you mean,
but you need to be able to put the WHOLE thing
in perspective, and not only in terms of your
ideology, but the debugging process, code extensibility,
maintenance issues, code simplicity and readability
and all sorts of other things.
The rules of:
THOU SHALT LIMIT THE SCOPE OF YOUR VARIABLES
is simply incomplete of a statement.
There are no ifs and buts in it.
So, it is not programming.
It is totalitarian dictatorship
of black and white.
Programming is a pure logic,
as THAT is where all the intricacies come in.
If you use this black and white model,
your program will be the most oppressive thing there is.
To the user, to the programmer and the rest of them
mortals that come its way.
Uhu.
And what happens if you hit an exception
during debugging?
Ever thought?
Can you look at those variables inside some loop
and see what EXACTLY happened?
How long will it take you to fix bugs with this approach?
How many times you would have to recompile
and how many source files you'd have to go thru
to see where is the error?
You see, looking at the source is not the same thing
as looking at the state of your program and variables
in RUN time.
Cause what you THOUGHT MUST be happening,
for some strange reason, do not happen.
And, usually, it is the simpliest things imaginable
that break your royal code.
Which is about the most foolish thing to do.
Just recently, i was lazy enoug to declare my
variables in one lengthy operation where a number
of files are opened and, in some cases, a single
statement would cause the entire file load and parsing.
The error would happen after tens of minutes of operation
and, once the exception was hit, i did not have a SLIGHTEST
clue what exactly was the reason for that exception.
Once i moved the declaration on the most outside scope
of method, i could see that error within seconds.
Hows THAT for lesson in programming?
It all depends.
Sure, you are guaranteed a better memory dealocation
and sure, you may avoid some subtle bugs if you initialize
the variables on the most outside scope and, later on,
use them when they were not properly set in the inner levels,
and, instead of compile time errors, you get run time exceptions.
No question about it.
But this is just the BEGINNING of a story,
and not the end.
Well, BOTH are correct
and both are wrong.
Because you need to specify ALL the conditions
and ALL the tradeoffs.
To general to even consider.
I doubt you have enough evidence for stability,
and i do not even attempt to figure out what those
"engineering benefits" are in specific terms.
"declare at the top of the block" dictates
are no different then "use bracess this way" dictate.
You can hit me with a sledge hammer,
but i will still use the braces on the next line,
and i have a REASON for it, you see,
and the reason is simple enough to a mere mortal to comprehend.
If you use braces at the end of a line,
you can never be certain if you put them in the
right scope, especially in nested "if else" clauses.
I'm happy with either approach and would go with either project standard
without argument. I used to declare variables at the top of a block in
the Algols and do like the scope limitation that provides: I guess that
too much C has stopped me using it. I must try harder.
First of all, if you declare variables at the very beginning
of you method, you can review that code and see if some
variables and, therefore, some operations are simply overkill,
or you are doing some extra work on a method level that would
not have to be done if your code was more structured.
So, by sheer fact that you have some variables,
it indicates that you do some operations that NEED those
variables, and you can see that you might be using several
variable to carry the same exact information except in
a slightly different context, and so you can fix that code.
As far as memory management goes, it is true that the memory
deallocation may improve if you declare those variables
on the deepest scope possible as in that case,
the deallocation is pretty much automatic.
But again, that is just a beginning of the story,
and not the end.
The layout standard I've seen that I really don't like is the custom of
declaring class-level variables after the methods. Why reverse the
standard used inside blocks and methods other than sheer perversity?
Well, i must be a pervert then.
I agree with you that it is better to move it in front,
generally speaking, but some methods have so much stuff
attached to them that it takes you quite some time
before you see the constructor code, which is about
the FIRST thing i want to see.
Then, after contructor code, i like to put the highest,
possibly thread level methods, such as start, stop, run,
Terminator (ever heard of such an animal), and things
like that.
Then, I'd like to see the main method, starting the
whole operation.
Then, after it, i like to see the more fine grained
methods.
And, about the LAST thing i want to see, is the even
handler code. That comes as just about the LAST thing
in that class, and the beauty of it, i know EXACTLY
where i can find it, even if i do not remember the
exact name of some variable or method,
which is an art on its own.
I can remember just about every single method or
variable in a pretty complex program, just because
of naming convention i use.
I can see what the methods do simply by looking
at the variable names those methods use.
And, the LAST thing i want to see is...
Tada!
The VARIABLES, in bulk.
But even there, they are all nicely sequenced
and the first in order come those of the most
outer scope and meaning, the MAJOR variables,
that could correspond to entire complex classes,
frames, etc.
Then comes the file level variables, file names,
handles, etc.
Then come the groups of related variables describing
some logically related operations or constructions.
Then comes the miscellaneous stuff, which i periodically
look at to see what kind of garbage is there
as there should be none on the first place as just about
all the variables should be decleared on more local
scope, otherwise you have a database consistency issue,
when several different methods access the same global,
and, in some cases, one hand does not know what the other
is doing.
As a general rule, I use as little globals as I can manage.
So far, my stuff runs, compiles, extends, and maintains
like a tank. Try to kill it. Even if you unplug the power
cord, in the middle of a file operation, I'll recover,
as long as operating system can recover the damaged file.
:--}
