this post was submitted on 27 Mar 2025
229 points (99.6% liked)
Programmer Humor
22156 readers
2759 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I think this is just a picky optimization.
The first one runs the constructor to instantiate a new string, then gets its class (which is presumably a static property anyway). The second doesn’t have to run any constructor and just grabs the static class name from the type.
Maybe there’s more implementation nuance here but it seems like an opinionated rule that has zero effect on performance unless that code is being called thousands of times every second. And even then the compiler probably optimizes them to the same code anyway.
It's good practice to get in the habit of coding to only do the things you want/need to do rather than hoping the compiler does it for you.
This particular constructor call may be light, but there may be constructors that have a lot of overhead. Or you might be running alongside 1000 other processes who said the same thing and you start to see performance degradation.
These things add up if you're doing them all over a 1 million line codebase, by which point it's incredibly painful to claw back performance if you need it.
This seems like one of those cases where you don't want to be waiting until benchmarking.
It makes the code simpler anyway.
It's not picky, needlessly creating objects makes the garbage collector run a lot more. Especially if it's invoked frequently like Minecraft recreating the object for every block on the screen for every frame to render. The garbage collector is largely responsible for lag of up to a second occurring at random times.
It's like saying
list.isEmpty()
overlist.getLength() == 0
is a picky optimisation.There's a developer out there who coded this and they obviously don't know what they're doing. One day they're gonna iterate all rows in the database to check if it's empty. You have to flag these issues early and teach the newbies.
Well, it also avoids running instantiation code, which could be doing all kinds of things. In theory, it could have a side-effect which modifies some of your application state or issues a log statement or whatever.
Even if it doesn't do anything wild right now, someone could change that in the future, so avoiding running such code when it's not needed is generally a good idea.