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.
This post was brought to you by this PMD rule.
Transcription
Why do we have this stupid code analyzer rule enabled anyway? Nobody writes code like this...
After telling them the lore why it's there:
You have seen such things before?
11 Times, as a matter of fact
Your transcription doesn't have the code in it
Can't wait for all the other horror stories getting posted here :D
I just like knowing which episode this is from and the implication that removing the code analyzer will cause an explosion.
So what is the reason for doing it that way?
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.
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
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() over list.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.
From the linked reference:
Avoid instantiating an object just to call getClass() on it; use the .class public member instead.
Yup, wasted memory allocation to get something that's there already
The first one returns an instance of the class, the second one is a static reference? I don't really know what I'm on about, so the words might be wrong.
Interpreted it the same, but I'm coming from C++
Would it be an instance of the class since the first thing you're doing is pulling the one property instead of the object itself?
I had a coworker who would sometimes not create a method as being static to the class and would therefore need to create a default instance to call said method. "It's domain-driven design."
flake8-simplify has a bunch of rules like that for Python, most of which may be automatically fixed if you're using something like ruff, so you never have to spend time actually fixing it.
Well, you shouldn't have to spend any time actually fixing code found by that rule either. If the time you spent was larger than 0, you are better looking for the cause than making something that fixes it automatically.
So I don't java (or ms java either) anymore. Why can't you just reference the class itself?
the 2nd does that already
in the first you can't, as getClass() is not a static method (wouldn't even make sense if it was)
The GP is saying that String is a class already, you shouldn't have to call String.class.
Personally, I'm away from it for long enough that I don't remember either.
I don't believe there is much deeper of an explanation than "because the Java designers didn't implement support for that".
That feature is called "types as a first-class value" and you need to implement some special casing or an entire system in the language to make it work. Telling devs there's a special static variable .class is conceptually simpler to implement and understand.
Is it simpler tho? You have to explain to someone that the Type is also an Object with the field .class on it. I feel like just saying it's a Type and you can reference Types directly is simpler. Idk maybe I've been currupted by type theory too much lol
Well, I think your idea would be simpler, if we weren't talking about Java.
Pretty much everything is an object in Java. It's only logical that a type would also be an object and have associated fields.
Similarly, what you're thinking of as "reference types directly" doesn't make sense in Java, because it lacks many of the systems to make that actually usable like a type. What you get from .class is a Class object, which you can't stick into a generic type parameter, for example.
It basically uses reflection to give you e.g. the name of that type and you can also instantiate an object of that type, if no parameters need to be passed to the constructor function.
And then, yeah, I think for explaining that you merely get an object which roughly describes the type, the separate .class field is a good idea.