The (strange) case against very long and explicit variable names, with Math

[Brisingr Aerowing]

:cool:

What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???

[PIEBALDconsult]

I agree.

[Vivi Chellappa]

This is why programmers dislike COBOL. With 30-character names, programmers got tired of spelling out long names -- not that any used them -- and switched to C which is really COBOL but shortened by dropping off the trailing 4 characters. You don't believe me? Where did record structures in C come from? COBOL! Where did pointers come from? COBOL, with the addition that you could ALTER a go to statement to point to a different location as the program executes! :-D

[Super Lloyd]

OMG! [Kolbold](https://en.wikipedia.org/wiki/Kobold) has everything! :D

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

[Lost User]

Fer faarrrkkkks sake, you're in Australia, it's faarrrkkkking maths.

Michael Martin Australia "I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash One Fine Saturday. 24/04/2004

[V 0]

Super Lloyd wrote:

All of that to say that those "long and meaningful" variable names are really an hindrance...

That greatly depends on the situation. If you use it locally, like in the example. I fully agree. If you need to use it elsewhere, however,... ;)

V.

(MQOTD rules and previous solutions)

[Jorgen Andersson]

The problem isn't the length of the variable names. (Even though they might be some times) The problem is that the original author didn't think all the way, but even worse, that everyone else is just copy'n'pasting. Take a look at your refactored code with the original variable names:

    int usableHeightNow = computeUsableHeight();
    if (usableHeightNow != usableHeightPrevious)
    {
        frameLayoutParams.Height = usableHeightNow;

It's not that bad anymore is it?

Wrong is evil and must be defeated. - Jeff Ello

[StM0n]

:) the old "but someone said you should use meaningful variable names" and c&p-coding without getting a grip. I would rather tend to rename a back to usableHeightNow... for readability :laugh:

(yes|no|maybe)* "Fortunately, we don't need details - because we can't solve it for you." - OriginalGriff

[Mark_Wallace]

I agree. usableHeightNow and usableHeightPrevious don't even meet the requirements of meaningful naming. They should be currentComputedValueOfUsableHeight and usableHeightExtantBeforeTheCurrentValueWasComputed [edit] What a time to typo "extant"! Open a ticket; the bloody code won't compile! [/edit]

I wanna be a eunuchs developer! Pass me a bread knife!

[Nicholas Marty]

or... if the Height is a field or a property without side effects in the setter:

frameLayoutParams.Height = computeUsableHeight();

[Jorgen Andersson]

I thought so as well, but if you follow the link in the OP you'll notice there's more code inside the conditional.

Wrong is evil and must be defeated. - Jeff Ello

[Mark_Wallace]

That's the trouble. You end up with 7,000 private instances of a, b, and c. Better is to use meaningful names that don't all start with the same characters (in this case "usableHeight"), and let intellisense do its magic. nowUsableHeight and newUsableHeight aren't such a pain, but are clear enough.

I wanna be a eunuchs developer! Pass me a bread knife!

[megaadam]

You are right Jörgen but even worse, that everyone else is just copy'n'pasting. :cool:

... such stuff as dreams are made on

[Nathan Minier]

I fundamentally disagree. In the age before the IDE and Intellisense this argument held some water, since descriptive variable names translated directly into writing time. These days I rarely need to type more than three characters and I've locked into the variable that I need. Long variable names provide description and context, and lead to self-documenting code: that Utopian dream where source code can be quickly understood without being riddled with // or /**/. The other point is that source code is for people. In the future, that set of people may include you or it may not, but the code will need to be pulled out, brushed off, and modified at some point. A terse variable name may make perfect sense to you, but the next guy is not you and it may or may not to him. I guarantee that a nice, descriptive name will, though.

"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli

[Richard Andrew x64]

Wholeheartedly agree! :cool:

The difficult we do right away... ...the impossible takes slightly longer.

[Gary Wheeler]

Long and meaningful variable names are useful in a long-term, global context. In this case, those longer names are obscuring their actual use in a local context. If you have a complicated calculation that references those names, copy the incoming values to shorter names for purposes of performing the calculation, thereby making it more readable.

Software Zen: delete this;

[raddevus]

Here's the likely truth Everyone who likes the short (letter) var names 1) is 45 or older (you've read K&R :) ) 2) codes alone and not as part of a team (it don't matter cuz it's write-once code) 3) All of the above :laugh: (but I'm kind of not laughing too, because when you read someone else's code like that you have to read it a few times). I'd much rather read someone else's code <=1 time. :-D