The (strange) case against very long and explicit variable names, with Math
-
I am working with Xamarin forms and there is a problem with FormsAppCompat size after softkeyboard is shown on screen. There is a bit of a fix copied verbatim all over the web which can (also) be found there: [Accommodating The On Screen Keyboard in Xamarin Forms - Xamarin Help](https://xamarinhelp.com/accommodate-on-screen-keyboard-xamarin-forms/) My particular beef is with those lines copied in so many places
int usableHeightNow = computeUsableHeight(); if (usableHeightNow != usableHeightPrevious) { int usableHeightSansKeyboard = mChildOfContent.RootView.Height; int heightDifference = usableHeightSansKeyboard - usableHeightNow; frameLayoutParams.Height = usableHeightSansKeyboard - heightDifference;This looks painfully complicated, doesn't it? That's probably why it has been copied verbatim in so many places. Now, as a thought exercise let's use those so called "evil and short and meaningless" variable names
int a = computeUsableHeight(); if (a != usableHeightPrevious) { int b = mChildOfContent.RootView.Height; int d = b - a; frameLayoutParams.Height = b - d;what is immediately visible now? well
frameLayoutParams.Height = b - d = b - (b - a) = ahence the all thing can be simplified to:int a = computeUsableHeight(); if (a != usableHeightPrevious) { frameLayoutParams.Height = a;All of that to say that those "long and meaningful" variable names are really an hindrance...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
:) 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
aback tousableHeightNow... for readability :laugh:(yes|no|maybe)* "Fortunately, we don't need details - because we can't solve it for you." - OriginalGriff
-
I am working with Xamarin forms and there is a problem with FormsAppCompat size after softkeyboard is shown on screen. There is a bit of a fix copied verbatim all over the web which can (also) be found there: [Accommodating The On Screen Keyboard in Xamarin Forms - Xamarin Help](https://xamarinhelp.com/accommodate-on-screen-keyboard-xamarin-forms/) My particular beef is with those lines copied in so many places
int usableHeightNow = computeUsableHeight(); if (usableHeightNow != usableHeightPrevious) { int usableHeightSansKeyboard = mChildOfContent.RootView.Height; int heightDifference = usableHeightSansKeyboard - usableHeightNow; frameLayoutParams.Height = usableHeightSansKeyboard - heightDifference;This looks painfully complicated, doesn't it? That's probably why it has been copied verbatim in so many places. Now, as a thought exercise let's use those so called "evil and short and meaningless" variable names
int a = computeUsableHeight(); if (a != usableHeightPrevious) { int b = mChildOfContent.RootView.Height; int d = b - a; frameLayoutParams.Height = b - d;what is immediately visible now? well
frameLayoutParams.Height = b - d = b - (b - a) = ahence the all thing can be simplified to:int a = computeUsableHeight(); if (a != usableHeightPrevious) { frameLayoutParams.Height = a;All of that to say that those "long and meaningful" variable names are really an hindrance...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I agree.
usableHeightNowandusableHeightPreviousdon't even meet the requirements of meaningful naming. They should becurrentComputedValueOfUsableHeightandusableHeightExtantBeforeTheCurrentValueWasComputed[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!
-
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
or... if the
Heightis a field or a property without side effects in the setter:frameLayoutParams.Height = computeUsableHeight();
-
or... if the
Heightis a field or a property without side effects in the setter:frameLayoutParams.Height = computeUsableHeight();
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
-
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)
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.
nowUsableHeightandnewUsableHeightaren't such a pain, but are clear enough.I wanna be a eunuchs developer! Pass me a bread knife!
-
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
-
I am working with Xamarin forms and there is a problem with FormsAppCompat size after softkeyboard is shown on screen. There is a bit of a fix copied verbatim all over the web which can (also) be found there: [Accommodating The On Screen Keyboard in Xamarin Forms - Xamarin Help](https://xamarinhelp.com/accommodate-on-screen-keyboard-xamarin-forms/) My particular beef is with those lines copied in so many places
int usableHeightNow = computeUsableHeight(); if (usableHeightNow != usableHeightPrevious) { int usableHeightSansKeyboard = mChildOfContent.RootView.Height; int heightDifference = usableHeightSansKeyboard - usableHeightNow; frameLayoutParams.Height = usableHeightSansKeyboard - heightDifference;This looks painfully complicated, doesn't it? That's probably why it has been copied verbatim in so many places. Now, as a thought exercise let's use those so called "evil and short and meaningless" variable names
int a = computeUsableHeight(); if (a != usableHeightPrevious) { int b = mChildOfContent.RootView.Height; int d = b - a; frameLayoutParams.Height = b - d;what is immediately visible now? well
frameLayoutParams.Height = b - d = b - (b - a) = ahence the all thing can be simplified to:int a = computeUsableHeight(); if (a != usableHeightPrevious) { frameLayoutParams.Height = a;All of that to say that those "long and meaningful" variable names are really an hindrance...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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
-
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
Wholeheartedly agree! :cool:
The difficult we do right away... ...the impossible takes slightly longer.
-
I am working with Xamarin forms and there is a problem with FormsAppCompat size after softkeyboard is shown on screen. There is a bit of a fix copied verbatim all over the web which can (also) be found there: [Accommodating The On Screen Keyboard in Xamarin Forms - Xamarin Help](https://xamarinhelp.com/accommodate-on-screen-keyboard-xamarin-forms/) My particular beef is with those lines copied in so many places
int usableHeightNow = computeUsableHeight(); if (usableHeightNow != usableHeightPrevious) { int usableHeightSansKeyboard = mChildOfContent.RootView.Height; int heightDifference = usableHeightSansKeyboard - usableHeightNow; frameLayoutParams.Height = usableHeightSansKeyboard - heightDifference;This looks painfully complicated, doesn't it? That's probably why it has been copied verbatim in so many places. Now, as a thought exercise let's use those so called "evil and short and meaningless" variable names
int a = computeUsableHeight(); if (a != usableHeightPrevious) { int b = mChildOfContent.RootView.Height; int d = b - a; frameLayoutParams.Height = b - d;what is immediately visible now? well
frameLayoutParams.Height = b - d = b - (b - a) = ahence the all thing can be simplified to:int a = computeUsableHeight(); if (a != usableHeightPrevious) { frameLayoutParams.Height = a;All of that to say that those "long and meaningful" variable names are really an hindrance...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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; -
I agree.
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
