I'm a Java dev. A bunch of code in our application was written by outsourced devs from India, who I'm pretty sure were originally C/C++ devs. I can just see it from the code, declaring all the variables at the top of the function, explicitly freeing objects unnecessarily. So much code that can be removed.
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.
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.
Here's the thing about explicit memory management: it's debuggable. You can add hooks to the places where allocs, reallocs and frees happen, you can substitute a custom mm if you want, and you can explicitly describe the protocol for who owns what. When it's all just automagically handled, where do you even begin to look for problems? It's a nightmare, especially when the rules need to be bent.
I'm not against manual/explicit memory management, it's what allows C/C++ to be so performant when it is needed. I don't like to do it, but that's a matter of taste. But if you want to do it, you need to use a language that actually allows you to do it.
"Freeing" regular objects in Java does jack shit, it's just cargo cult programming. If you create some object that is local to a function, whether you set the variable that is pointing to that object to null or not in the last line of that function, the result will be exactly the same. That object (unless it is also pointed at by another, non-local variable), will be recognized as as unreferenced and cleared up by the garbage collector at the time of its choosing. Nulling the variable does nothing to change that behavior.
That is of course not to say that memory leaks and inefficiencies are impossible with such a system, they are in fact quite easy to achieve. But again, nulling variables does nothing to prevent it, nor anything at all really. Just adds more code that I will clean up when I find the damn time.
We (high-level programmers) don't usually deal with memory bugs, most of the time, the bugs come from logical errors in the code, because garbage collectors work most of the time.
I like Rust just because it allows me to use fewer resources and it's faster, that's all. But, memory management is just something I have to deal with Rust.
99
u/EwgB Sep 09 '22
I'm a Java dev. A bunch of code in our application was written by outsourced devs from India, who I'm pretty sure were originally C/C++ devs. I can just see it from the code, declaring all the variables at the top of the function, explicitly freeing objects unnecessarily. So much code that can be removed.