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.

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

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

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/

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

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.

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.

I directly replied to you 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.

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

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.

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

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.

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.