|
He’s just trawling us.
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
As we flounder through this thread I need to ask you: How fishy? On a scale of 1 to 10.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos, GHB wrote: On a scale of 1 to 10.
Numbers? Holy mackerel! Schooling is now required in this thread?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
No, it's just a Red Herring!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Whew..Thank Cod!
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Just transport the whole kit and caboodle into their engine room, where they'll be no treble at all.
|
|
|
|
|
rnbergren's recent post about variable names was good.
Lots of helpful advice poured in.
I didn't respond but I think that I should have done so.
rnbergren's post was about using frivolous or silly names for Variables and other things in proof of concept code and then using this as in copy and pasting in the real code. Sometimes changing it and sometimes not. Enjoying it or not.
Most responses were like, do it properly in the first place and it won't end up in your production code.
I agree. I have done it in the past but not anymore.
However I do like to be creative and sometimes I look at a previously named function, sub or Var name and marvel in it's relevance. I often comment/remark on the name as well so that it makes sense to others.
Sander Wrote:Quote: So no, I've made doing it "right" a habit and would not even think about naming something "astr" or "ewww" Smile | 
OK ewww is a bit weird unless the table has field names like ewww and ahhh. (I love and respect Sander.)
I used to always use nresponse as the throw away variable name for things like the result of an input box within a sub.
I remember using ansStr once which was commented as 'answer string'. So close to astr.
Personally I don't see the problem especially with a throwaway Variable.
It is only there for a few micro seconds.
Every other name is important.
So I am interested in what others use for a throw away variable names used to hold a response from something like an inputbox or similar.
Do you always use the same name and if so what is it?
Or do you change it to suit the situation?
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
|
|
|
|
|
I already voted. Once I am past like 2 stupid variable names or I am past 15 lines of code. Well the whole thing needs to be cleaned up for the masses.
I pretty much only use astr for strings and some other silly ones.
Fun discussion. can't wait to see the posts.
To err is human to really elephant it up you need a computer
|
|
|
|
|
Quote: Fun discussion. can't wait to see the posts.
Yeah same here.
It is something that isn't normally spoken about.
Thanks for steering this one as well.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
|
|
|
|
|
C# has "institutionalized" throw-away variable names: Discards - C# Guide | Microsoft Docs[^] but they aren't quite what you are talking about.
If you mean that an input box returns a value and you'll use it just once, then don't store it in a variable: use it inline, or give it a sensible name if that'll make your "single line of code" unreadable. "result" is a good one - it at least tells you that it's probably short term, but give you a clue what it contains if extra code is added at a later point.
DialogResult result = MessageBox.Show(prompt, caption, MessageBoxButtons.YesNoCancel);
if (result == DialogResult.Cancel) return;
if (result == DialogResult.Yes)
{
...If later code makes the "Cancel" branch bigger (logging, "Are you sure?" that kinda thing maybe) then the sense of the code is retained.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: then don't store it in a variable: use it inline
Except when it kills readability, like Commandstrings.
<edit>Didn't even read the full sentence properly. 
|
|
|
|
|
Jörgen Andersson wrote: <edit>Didn't even read the full sentence properly
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I'll blame an unfortunate linefeed.
|
|
|
|
|
Yes Sensible. I like it.
Thanks.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
|
|
|
|
|
Guilty. I tend to reuse "CommandString". Only change it if I use more than one at the same time.
|
|
|
|
|
Some say that consistency is a virtue.
I think that your tendency is OK and readable.
Somethings just become habits.
Thanks, it is interesting.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
|
|
|
|
|
I've never used silly variable names, even for throw away variables, but I do use result and response quite often. I try to use generic variable names in specific types of methods, such as methods used in the data access layer, so I can make templates from them. I try to balance readability, simplicity, and functionality when writing code. That's why I found it quite difficult transitioning from the old way of writing variable names (a$ as an example) to writing out full length variable names such as errorLogEntity.
"When you are dead, you won't even know that you are dead. It's a pain only felt by others; same thing when you are stupid."
Ignorant - An individual without knowledge, but is willing to learn.
Stupid - An individual without knowledge and is incapable of learning.
Idiot - An individual without knowledge and allows social media to do the thinking for them.
modified 19-Nov-21 21:01pm.
|
|
|
|
|
Sensible. I like what you are saying. It just makes sense.
Repetition for short throw away vars and full length names for important and longer living ones.
Some may think that a$ was a bit silly, but hey, it was common way back.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
|
|
|
|
|
for loop counters i use i,j,k, etc
for results from routines i use "result"
for throwaways I usually use an abbreviated name that indicates the purpose.
if the purpose is obvious, and the variable has small locality in my routine, i may even name it something like "fn" to hold a filename, or p to hold a point.
Real programmers use butterflies
|
|
|
|
|
I am, pretty much the same. Thanks.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
|
|
|
|
|
This discussion is quite fascinating. Back in my youth (when dinosaurs roamed the earth), languages restricted both length of variable names and enforced type based on initial (or even only!) letters.
So, I to N would be integer, everything else floating point. This is, I believe the origin of the common use of i,j,k for integer loop variables etc, and x,y,z (also algebraic) for common floats.
Someone I once employed would have complex calculations etc using variables like x, xx, xxx, xxxx and y,yy,yyy,yyyy etc - write only code if ever there was any.
The advent of unrestricted variable names led to the opposite extreme, where variable (and function) names became so long and complex
eg:
doubleCalculateOffsetForWaveFunction(intScaleFactorForWaveFunction,floatWaveFunctionSeedValue)
doubleCalculateOffsetForInverseWaveFunction(intScaleFactorForWaveFunction,floatWaveFunctionSeedValue)
with variations on camelCase, "_" separators etc) that code became tedious to type correctly and especially to refactor before the rise of the modern IDE; impossible to read and understand because of the effort needed to parse the variable names, especially when lots were very similar in structure etc etc.
(How would you know from reading the two declarations above whether the parameters were the correct variables eg: you might indeed want to use the same seeds here, or it might need different ones, so why not just use 'seed' etc)
BUT, you have to beware of making anything other than throwaway variable names too specific to the algorithm rather than their usage - because this can make them ambiguous or misleading in meaning:
does 'intUserValue' indicate something entered by the user, some property of the user, the user's value to the organisation etc
Making up variable names can be one of the hardest parts of coding something especially if one coding house uses identical names differently to another. I recently dug myself into a hole migrating a business app from SAGE accounts to XERO, because in SAGE anything (Nominal ledger entries, customers, suppliers etc) can be in an 'account'. In XERO only nominal items go in 'accounts', customers go in 'contacts'. I only discovered this when I tried to post a customer invoice and found that I couldn't assign it to an 'account', only to a 'contact'.
Then there are the times when you use a library function return value in-line, there's a bug, and even your modern sophisticated IDE has no way to inspect the return value without dropping right down to assembler level code inspection - so you put the result into a variable which the compiler then helpfully removes again during optimisation so you still can't debug it easily.
After many years, I have come to the conclusion that KISS applies as much to variable naming as to code itself: Also if you are dyslexic, long variable names can be incredibly difficult to cope with too.
So, as simple as possible, don't bother with describing the type in the name (except possibly in languages that don't have or enforce types, and even then limit yourself to single letters if possible eg iRetVal, not integerRetVal).
Simple variable/function names along with careful, concise comments can make all the difference!
You have heard of comments, haven't you? 8)
|
|
|
|
|
A wonderful response.
Really enjoyed this one especially.
Thanks.
I was aware of most of the history that you mentioned.
The long variable and function name thing made me nearly spit my stout out over the keyboard. I have never seen this before but I have seen similar.
I usually comment on names, especially function names and occasionally with Variables if they may seem obscure.
A comment is sometimes priceless.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
|
|
|
|
|
I agree with most of this. I've only been coding since the mid 80s but I have worked in software professionally since I was 18, with some breaks here and there for my mental health. So I have some experience, and for me I've found
A) Style isn't as important as consistency of style
B) It's easier to go with the flow. Your job is to make your flow come correct. That takes practice. Make it instinct to do the right thing. With variable names this means foster good habits, but then move to relying on the "muscle memory" of those habits in terms of naming patterns
C) Everyone has opinions. You can't satisfy every developer, so satisfy you and your project lead.
Just my $0.02
Real programmers use butterflies
|
|
|
|
|
I think that the single responsibility principle (from SOLID) is directly linked to names: if you make sure that your function or class or even variable just fulfills a single purpose, then you should also be able to name it appropriately, using that purpose. Or, the other way round: if you find that parts of a name you're looking at describe different purposes, then there is likely a copnflict with the single responsibility principle!
In other words, clean code leads to good, and reasonably short names.
But let's look at your examples:
doubleCalculateOffsetForWaveFunction(intScaleFactorForWaveFunction,floatWaveFunctionSeedValue)
doubleCalculateOffsetForInverseWaveFunction(intScaleFactorForWaveFunction,floatWaveFunctionSeedValue)
In these names, the type information does absolutely nothing to explain the purpose, so these parts must go. Next, the function names describe what the result is used for (the (inverse) wave function). This info should go into the argument list, not the name. That will also make the calculateOffset functionality easier to refactor: if there's anything you need to fix or change in the offset calculation, having just one function to look at is always preferable to having >1 functions!
As for naming style, I consider '_' separators to be more readable than any other style, but TBH I couldn't care less, so let's stick with what you had. With my comments above, you get just one function instead of two:
calculateOffset(scaleFactor, seedValue, functionType)
Since the function type goes into the argument list anyway, I've dropped it from the argument names. I'd also drop the meaningless suffix 'Value', but it's already a lot more readable. And all that without losing any information!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Indeed so!
For the avoidance of doubt, these were not functions created by me! 8)
I have never understood the need, even in interpreted languages like modern BASICs etc, for 'hungarian' notation - if the language isn't type-safe, then no amount of attaching prefixes etc is going to prevent some library assigning a string to the integer variable you just passed it silently and hence subtly altering the results etc.
Possibly useful as a reminder to you as coder, but cannot be relied on by anyone else reading your code, so better to have meaningful variables and proper tests, exception handling etc so that context reveals what should be going on.
I'm working on a very elderly codebase at the moment where some, but not all, tables are named tbl<name>; some, but not all, forms are frm<name>; some, but not all, reports rpt<name> etc etc. The lack of consistency renders all these prefixes completely useless and just makes typing out code tedious and mistake prone...
As for comments? Ah yes, I did find one, once, somewhere in the 100,000 or so lines of code...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
