Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Representing the Impractical and Impossible with JDK 10 “var”

benjiweber.co.uk

Post reply on HN
Print view View original

11–20 of 131 posts

Re: Representing the Impractical and Impossible with JDK 10 “var”

#11

Post by skybrian »

pents90 wrote: post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

This is an old argument. A counterargument is that if the IDE can auto-insert the type for you, it could also show you the type on demand.

But this assumes that when reading code, you're always using a tool that can show you the type. Auto-inserting is only needed when writing.

One thing to be wary of is that even when the compiler shows you the type, (in an error message, for example), if it's complex, it will be difficult to understand. If you want to write simple code, perhaps it's better to avoid or encapsulate complicated types?

Re: Representing the Impractical and Impossible with JDK 10 “var”

#12

Post by Marazan »

pents90 wrote: post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

Reading long nested generic type declarations in Java is an absolute utter mental pain. Being able to vat that shit will be a god send.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#13

Post by rzzzt »

extrememacaroni wrote: post #10
arcticbull wrote: post #8

Earlier quoted context omitted.

I'd suggest that means your `getAddress()` name could be improved to convey the necessary information.

`getAddressWhichIsOfTypeString()`? `str_GetAddress()`? `GetAddress_STR()`?

aGetAddress()

Re: Representing the Impractical and Impossible with JDK 10 “var”

#16

Post by trixie_ »

pents90 wrote: post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

I'm pro var

* I write code a lot more fluidly with var. When I go back to writing non-var code (enforced by some departments) I find that it breaks my focus on solving the problem at hand. I end up writing my code with var and then going back and replacing my vars with the type names.

* I find code a lot easier to read. I can understand the flow of the logic easier, the variable names are enough. Unless you have the type definition memorized, just knowing the type isn't going to help you much. You're going to need an IDE either way.

* Refactoring is easier. For example, changing the return type of a function from array to list means a lot less code needs to be changed as a result if the callers were using var. The compiler will tell you if there's any instances where a caller was using an incompatible property.

* Reviewing is easier. Your change set is a lot smaller when changing a type name.

Seriously you won't miss it when it's gone. People also used to prefer Hungarian notation.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#17

Post by bcoates »

pents90 wrote: post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

Maintenance programmers already have to deal with concealed mystery types, every time you do

   f(g())
it's just syntax sugar for

   var temp = g()
   f(temp)
Now at least programmers aren't tempted to do gratuitous function nesting rather than introducing a variable just to avoid cluttering code with an unimportant type name.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#18

Post by jbooth »

Marazan wrote: post #12
pents90 wrote: post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

Reading long nested generic type declarations in Java is an absolute utter mental pain. Being able to vat that shit will be a god send.

Then you're dealing with long, nested invisible type declarations.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#19

Post by trixie_ »

matt2000 wrote: post #3
pents90 wrote: post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

I agree. It seems very clear that code readability is reduced by var-like type hiding. When I'm doing code review and I see "var address = contract.getAddress();" what is the type of that variable? I have no idea.

Address address = contract.getAddress();

Not sure how this helps. I pretty much knew 'getAddress' would return some sort of Address structure. It's not like knowing the type name tells you what properties are on it. So what's the point?

Re: Representing the Impractical and Impossible with JDK 10 “var”

#20

Post by jayd16 »

pents90 wrote: post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

Var makes refactoring way easier while being just as safe and informative.
Post reply on HN