Names
-
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.
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
-
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
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
-
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
grralph1 wrote:
I love and respect Sander.
Love you too man #nohomo #bromance 😘
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
grralph1 wrote:
I love and respect Sander.
Love you too man #nohomo #bromance 😘
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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
-
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 did respond to the previously mentioned post, as one who does use silly names. Perhaps a new topic, but I also leave silly (funny?) comments in the code for whomever receives the punishment of having to fix modify my code later.
// Note: No pterodactyls were harmed in the testing of this code, but the same cannot be guaranteed once released in the wild.
if (...) {
-
-
} else {
// Sit back, relax, and have a beer.
}Nothing succeeds like a budgie without teeth.
-
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
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
-
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 use "result" or "response" when it is really a throw away variable for debugging purposes. Using "ewww" or "blurpp" is crossing the line. We are working, not joking with friends. Even if it's a personal project, bad habits get carried to other things.
-
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
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 use "result" or "response" when it is really a throw away variable for debugging purposes. Using "ewww" or "blurpp" is crossing the line. We are working, not joking with friends. Even if it's a personal project, bad habits get carried to other things.
-
I did respond to the previously mentioned post, as one who does use silly names. Perhaps a new topic, but I also leave silly (funny?) comments in the code for whomever receives the punishment of having to fix modify my code later.
// Note: No pterodactyls were harmed in the testing of this code, but the same cannot be guaranteed once released in the wild.
if (...) {
-
-
} else {
// Sit back, relax, and have a beer.
}Nothing succeeds like a budgie without teeth.
Yes I do remember your bravery and your pride. I do like the idea of silly or humorous comments. You only live once. And it may cheer up someone who is reworking your work. Weirdly though I hardly ever do it. (Probably because no one else usually ever sees my source code.) For the past 10 years I have been commenting for others. Prior to that it was only ever for me. Thinking about this whole thing I have discovered that I appear to be most creative (not silly) when making up names for functions. Less so for subs and variables. However I recently noticed that in some legacy code that I had a public boolean variable called TheWhiteZone. The comment said "The white zone is for loading and unloading only". This was exactly what the Var was indicating, loaded or not, and it wasn't aloud to park there. No Way.
"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
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
-
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 have used and will continue to use "temp" for a temporary variable that lives for one or two lines of code.
-
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 always use something meaningful, even if it is a throwaway variable. I work hard to make my code readable and think of whether the name will help or hinder me six months from now. I have worked in way too much legacy code that took forever to figure out and understand maintenance is where the bulk of programming time gets spent. (much to my dismay!)
-
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 learned from this series of posts to utilize "str" for strings. I never liked using "string" since it conflicts w/ std::string. I always use "using namespace std;" I favor descriptive names however I would rewrite doubleCalculateOffsetForWaveFunction(intScaleFactorForWaveFunction,floatWaveFunctionSeedValue) as Offset_forWaveFunction(scale_factor, seed_value) I don't believe in Hungarian notation as it is merely another source of error and of course the return value is already documented. "Calculate" is redundant since we know that's what functions do. I find it helpful to distinguish prepositions in the name. "ForWaveFunction" is not needed since the variable is in context. If this method was of a class WaveFunction then all that would be needed would be Offset(scale_factor, seed_value). My local variables are always lower case. Capitals I reserve for global or public objects. I am fascinated by naming notation conventions. I like the notation to say something about the method and variable e.g. to distinguish public methods from private e.g. camel for public and snake for private though I am conflicted as I like snake as it is easy on the eyes with no capital letters shouting at me though I am currently utilizing all capitals for statics and terminate all lambdas with "_LAMBDA". I am eager to learn of other's techniques and preferences. - Cheerio
-
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 once came across a function whose purpose was to send a message to the Sales And Marketing application. The developer had amusingly but appropriately named the function TelegramSAM. Unfortunately, they had then got a little carried away: The author was listed as M. Bolan The variables were named "jungle", "faced", "jake", "make", "no" and "mistake".
-
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
Hands down the 3 hardest problems in programming: -naming stuff -off-by-1-errors For throwaways, I usually pick my repertoire of Result (for holding something that'll get returned) and Scrap (generic temporary). For stuff like responses from dialog boxes, I either take my old-and-tried Scrap, or give it some meaningful name like "SerialNo" when the user is prompted for a serial.
-
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
Some people have called my code idiosyncratic.
i,j,kfor loop indices with scope inside the for loop.rcfor any numerical function return code with a small scope.valfor many kinds of value, as a formal argument name.thatfor the argument of a copy constructor. My input variables tend to have real names. I mostly store results in variables instead of using the rvalue result because it's typical that I have to test them more than once. -
I learned from this series of posts to utilize "str" for strings. I never liked using "string" since it conflicts w/ std::string. I always use "using namespace std;" I favor descriptive names however I would rewrite doubleCalculateOffsetForWaveFunction(intScaleFactorForWaveFunction,floatWaveFunctionSeedValue) as Offset_forWaveFunction(scale_factor, seed_value) I don't believe in Hungarian notation as it is merely another source of error and of course the return value is already documented. "Calculate" is redundant since we know that's what functions do. I find it helpful to distinguish prepositions in the name. "ForWaveFunction" is not needed since the variable is in context. If this method was of a class WaveFunction then all that would be needed would be Offset(scale_factor, seed_value). My local variables are always lower case. Capitals I reserve for global or public objects. I am fascinated by naming notation conventions. I like the notation to say something about the method and variable e.g. to distinguish public methods from private e.g. camel for public and snake for private though I am conflicted as I like snake as it is easy on the eyes with no capital letters shouting at me though I am currently utilizing all capitals for statics and terminate all lambdas with "_LAMBDA". I am eager to learn of other's techniques and preferences. - Cheerio
Thanks for that it is very interesting.
Quote:
doubleCalculateOffsetForWaveFunction(intScaleFactorForWaveFunction,floatWaveFunctionSeedValue)
Gee. I can read your rewrite easily. The original is like a the name for a Welsh town and the only person who could read that would be the OriginalGriff. I have never used ALLCAPS for anything. No reason, just never even thought about it. Therefore no titleCASE case either. I usually use camelCase now but used to use CamelCase. I sometimes but rarely use snake_case or a cross between it and one of the camel styles just for some emphasis. For Public variables I always distinguish these with a g prefix. Like gWaveVal. The g indicates Global. It is fascinating to hear what other peoples preferences are and also the reasons for their preference. Thx
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
-
I once came across a function whose purpose was to send a message to the Sales And Marketing application. The developer had amusingly but appropriately named the function TelegramSAM. Unfortunately, they had then got a little carried away: The author was listed as M. Bolan The variables were named "jungle", "faced", "jake", "make", "no" and "mistake".
This made me laugh. What a great name for the function. Almost the perfect name but in retro case. It may fly completely over the head of younger developers though. I like the idea of having a theme though. However easy to get carried away.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
