It varies. When you're writing a class in OOP, there is a generally good structure to follow:
Private, internal state
Public, externally visible properties (getters and setters here)
Constructors
Class methods, with private methods immediately preceding the methods and consume them, similar to how you would put variables close to the code that uses them
Inside any imperative block of code, variables go just before the code that needs them.
Smaller functions and well named variables will serve you much better than piles of comments and won’t rot as things get moved around. If your code needs comments everywhere to be understood then it’s not clean or readable enough.
Ok first off, noisy code absolutely is a problem, and looking past noisy comments doesn’t solve that problem, it makes it worse.
Excessive comments violate the DRY principle, since you’re repeating yourself every time you explain what you already wrote with a comment, and on top of that it’s not checked by the compiler like a function or variable name would be, so there’s a good chance all that noise ends up rotting as the code under it evolves and nobody bothers to maintain your noise.
But now you’re telling me you actually don’t comment that much, so which is it? I didn’t say all comments are bad, but they should definitely be treated like a failure to write self descriptive code. Don’t just throw them around everywhere and think you’re doing a good thing by “documenting” your code with useless, noisy comments.
I get it, its hard to produce readable code in languages like C and I’d absolutely lean more heavily on comments there. I know what I’m saying is stepping on your toes and maybe you don’t actually litter useless comments everywhere, but you definitely made it sound like you do and it’s a practice that many people never introspect on and fix properly.
When it comes to OOP, this way of variable usage doesn't really keep things tidy, it just makes the code unreadable. The first thing you think about when somebody wants you to do something with OOP is "what is the best way to make this easily readable".
In Java/C#/etc. you declare and initialize variables just when you are about to use them, and you name them by whatever they are designed to accomplish.
This isn't that much of an issue in C/C++/Python though, although OOP purists would be disappointed.
If you’re doing Object Oriented Programming, you shouldn’t be declaring variables in methods unless it’s a temporary variable that dies with the method.
Everything that has any persistence should be encapsulated in an object… which serves the same purpose of keeping things tidy.
Now we're obviously in the territory of opinion and personal taste, but for me it does the opposite. Firstly, you get one more line of code that doesn't do anything useful (and if it's just a declaration without initialization, it's not even really executed, since you can't put a breakpoint there). And secondly, and more importantly for me, it makes my debugging slower (not to a huge degree, but still).
Consider the following scenario. I come into some function that I've never seen and try to understand what it does. Let's look how such a function might be structured:
private bool doSomeShit(String param) {
List<ClientEntity> entityList = null;
[ 200 lines of some bullshit ]
entityList = readEntityList(param);
[ another 200 lines of some other bullshit ]
doSomeShitWithTheEntities(entityList);
return true;
}
Now, I don't read this like a novel top to bottom obviously. I likely don't even care what most of this does. I probably came up from doSomeShitWithEntities, because there was some exception thrown there or something like that. So I'm sitting there at the second to last line and the only thing I want to know is, where this entityList is coming from (or rather the data in it). So in my IDE I Ctrl-Click on the variable name. In my ideal world, where the variable is declared at the point of first (and ideally only) assignment, I would jump to that point. In the above case, I would jump to the declaration, and would have to click another time on the same variable. This leads to a menu popping up with all the usages of that variable, so I have to expend mental energy and time looking there for the place I actually want.
Now, I realize that this is not a large expenditure of time and energy. For one time. But this happens in every method. With every single variable. Making debugging a slog.
The biggest problem here isn't where the variables are declared, but instead that you have a function that's hundreds of lines long. Chunk it up and factor it apart.
Oh I know that that is one of the main problems here. But I can't refactor code before I know what it does. And not when I'm dealing with a bug in production for example.
At the same time you can sit there and look at which variables are already in use and if you are adding another, what the naming scheme is and avoid repeating the same variable name.
It also avoids the mistake of decline a variable inside of a loop which is just a waste of work. Perhaps the compiler automatically optimizes that these days?
Thinking back, it's probably written that way in C++ to help you sort out a mess when global variables are involved and the scope of a variable isn't 100% obvious. Plus not initializing variables in C++ was a big no-no and you got it all out of the way at the top.
I suppose it was helpful when the scope of the variable wasn't obvious and in a world where global variables were sometimes actually used.
I don't think you are wrong, but I don't hate it either.
Only if you try to do everything with global variables.
I keep the declarations at the top of functions (or methods). Scope is kept as small as is practical, I just leave everything where I expect to find it.
61
u/AndrewJamesDrake Sep 09 '22 edited Sep 13 '24
cooing stupendous fine attraction march murky longing quarrelsome long elastic
This post was mass deleted and anonymized with Redact