• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Programming style question (inline variable declarations)

scootermaster

Platinum Member
Simple question:

I usually avoid inline variable declarations, and prefer to stick them at the top of my function. Probably for cleanliness' sake, and probably because I started with C, not C++.

But I notice sometimes I wonder if a variable was initialized, or [egads] what its for, or what type it is and stuff. Now, hopefully a lot of this can be gleaned from context and the variable name (I'm getting better about calling things "arrayIndexCounter" instead of "temp") but in some sense, it makes sense to have variables that are just going to be used "right now" (i.e. as I'm coding) declared right before I'm using them.

So the question is whether or not this is considered bad form (or maybe I'm so out of the loop it's considered bad for not to? Who knows?)
 
Some languages (such as delphi) force the "every variable at the top of the function" setup. I personally am not a big fan of it. I feel code looks cleaner when variables are initialized as late as possible. That way, you know the basic locality that a variable is being used in.

I don't think it is considered bad form, for small functions it may even be desirable, but for larger functions, I like late variable declarations. Nothing is more off putting then to see a function with 5000 variables declared at the top.
 
The only variables I don't declare at the top are variables that don't hold 'important' data. For example say I suddenly needed a counter variable to see how many times I ran a loop.
 
I'll swim against the current and say that I prefer to declare variables with minimum possible scope, whenever a language allows me to do so.

Minimum scoping reduces the chance that old values will accidentally pollute new computation (e.g., though an omission of a re-initialization), minimizes local stack pressure, and improves data locality.
 
I find it depends, sometimes I just need a temp variable to put something in for a single section of the app. i want such variable to have the least scope possible. For example, something like this:

int tmp=0;
while(getdata(tmp))dostuff(tmp);

Where getdata() actually returns true/false but also modifies tmp. It would be silly to declare tmp at the top. Though, if I need to keep reusing it as a temp variable, I could see value in doing that. Just need to be careful.
 
I tend to agree with sourceninja. I think it looks cleaner with as many variables as possible declared at the beginning. However for temp/scratch variables with limited scope I don't see anything wrong with declaring them there.
 
In general, keep the scope of a variable name as limited as possible. In cases where the language provides tools for sub-local scoping, use them.
 
In general, keep the scope of a variable name as limited as possible. In cases where the language provides tools for sub-local scoping, use them.

Yea, I don't mean to say everything is global. Just declared at the top of where it is used (top of the method, top of the function, etc)
 
For C/C++ I declare "important" or often-used variables at the top, but will often place variables used in just one loop right above it, as a kind of global / local separation even though they're technically in the same scope.

The fake-local variables are generally counters or scratch buffers. If it didn't look ugly I should probably wrap the one loop and its variables with { } to really create a local scope.
 
The smaller the scope of a variable, the easier it is to debug, IMO. And having variables declared at the top makes the code look cleaner.

That said, I think it's perfectly all-right to have temporary variables declared in the middle. As long as they are temporary. A rule of thumb, is that if you need to access a variable a page below where it's declared, then you'd better move its declaration to the top.

Back in college, it was an amusing scene figuring out how people's code worked, only to discover a "temporary" variable evolved into a "critical" variable. 😀

-chronodekar
 
I'll swim against the current and say that I prefer to declare variables with minimum possible scope, whenever a language allows me to do so.

Minimum scoping reduces the chance that old values will accidentally pollute new computation (e.g., though an omission of a re-initialization), minimizes local stack pressure, and improves data locality.
This, hands down. A knowledge of assembly language and compiler construction is helpful in understanding.

Cogman, two posts before you, agrees with you. So, it looks like you'll have other salmon to swim with.
 
I notice a trend between database-centric coders and web-centric coders. Those from the database realm seem more likely to declare variables first while the web-centric tend to declare variables within the local scope.

I go both ways and don't see any reason to only go one way or the other. Declaring variables all at once looks cleaner and (along with good commenting) allow a better readability of the code. Late variable declaration (also along with good commenting) makes the code easier to debug.
 
Studies have shown (will provide details if I can be bothered, currently typing from in bed) that declaring variables as close as possible to where the variable will be used leads to more correct code.
 
Studies have shown (will provide details if I can be bothered, currently typing from in bed) that declaring variables as close as possible to where the variable will be used leads to more correct code.

It's basically just modularity and decoupling, which I think all will agree are proven to be a Good Thing. Programmers sometimes don't think about scoping past the level of a method body, but most languages provide tools for lower scopes now. I can't see why anyone wouldn't use them. If you only need a variable in a particular try block, for example, declaring at method scope would be the equivalent of moving a method scope variable up to class scope. Doesn't make sense unless you really need to share it across the whole scope in which it is declared.
 
Studies have shown (will provide details if I can be bothered, currently typing from in bed) that declaring variables as close as possible to where the variable will be used leads to more correct code.

No arguments here. :thumbsup: The problem is to avoid the temptation to use them in other places too.

-chronodekar
 
Back
Top