News for hackers. Stuff that matters.
Re:Rating 26 years of Java changes by Traubenfuchs on Saturday October 11, 2025 @04:38PM (#45552488)
It‘s a harmful code smell: It often obfuscates the type, forcing you to actively check for the type and should not be used.
Re:Rating 26 years of Java changes by a57721 on Saturday October 11, 2025 @06:13PM (#45553120)
It is used for things like "Foo x = new Foo()" where the type is obvious.
Re:Rating 26 years of Java changes by newAccount2025 on Saturday October 11, 2025 @04:55PM (#45552628)
Your IDE can do that?
Re:Rating 26 years of Java changes by MBCook on Saturday October 11, 2025 @08:33PM (#45554038)
It can. But seeing the text there is faster than having to hover to see what the type is.

It exists. It’s fine. People obviously like it.

Some don’t, I’m one of them. I don’t see the advantage is very big at all. I don’t think it’s worth the trouble.

But that’s me.

Re:Rating 26 years of Java changes by bigstrat2003 on Saturday October 11, 2025 @09:00PM (#45554168)
Languages should not be designed around the assumption that people use an IDE.
Re:Rating 26 years of Java changes by noisy_boy on Saturday October 11, 2025 @10:46PM (#45554725)
What if I'm just looking at a pull request on GitHub? Sure I can check out the branch etc but that's just adding more friction.
Re:Rating 26 years of Java changes by Traubenfuchs on Sunday October 12, 2025 @06:27AM (#45557048)
Bingo.

Sometimes I doubt most hacker news commentors have ever worked in big corpo environments where you have to regularly review large PR in some broken webapp like GitHub.

Re:Rating 26 years of Java changes by vips7L on Sunday October 12, 2025 @09:36AM (#45558149)
If you haven’t used GitHub plugins in your ide to review you should really give it a try. It’s really night and day.
Re:Rating 26 years of Java changes by Supermancho on Saturday October 11, 2025 @04:54PM (#45552618)
This is what it looks like to me. If you wanted to do this, why not use a scripting language where you can use this kind of practice everywhere? In Java, I don't expect to have to look up the return type of something to discover a variable type. Graciously, I can see how you can save rewriting the Type declaration when it's a function return you want to mutate.

Generally, you save some keystrokes to let other people (or future you) figure it out when reading. It seems like bad practice altogether for non trivial projects.

Re:Rating 26 years of Java changes by guax on Saturday October 11, 2025 @05:53PM (#45553023)
Modern IDEs will show you the type of anything at all times. I do not understand your point unless you're doing raw text editing of Java source.

Those keystrokes are not just saved on writing, they make the whole code more legible and easier to mentally parse. When reading I don't care if the variable is a specific type, you're mostly looking whats being done to it, knowing the type becomes important later and, again, the IDE solves that for you.

Re:Rating 26 years of Java changes by Supermancho on Saturday October 11, 2025 @07:45PM (#45553793)
> Modern IDEs will show you the type of anything at all times. I do not understand your point unless you're doing raw text editing of Java source.

The word "String" "Integer" et al. + "var" is too much real estate for being explicit. Sometimes, I'm looking at the decompiled source from some library that doesn't have a source package available.

> Those keystrokes are not just saved on writing, they make the whole code more legible and easier to mentally parse.

This is incorrect. Repeating it doesn't make it true. For trivial code (<10 lines) probably seems fine at the time. Lots of bad practices start with laziness.

Changing practice because an author thinks a function is small enough when it was written, is a recipe for unclean code with no clear guidelines on what to use or expect. Maybe they rather put the onus on a future reader; this is also bad practice.