AI to name your Java Classes | Hacker News Reader

AI to name your Java Classes

projects.haykranen.nl

51 pointsghoshbishakh50 comments

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 ;)

AI basically just means software at this point.

To paraphrase Marx, "AI fads appears twice, first as comedy, then as tragedy"

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.

Here's a tested ChatGPT prompt:

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.

Such a missed opportunity, the project itself could have had a name like AIGeneratedJavaClassNameFactoryImplementation.

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.

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.

https://immutables.github.io/

Exactly ! In my experience OOM certainly seems to be a Java key principle.

(Currently replacing a Java application with one written in Go).

It's probably a mistake to think of Java's classes as being types.

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.

Everytime I see i,j,k as variable names, I wonder if the original author will be able to understand their own code in a few weeks.

Probably the worst example since those are pretty canonical as loop counters. Try a,c,w,z.

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_ :) )

In over 25 years of doing that I've yet to encounter a problem so idunno, maybe your model of something here is drastically off.

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.

To be fair, I find every code style that isn't my own harder to read than the style I prefer myself.

I directly replied to your post saying:

> 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.

Thanks for replying, but it seems you missed the second part of my comment.

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.

outer, middle, inner loop variable, not hard,

i can be an iterator as well, if 3 used together - definitely 3 nested loops... or 2, and k is key in a Map. The gp jab was unjustified.

I don't remember using anything else in a for loop.

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.

Why? That makes very little sense in an OOP language. E.g.

   var v = new VeryLongClassName();
   v.op1();
   v.op2();

Alternatively:

   var v = new VV();
   v.veryLongMethodName1();
   v.veryLongMethodName2();

More code for the second option, doesn't increase readability.

> The mistake Java makes is to make everything a noun

What alternatives do you have in mind?

> The mistake Java makes

been a while since I read the BNF of Java, don't seem to recall this.

I mean java as it is used in the real world, not java the spec. I think you know I meant this too :)

I first saw this years ago, shortly after starting my first professional Java dev job, and I thought it was hilarious at the time.

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

Thanks!

What’s the name of design principle: “If you can’t name it, it shouldn’t exist”?

I know of an opposite principle: if you can point at a pattern in your code and name it, it means it's not sufficiently abstracted.

Names are mostly for humans. In functions with limited scopes there should be no need for names beyond single letters.

Even functions don’t need names once they are small and pure enough.

Alas, we still cling to names.

Is the function doing something I care about? If yes, the name should tell me what that is. If not, why's it there at all?

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.

how do you plan to refer to these nameless functions when they are reused multiple times?

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.

Wow. I’m impressed at how lean your architecture is. No Factories?

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).

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.

Now if it could automatically rename the classes in my many LOC project!

Reply on news.ycombinator.com