Cosmetic vs More Efficient
-
May I inquire why you would not write "whatEver(inVal=internalDefault)" - Cheerio
Because of this:
whatEver(NULL); -
Because of this:
whatEver(NULL);I meant to agree w/ Monsieur Mircea Neacsu - Professional Profile[^] in his post The Lounge[^] I simply do not understand the purpose of passing in a value only to discard and replace it. In hopes of becoming a better programmer or is it "coder" or is it "app author" I now know it is not "progamer" a full and lengthy explanation would be most appreciated. I am afraid I am too dim witted to understand how your brief quote "whatEver(NULL)" is an explanation as to why one would not declare it as Monsier Mircea Neacsu suggested. I await your kind reply. - Cheerio
-
The difference may be slight but one of the conundrums I find myself in is using a ternary operator to handle a default vs non-default assignment. Simplified:
function whatEver(inVal=NULL) { // here, NULL is a default value for a function argument
// This ?
if(inVal==NULL)
inVal = internalDefault;// or this?
inVal = (inVal==NULL)?internalDefault:inVal;} // function whatEver(inVal=NULL)
The first should be a touch more efficient as it only does an assignment when necessary, but generally an insignificant difference. So - what would you do, and, do you ever pause and consider it before choosing?
"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
I think, because the THEN branch is short, the second is more natural. EDIT: I turns into mess when the same condition evaluated many times in the "sentence". Natural languages and regexp have simple backreference to solve the problem.
-
I meant to agree w/ Monsieur Mircea Neacsu - Professional Profile[^] in his post The Lounge[^] I simply do not understand the purpose of passing in a value only to discard and replace it. In hopes of becoming a better programmer or is it "coder" or is it "app author" I now know it is not "progamer" a full and lengthy explanation would be most appreciated. I am afraid I am too dim witted to understand how your brief quote "whatEver(NULL)" is an explanation as to why one would not declare it as Monsier Mircea Neacsu suggested. I await your kind reply. - Cheerio
Function logic is really strange, but in any case, with your suggestion, result of whatEver(NULL) call is: inVal is not replaced by internalDefault and remains null, which will cause exception when this pointer is dereferenced.
-
Function logic is really strange, but in any case, with your suggestion, result of whatEver(NULL) call is: inVal is not replaced by internalDefault and remains null, which will cause exception when this pointer is dereferenced.
Thank you for your reply but doesn't the original code of Monsieur Mircea Neacsu as shown below merely replace
inValw/internalDefaultwheninValisNULL?function whatEver(inVal=NULL) { // here, NULL is a default value for a function argument
// This ?
if(inVal==NULL)
inVal = internalDefault;// or this?
inVal = (inVal==NULL)?internalDefault:inVal;} // function whatEver(inVal=NULL)
-
The difference may be slight but one of the conundrums I find myself in is using a ternary operator to handle a default vs non-default assignment. Simplified:
function whatEver(inVal=NULL) { // here, NULL is a default value for a function argument
// This ?
if(inVal==NULL)
inVal = internalDefault;// or this?
inVal = (inVal==NULL)?internalDefault:inVal;} // function whatEver(inVal=NULL)
The first should be a touch more efficient as it only does an assignment when necessary, but generally an insignificant difference. So - what would you do, and, do you ever pause and consider it before choosing?
"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
I prefer
if(inVal==NULL) inVal = internalDefault;
Why waste a line of screen space. It's easy enough to read. Though I actually prefer the declaration assign the argument w/ the valid default value as in
return_type whatEver(arg_type inVal=internalDefault);
I simply do not understand the logic of assigning a value to an argument only to immediately discard and replace it. I would be happy to learn of same. Incidentally I learned from a previous post or article I don't recall which to write e.g.
void foobar(int arg)
{
if(arg != valid_value) return;
// remainder of function performs logic for valid argument
}instead of
void foobar(int arg)
{
if(arg == valid_value)
{
// block performs logic for valid argument
}
}so as to minimize the number of indented blocks even though in previous times I preferred minimizing the number of
returnstatements. I find minimizing the number of indented blocks to be easier to understand. - Cheerios -
The difference may be slight but one of the conundrums I find myself in is using a ternary operator to handle a default vs non-default assignment. Simplified:
function whatEver(inVal=NULL) { // here, NULL is a default value for a function argument
// This ?
if(inVal==NULL)
inVal = internalDefault;// or this?
inVal = (inVal==NULL)?internalDefault:inVal;} // function whatEver(inVal=NULL)
The first should be a touch more efficient as it only does an assignment when necessary, but generally an insignificant difference. So - what would you do, and, do you ever pause and consider it before choosing?
"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
Comments below assume C#, capabilities / syntax in other languages may vary. My preference is, if
internalDefaultis not a compile-time constant, to overload the function e.g.void whatEver() => whatEver(internalDefault);
void whatEver(sometype inVal) { /* ... */ }or (assuming
internalDefaultis a compile-time constant)void whatEver(sometype inVal = internalDefault) { /* ... */ }
Better than null would be to use
default(type) e.g.void whatEver(sometype inVal = default(sometype) { /* ... */ }
But in all of theses you should still check that inVal is not null. Alternatively, you can use the null coalescing operator e.g.
void whatEver(sometype inVal = null) // or void whatEver(sometype inVal = internalDefault)
{
inval = inval ?? internalDefault;
}One day, perhaps, there will be a null coalescing assignment operator so you can do
inVal ??= internalDefault;
- this is a feature that I have wanted in JavaScript since JS1.1 (c 1998) to change having code like
myvar = myvar || somedefault;
into
myvar ||= somedefault;
-
I usually write:
void whatEver (int inval = internalDefault)
I want to let users see what the function does in case of a NULL value. Otherwise I would have to document what happens when parameter is NULL.
function whatever(inval=NULL)is simply not C/C++.Quote:
do you ever pause and consider it before choosing
I consider every line in my programs. This would be no exception. EDIT: Note that in C++ default value is written in the header file or wherever the function is declared not in the implementation as your code seems to suggest.
Mircea
This was not intended to be a C++ only question. The C++ on the top of the block is incidental to my picking a code block (should have used plain code).
"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
-
I rarely use the ternary operator unless something happens in both situations. I'd write it the first way, and even on one line unless the assignment seemed a likely spot for a breakpoint.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.That's pretty much my attitude. One place that's essentially always the ternary operator (for me) is testing for incoming arguments in a php file
$aVal = isset($_REQUEST['val']) ))?isset($_REQUEST['val']:some_default;
There could be a flock of these, one after the other, to handle potential incoming values so (at least) I don't get undefined errors. Further handling of default may occur later on (like not use the value). Because it's always the way I do the checking for this particular file type it falls back to being easy reading. Within the body it's not, however, the default way of doing it.
"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
-
That's pretty much my attitude. One place that's essentially always the ternary operator (for me) is testing for incoming arguments in a php file
$aVal = isset($_REQUEST['val']) ))?isset($_REQUEST['val']:some_default;
There could be a flock of these, one after the other, to handle potential incoming values so (at least) I don't get undefined errors. Further handling of default may occur later on (like not use the value). Because it's always the way I do the checking for this particular file type it falls back to being easy reading. Within the body it's not, however, the default way of doing it.
"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
I don't know PHP, but that looks like a good usage after squinting at it and reading your explanation.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
May I inquire why you would not write "whatEver(inVal=internalDefault)" - Cheerio
This question is (despite the little C++ above the code snippet) meant to be considered beyond C++. One reason for you to consider is those languages that accept a variable argument list and accept an empty argument position (php comes to mind). So function sample($x=7) can be invoked: sample($inVal) or sample() with the latter assigning 7 to the internal value. NULL, however, is more common (for me at least). There's some personal conventions that are standardized that way. For example, in the cases where more than on arg has a default I can fill it's place with NULL (it cannot be empty) and assign a further argument. Often used for strings, actually, where I wish to control minor things such as delimiters, test char sets, and such. Think of it as a sometimes variable but usually always the same value is desired.
"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
-
The difference may be slight but one of the conundrums I find myself in is using a ternary operator to handle a default vs non-default assignment. Simplified:
function whatEver(inVal=NULL) { // here, NULL is a default value for a function argument
// This ?
if(inVal==NULL)
inVal = internalDefault;// or this?
inVal = (inVal==NULL)?internalDefault:inVal;} // function whatEver(inVal=NULL)
The first should be a touch more efficient as it only does an assignment when necessary, but generally an insignificant difference. So - what would you do, and, do you ever pause and consider it before choosing?
"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
My God in heaven. The first thing you absolutely must fix is the spacing:
inVal = (inVal == NULL) ? internalDefault : inVal;
That's better. Now, what were you babbling on about?
Software Zen:
delete this; -
The difference may be slight but one of the conundrums I find myself in is using a ternary operator to handle a default vs non-default assignment. Simplified:
function whatEver(inVal=NULL) { // here, NULL is a default value for a function argument
// This ?
if(inVal==NULL)
inVal = internalDefault;// or this?
inVal = (inVal==NULL)?internalDefault:inVal;} // function whatEver(inVal=NULL)
The first should be a touch more efficient as it only does an assignment when necessary, but generally an insignificant difference. So - what would you do, and, do you ever pause and consider it before choosing?
"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
I would completely disregard both causes, check what my developers commonly understand best, and pick that one. As a rule: - Never write code for an unqualified or unasked efficiency goal. - Always write code that is cost-effective to maintain. I've seen many many many average developers write code in a specific way because it's supposedly more efficient. In almost all of those cases, they completely skipped measuring performance and examining the software requirements, and are picking an obtuse implementation because it makes them feel good about their code. To be a excellent developer, you need to write excellent code for humans, and randomly add optimized of code for the compiler. The compiler doesn't care at all, while the humans do. Write code for the latter.
-
I would completely disregard both causes, check what my developers commonly understand best, and pick that one. As a rule: - Never write code for an unqualified or unasked efficiency goal. - Always write code that is cost-effective to maintain. I've seen many many many average developers write code in a specific way because it's supposedly more efficient. In almost all of those cases, they completely skipped measuring performance and examining the software requirements, and are picking an obtuse implementation because it makes them feel good about their code. To be a excellent developer, you need to write excellent code for humans, and randomly add optimized of code for the compiler. The compiler doesn't care at all, while the humans do. Write code for the latter.
KateAshman wrote:
check what my developers commonly understand best, and pick that one.
I've never considered coding to be a majority operation. I do what I do because I think that's how it should be done. If I learn something better I'll fix it.
KateAshman wrote:
I've seen many many many average developers write code in a specific way because it's supposedly more efficient.
Seems to contradict your earlier (first) statement. Don't join the herd in a stampede of "me too!" - if everyone does everything because that's how everyone else does it then nothing will change.
"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
-
My God in heaven. The first thing you absolutely must fix is the spacing:
inVal = (inVal == NULL) ? internalDefault : inVal;
That's better. Now, what were you babbling on about?
Software Zen:
delete this;Gary Wheeler wrote:
That's better. Now, what were you babbling on about?
Shoes and Ships and Sealing Wax. Cabbages and Kings.
"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
-
This was not intended to be a C++ only question. The C++ on the top of the block is incidental to my picking a code block (should have used plain code).
"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
Besides my uncalled for nitpicking on syntax, the more important point of my answer was the idea of avoiding arbitrary "flag" values in parameters. This goes along the lines of "Principle of least astonishment"[^] or "minimum surprise principle" as I prefer to call it, of not forcing the user of your code to remember artificial conventions. For instance, if you have in your .h file a function:
string find_question (int answer=-1);
You have to go to the source file (or the docs) to find behind it some code like:
string find_question (int answer)
{
if (answer == -1)
answer = 42;
...
}Sometimes use of such "flag" values is hard to avoid but in many cases, specially with templetized languages, it is just laziness. One good example of such lazy design is the
basic_stringclass in C++. IMO there is no excuse for using -1 (fancifully disguised asstring::npos) as a flag for last position in string.Mircea
-
Besides my uncalled for nitpicking on syntax, the more important point of my answer was the idea of avoiding arbitrary "flag" values in parameters. This goes along the lines of "Principle of least astonishment"[^] or "minimum surprise principle" as I prefer to call it, of not forcing the user of your code to remember artificial conventions. For instance, if you have in your .h file a function:
string find_question (int answer=-1);
You have to go to the source file (or the docs) to find behind it some code like:
string find_question (int answer)
{
if (answer == -1)
answer = 42;
...
}Sometimes use of such "flag" values is hard to avoid but in many cases, specially with templetized languages, it is just laziness. One good example of such lazy design is the
basic_stringclass in C++. IMO there is no excuse for using -1 (fancifully disguised asstring::npos) as a flag for last position in string.Mircea
I addressed this somewhere else but, as an example, a variable arg list is possible (and often very desirable) in, for example, php (very much C-like except for no strong typing). It allows one to create a function with a default value and still not be stuck with just that value. An ease of use thing. The example I gave in what is really a style-preference question, can be called either as whatEver(inVal) or whatEver() with the latter not giving a 'missing argument' error but rather defaulting to what was in the declaration. An example of use: initializing a random function: with a value it uses that; without a value it can internally pick the current time of day. It's related somewhat to C++ overloading functions.
"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
-
if(inVal==NULL)
{
inVal = internalDefault;
}Wrong is evil and must be defeated. - Jeff Ello
I love the matching braces! When did they invent that???
-
I usually write:
void whatEver (int inval = internalDefault)
I want to let users see what the function does in case of a NULL value. Otherwise I would have to document what happens when parameter is NULL.
function whatever(inval=NULL)is simply not C/C++.Quote:
do you ever pause and consider it before choosing
I consider every line in my programs. This would be no exception. EDIT: Note that in C++ default value is written in the header file or wherever the function is declared not in the implementation as your code seems to suggest.
Mircea
TBH, if it is something we have to do a lot of, I prefer wrapping it with a #defined function...
void fx(int intVal)
{
intVal = COALESCE( intVal, intValDefault );
intVal = COALESCE( intVal, intValDefault );
intVal = COALESCE( intVal, intValDefault );
intVal = COALESCE( intVal, intValDefault );
intVal = COALESCE( intVal, intValDefault );
}Stealing the syntax from SQL gets the point across. Sometimes, doing something 5 times in a row, changes your interpretation of the value of the choice.
-
I usually write:
void whatEver (int inval = internalDefault)
I want to let users see what the function does in case of a NULL value. Otherwise I would have to document what happens when parameter is NULL.
function whatever(inval=NULL)is simply not C/C++.Quote:
do you ever pause and consider it before choosing
I consider every line in my programs. This would be no exception. EDIT: Note that in C++ default value is written in the header file or wherever the function is declared not in the implementation as your code seems to suggest.
Mircea
I agree with this. If your default parameter is only going to be replaced anyway, just go straight to the replacement. Of course, you still need to allow for null actually being passed (assuming the parameter is of a nullable type), so you'll need the check internally. I'm ambivalent on the question of ternary vs 'standard' here. The ternary is small and uncomplicated enough to be readable. Personal/team preference there.
