The next step would be dumping out partial UML diagrams for a whole set of names so you can get a quick overview of how TransactionalWrapper, ClientTransactionalWrapper, and PrototypeClientTransactionalWrapper interact with ThreadVisitor, InfoThreadVisitor, and PrinterInfoThreadVisitor.
They must be using injectors, of course. No need for factories.
I more surprised by the absence of XXXManager, XXXStore, XXXProvider, and also AbstractXXX, not to mention XXXStoreProvider and XXXStoreManager, and maybe DefaultXXXManager too (which is the default implementation of XXXManager (which is an interface), and also the only implementation of XXXManager that will ever exist by virtue of XXXManager being incredibly specific anyway).
The mistake Java makes is to make everything a noun. Types should have short names. Functions should have long descriptive names. Variables can have single letter names.
It's an old convention that comes either from Fortran or math (sums/matrices). Depending on how long a for loop is, more descriptive names can make sense.
I’m not sure what you are implying. This is not a problem you’d notice if you use this pattern yourself, but something that makes code harder to read for people that don’t.
A fine criticism, but surely you see that you first made a comment about the author themselves not being able to read their own code, I replied about that, then you said it wasn't something the author themselves but about other people.
Come on, folks. It's a culture thing. If your loop body is 20 lines, fits trivially on a single editor window, and starts with a declaration of a counter named "w" (for "worker", or "width" or whatever obvious thing it's referencing), that's Just Fine. No reasonable reader is going to have trouble with that, and you know it. Decades and decades of extremely maintainable[1] code has been written in that style. Aesthetics are just aesthetics. Write to the style of the project you're maintaining, and just let the argumentation go.
[1] And more to the point: extremely maintained. You're really going to put the code quality of your Java WhateverFactoryListenerRepository class, that will probably be rewritten by some new hire in 2025, down against a Linux kernel file that has been under continuous improvement since 1997? Because of variable names?
I agree that one letter variable names sometimes make sense. I’d use w for width if the function is short, has a very limited number of variables, w is limited to the scope of the function and not an input parameter, and w is used multiple times.
I had an annoying bug a couple of weeks ago. I had an array of ongoing events, and an array of time windows (roughly, quarters or years). I wanted to generate the cross-product of events and windows, evaluate some metric for each combination, and total the metric per time window. So, i wrote a pair of nested loops over the two arrays, calculated the metric in the inner loop, and accumulated it into a third array with a slot per time window.
Except i had called the loop variables i and j, forgot which way round i had nested the loops, and used the index into the event array to select a slot in the accumulation array. I was baffled as to why my results were completely wrong, but totalled to the right amount!
Once i realised what i had done, i renamed the loop variables to eventIdx and windowIdx. This is far better.
Why would it be such a good idea to obfuscate the semantics of three different loops (i,j,k) instead of writing “userIndex”, “addressIndex”, and “charIndex”? With “j”, I have to lookup its meaning constantly. If I need to scroll to understand the meaning of a variable, then there is room for improvement in my opinion.
You're right that they're terrible names, and that giving them names that describe how the counter is being used would be better
and
Since they get used as loop counters so much you at least know that they're being used in a loop. It's not much info, but at least it's something. (The grandparent's suggestion of 'a, c, w' (or whatever) tells me _nothing_ :) )
Write Kotlin instead so you can have a method named `this method will calculate the sum of two integers`!
I don't think Java has a naming problem per se, I think the focus on inheritance and other OOM principles just make it very easy to overengineer your solutions.
Things like getters and setters (and the fact Lombok still isn't just part of the language itself) annoy me much more. At least records fix some pain points.
I’ve personally enjoyed using Immutables even more than Lombok. It produces generated java classes instead of a JAR when you build so it’s easy to view.
You tell me. Seems like most functions can be eliminated and just replaced by comprehensions or a series of map, reduce, filters, sort, comparisons, etc, with small operations applied per element.
Sure, they could. But I find naming these things explains to future users the point of why you're applying all of these functions. A chain of 10 filters / maps / comparisons / etc... do 0 to explain why a program cares about doing those things.
If it is a true pure function that has already been proven and tested to be correct, you only need to be concerned with the output. The function itself will never have side effects you need to understand nor will it ever change.
Requirements change. I need a function that takes the same input, but the output is no longer valid. But I can't look at this "incredible pure function" and figure out how to do that.
I was disappointed to see this is just a cheap joke. I'd actually be interested to see how well one of the new LLMs does, if you give it a description and some of the code and ask it to name the class for you.
Naming is hard. I think it'd be pretty neat to write the code with a placeholder for the tricky names and then let an AI suggest them once it's done.
The reason naming is hard is because the author didn't know what they were making as they were making it. For the AI to name it well it would first have to rewrite it and separate distinct salient concerns which spans both the implementation and real-world domain spaces.
I could see it operating on a natural language description of what you're going to write. I just tested this with ChatGPT and it was able to give me a set of design pattern-based classes that would probably fit in enterprisey Java codebases.
Suggest better variable and method names in the following Java code. Don't list the new code, only the changes, in the format "oldName" => "newName". You can also suggest multiple alternatives in the format "oldName" => "newName1" or "newName2"
In my experience, 90% of the proposed changes are bad, but occasionally it does have good ideas.
Of course, you shouldn't upload your company's code to OpenAI, but you can try it out on open source or experimental projects.
Funny as this idea would do on a real try a much better job than most software developers are doing without such assistance. I wish to run such tools over most projects i've encountered to clean up the crap colleagues (and myself) have come up with.
Surprised to see a project i made twelve(!) years ago on the front page today. Just to make it clear: this was most definitely a joke, and not an AI at all. It's just random words thrown together, which was kind of the point i was trying to make about some Java developers naming their classes ;)
50 comments
[ 4.1 ms ] story [ 95.7 ms ] threadI more surprised by the absence of XXXManager, XXXStore, XXXProvider, and also AbstractXXX, not to mention XXXStoreProvider and XXXStoreManager, and maybe DefaultXXXManager too (which is the default implementation of XXXManager (which is an interface), and also the only implementation of XXXManager that will ever exist by virtue of XXXManager being incredibly specific anyway).
> I wonder if the original author will be able to understand their own code in a few weeks
As the original author of plenty of this code, I'm reporting no problems 1300 weeks in.
[1] And more to the point: extremely maintained. You're really going to put the code quality of your Java WhateverFactoryListenerRepository class, that will probably be rewritten by some new hire in 2025, down against a Linux kernel file that has been under continuous improvement since 1997? Because of variable names?
Except i had called the loop variables i and j, forgot which way round i had nested the loops, and used the index into the event array to select a slot in the accumulation array. I was baffled as to why my results were completely wrong, but totalled to the right amount!
Once i realised what i had done, i renamed the loop variables to eventIdx and windowIdx. This is far better.
and
Since they get used as loop counters so much you at least know that they're being used in a loop. It's not much info, but at least it's something. (The grandparent's suggestion of 'a, c, w' (or whatever) tells me _nothing_ :) )
What alternatives do you have in mind?
I don't think Java has a naming problem per se, I think the focus on inheritance and other OOM principles just make it very easy to overengineer your solutions.
Things like getters and setters (and the fact Lombok still isn't just part of the language itself) annoy me much more. At least records fix some pain points.
(Currently replacing a Java application with one written in Go).
https://immutables.github.io/
been a while since I read the BNF of Java, don't seem to recall this.
They can types, but most of these "classes with funny names" are more often than not just a logical grouping of functions.
It's probably more informative to view them as a bundle of parametrized functions, than as a record of data.
Even functions don’t need names once they are small and pure enough.
Alas, we still cling to names.
Naming is hard. I think it'd be pretty neat to write the code with a placeholder for the tricky names and then let an AI suggest them once it's done.
Suggest better variable and method names in the following Java code. Don't list the new code, only the changes, in the format "oldName" => "newName". You can also suggest multiple alternatives in the format "oldName" => "newName1" or "newName2"
In my experience, 90% of the proposed changes are bad, but occasionally it does have good ideas.
Of course, you shouldn't upload your company's code to OpenAI, but you can try it out on open source or experimental projects.
I have since found that Java itself steers developers in this direction and this type of naming is actually quite natural when working with Java.
That being said, I still find it really amusing. Kudos to the person who made it