|
D'oh!
I spent about 20 problematic minutes trying to coming up with anagrams for "aviary"....
One morning I shot an elephant in my pajamas. How he got in my pajamas, I don't know.
|
|
|
|
|
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
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) = a hence 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...
|
|
|
|
|
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???
|
|
|
|
|
|
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
(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.
|
|
|
|
|
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!
|
|
|
|
|
|
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
|
|
|
|
|
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,...
|
|
|
|
|
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!
|
|
|
|
|
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?
|
|
|
|
|
or... if the Height is 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.
|
|
|
|
|
You are right Jörgen but even worse, that everyone else is just copy'n'pasting.
... such stuff as dreams are made on
|
|
|
|
|
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
(yes|no|maybe)*
"Fortunately, we don't need details - because we can't solve it for you." - OriginalGriff
|
|
|
|
|
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!
modified 1-Mar-17 2:52am.
|
|
|
|
|
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!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
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;
|
|
|
|
|
This is an intriguing concept. But, other than practicing your bash shell commands without a VM or dual boot, what are some practical uses for it? Can you set up a Linux development environment, run a LAMP or LARP* stack on it?
I'm curious to know what uses CP'ers have found.
*Linux Apache Ruby PostgreSQL.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
It may work better for some games than Wine
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hmm, install bash on Windows, so you can run Wine, so you can run Windows games.
Makes perfect sense.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
It gives you a true 8-bit experience.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Leisure Suit Larry will rise again!
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Hmm. You're actually turning my head in favour of it!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|