undefined | Better HN

0 pointswatwut8mo ago0 comments

There is about zero difference in readability of your two statements, rending var not useful.

And 'var accounts = calculateAccounts(something)' is literally less readable, because now you dont see what exactly accounts is.

Var statement speed up writing, then are either irrelevant or gets rewritten to types for better readability.

0 comments

leetcrew8mo ago

the advantage of var is not clear in toy examples. in real life, people write stuff like

  Map<String, MyExtremelySpecificAndVeryLongTypeName> myExtremelySpecificAndVeryLongTypeNameMap = myExtremelySpecificAndVeryLongTypeNameMapProvider.provide();

literally anything to reduce the number of line breaks needed for a single statement is welcome.

matt20008mo ago

I agree, and I'm not sure how something like 'var accounts = calculateAccounts(something)' can be thought of as better in a code review setting. I suspect using "var" or equivalent will be considered a problem by most companies within the next few years.

tombert8mo ago

This experiment has already been run with pretty much every language that isn’t Java or C, and I think most people have been ok.

Yes, code review is arguably worse, but most people who write Java do so with an IDE and the type is never unknown at that point.

Also, if your function is big enough to where the type of var is not very clear, it likely shouldn’t be passing code review regardless.

nunobrito8mo ago

Those writing in python and javascript don't honestly know any better. They grew in a world without unit testing or without products that need to grow into gigantic systems maintained over the next decades.

This reminds me of a developer writing in jRuby because "it was better". While he was in the company he'd still give support to his own works, after leaving nobody else wanted to pickup those "better" things and would prefer to write workarounds to the tool, it effectively became a black box that few could improve and even worse to test. As result, those portions had to be rewritten in proper Java so that we'd be able to deeply measure/test and improve.

Never again.

vips7L8mo ago

There’s nuance in programming. Both of these statements can be true. Var reduces boiler plate when you’re duplicating information in both the lvalue and rvalue.

I’m in agreement that when the information isn’t in the rvalue that you shouldn’t use var.

jfengel8mo ago

Var can help in maintenance. Change the return type of calculateAccounts and you don't have to modify this code (assuming that it duck-types out equivalently).

That isn't necessarily a huge win: it does force a compile change that isn't obvious from the source. And a refactoring tool could have performed the code change automatically so it's not as big a deal as it might have been.

matt20008mo ago

I would argue that it helps me when performing maintenance to see and correct where types may have changed. Not always, and sometimes it is busy work I agree, but overall I prefer it.

cokely8mo ago

Yeah I generally avoid using 'var' to elide method return types for that reason. In my early phase of var enthusiasm I even had it result in a bug that would have been caught if the type had been made explicit.

I do still really like it in the `var list = new ArrayList<String>()` case though.

watwutOP8mo ago

Modify it when? If the interface renames? IDE does that. If the actual return type changes? They you do have to check that place whether it is still valid.

Maintenance involves a lot of reading of unknown code. That is literally the situation where you are rewiting var to specific types to figure out what is going on.

jauntywundrkind8mo ago

I tend to agree here, I prefer explicitness. Even though yes it does mean some pain when refactoring, it also creates very clear diffs showing impact, which I consider a positive.

Ideally this could all be dealt with via tools. An IDE that shows whatever the user prefers, but is actually saving into a format defined for the repo.

Larrikin8mo ago

It is less readable because either accounts is named incorrectly or calculateAccounts is.

If it should be createAccounts, nothing is lost unless you have multiple account types in which case you would call it createUserAccounts, create adminAccounts etc.

jghn8mo ago

> is literally less readable

Please point me to an objective measure of "readability" that holds for all people. And then demonstrate that your example is "literally" lower on that scale.

pyrale8mo ago

Readability was a term coined by people writing languages that are litterally unusable without an IDE to hide stuff when they render the source file to explain why refusing to learn languages with curly braces is sane.

nunobrito8mo ago

Oh man.. that comment really hit deep. I'll never understand why people argue that it is "easier" to adopt invisible characters and exact tab positioning instead of just using braces or similar to mark the code blocks.

Drives me nuts because you really can only write code for those programs with an IDE that is prepared for the case. Try to edit the code directly from the github web interface and it won't compile.

pyrale8mo ago

Whoops, my initial intent was "without curly braces", since that's where most of the readability comments are from. I guess the comment works both ways, though.

> Drives me nuts because you really can only write code for those programs with an IDE that is prepared for the case.

Usually people have strict rules for that (e.g. pep8), and most text editors will do it for you with little configuration.

vips7L8mo ago

> var accounts = calculateAccounts(something)'

Where did I write this? It’s almost as if there’s nuance in programming.

Var helps when you’re duplicating information that is already known. Your example is clearly not that.

j / k navigate · click thread line to collapse

0 comments

leetcrew8mo ago

the advantage of var is not clear in toy examples. in real life, people write stuff like

  Map<String, MyExtremelySpecificAndVeryLongTypeName> myExtremelySpecificAndVeryLongTypeNameMap = myExtremelySpecificAndVeryLongTypeNameMapProvider.provide();

literally anything to reduce the number of line breaks needed for a single statement is welcome.

matt20008mo ago

tombert8mo ago

This experiment has already been run with pretty much every language that isn’t Java or C, and I think most people have been ok.

Yes, code review is arguably worse, but most people who write Java do so with an IDE and the type is never unknown at that point.

Also, if your function is big enough to where the type of var is not very clear, it likely shouldn’t be passing code review regardless.

nunobrito8mo ago

Never again.

vips7L8mo ago

There’s nuance in programming. Both of these statements can be true. Var reduces boiler plate when you’re duplicating information in both the lvalue and rvalue.

I’m in agreement that when the information isn’t in the rvalue that you shouldn’t use var.

jfengel8mo ago

Var can help in maintenance. Change the return type of calculateAccounts and you don't have to modify this code (assuming that it duck-types out equivalently).

matt20008mo ago

I would argue that it helps me when performing maintenance to see and correct where types may have changed. Not always, and sometimes it is busy work I agree, but overall I prefer it.

cokely8mo ago

I do still really like it in the `var list = new ArrayList<String>()` case though.

watwutOP8mo ago

Modify it when? If the interface renames? IDE does that. If the actual return type changes? They you do have to check that place whether it is still valid.

Maintenance involves a lot of reading of unknown code. That is literally the situation where you are rewiting var to specific types to figure out what is going on.

jauntywundrkind8mo ago

I tend to agree here, I prefer explicitness. Even though yes it does mean some pain when refactoring, it also creates very clear diffs showing impact, which I consider a positive.

Ideally this could all be dealt with via tools. An IDE that shows whatever the user prefers, but is actually saving into a format defined for the repo.

Larrikin8mo ago

It is less readable because either accounts is named incorrectly or calculateAccounts is.

If it should be createAccounts, nothing is lost unless you have multiple account types in which case you would call it createUserAccounts, create adminAccounts etc.

jghn8mo ago

> is literally less readable

Please point me to an objective measure of "readability" that holds for all people. And then demonstrate that your example is "literally" lower on that scale.

pyrale8mo ago

nunobrito8mo ago

Drives me nuts because you really can only write code for those programs with an IDE that is prepared for the case. Try to edit the code directly from the github web interface and it won't compile.

pyrale8mo ago

Whoops, my initial intent was "without curly braces", since that's where most of the readability comments are from. I guess the comment works both ways, though.

> Drives me nuts because you really can only write code for those programs with an IDE that is prepared for the case.

Usually people have strict rules for that (e.g. pep8), and most text editors will do it for you with little configuration.

vips7L8mo ago

> var accounts = calculateAccounts(something)'

Where did I write this? It’s almost as if there’s nuance in programming.

Var helps when you’re duplicating information that is already known. Your example is clearly not that.

j / k navigate · click thread line to collapse