Cosmetic vs More Efficient
-
I love the matching braces! When did they invent that???
Rusty Bullet wrote:
I love the matching braces! When did they invent that???
Probably 'they' invented it c1970 but I suspect it had been used earlier. See Indentation style - Wikipedia[^] for Allman braces and match the date with BSD Berkeley Software Distribution - Wikipedia[^] It is definitely the way I was shown for Algol 60 (although the braces were then tokens called begin and end) and the one that I have used ever since. Many other folks have independently 'invented' it. If K&R's bracing is TOOTBS (The One and Only True Brace Style, Allman's bracing is TOOLBS (The One and Only Logical Brace Style) or TOOSBS (The One and Only Sensible Brace Style). Much, much, much easier for matching starts and ends of blocks; much, much, much easier for finding mismatched braces.
-
I would always use the first set of code (marked by "this ?") for two reasons... 1) I haven't bothered to learn all the new ways of coding for the simple reason that they most often make the code look arcane and difficult to read. This would result in boosting maintenance costs through difficulties with less experienced developers trying to understand what has been written. 2) Efficiency is highly overrated in computer systems. Do you really believe that a Human Being will be able to tell the difference in speeds between the two types of code? Of course not. So why bother with it? The reason developers bother with such concoctions is they are under the impression that what they are doing either looks "cool", they actually believe that using such arcane coding constructs will make their applications perform better, or both. As to the latter, no such coding construct will make one's code perform better except in the tiny recesses of computer memory where no one will ever notice.
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
Efficiency is not highly overrated, depending upon the type of coding you do. Even early on I had some molecular modeling code that, when I changed from function (actually subroutine) return values to global values ran about 95% faster. Overnight batch runs became real-time in terms of excitation and planning the next iteration target. OK - long ago with FORTRAN and room-size computers. And time sharing. Some other optimizations were made for I/O timing, as well. Back to now: doing it right, which means efficient coding, is even necessary for Web-Based applications: whether it's load time for a page (one second or fifteen?) or, far more importantly, optimizing SQL: something which has reared it's head, recently, as the amount of data in tables, especially joined tables, has grown. A stored procedure could even fail do to exceeding the maximum execution time set up (again, 400 users means limits). So - if all your coding has to handle is small numbers of iterations and much time awaiting human responses it makes no perceivable difference - but good habits pay one back when they don't have to what always seems to be the inevitable future of a good application.
"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
-
Rusty Bullet wrote:
I love the matching braces! When did they invent that???
Probably 'they' invented it c1970 but I suspect it had been used earlier. See Indentation style - Wikipedia[^] for Allman braces and match the date with BSD Berkeley Software Distribution - Wikipedia[^] It is definitely the way I was shown for Algol 60 (although the braces were then tokens called begin and end) and the one that I have used ever since. Many other folks have independently 'invented' it. If K&R's bracing is TOOTBS (The One and Only True Brace Style, Allman's bracing is TOOLBS (The One and Only Logical Brace Style) or TOOSBS (The One and Only Sensible Brace Style). Much, much, much easier for matching starts and ends of blocks; much, much, much easier for finding mismatched braces.
TOOTBS is for me. Staggered braces were invented by publishers trying to squeeze more code on a page to save paper. It was anti-readable. The problem with squeezing the code for publishing was that people learned from books, and learned the wrong style. Publishing should remain as publishing and readable code should be the norm for actual coding, but then I am opinionated toward readability and maintainability.
-
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 don't think it matters much as the compilers are pretty efficient at this. In C#, I usually use the "null coalescing assignment operator (??=)"; so "inVal ??= internalVal;". Here are some functions to test the various ways to assign a default value:
void FixNullArg_SimpleIf(string arg = null) {
if (arg == null)
arg = "Fix null via simple if";
Console.WriteLine(arg);
}
void FixNullArg_TernaryOp(string arg = null)
{
arg = (arg == null) ? "Fix null via ternary operator" : arg;
Console.WriteLine(arg);
}
void FixNullArg_NullCoalescingOp(string arg = null)
{
arg = arg ?? "Fix null via ?? operator";
Console.WriteLine(arg);
}
void FixNullArg_NullCoalescingAssignmentOp(string arg = null)
{
arg ??= "Fix null via ??= operator";
Console.WriteLine(arg);
}
void FixNullArg_IsNullOrWhiteSpace(string arg = null)
{
arg = string.IsNullOrWhiteSpace(arg) ? "Fix null via IsNullOrWhiteSpace" : arg;
Console.WriteLine(arg);
}And here is the decompiled Intermediate Language (IL):
FixNullArg_SimpleIf:
IL_0000: nop
IL_0001: ldarg.1
IL_0002: ldnull
IL_0003: ceq
IL_0005: stloc.0
IL_0006: ldloc.0
IL_0007: brfalse.s IL_0010
IL_0009: ldstr "Fix null via simple if"
IL_000E: starg.s 01
IL_0010: ldarg.1
IL_0011: call System.Console.WriteLine
IL_0016: nop
IL_0017: retFixNullArg_TernaryOp:
IL_0000: nop
IL_0001: ldarg.1
IL_0002: brfalse.s IL_0007
IL_0004: ldarg.1
IL_0005: br.s IL_000C
IL_0007: ldstr "Fix null via ternary operator"
IL_000C: starg.s 01
IL_000E: ldarg.1
IL_000F: call System.Console.WriteLine
IL_0014: nop
IL_0015: retFixNullArg_NullCoalescingOp:
IL_0000: nop
IL_0001: ldarg.1
IL_0002: dup
IL_0003: brtrue.s IL_000B
IL_0005: pop
IL_0006: ldstr "Fix null via ?? operator"
IL_000B: starg.s 01
IL_000D: ldarg.1
IL_000E: call System.Console.WriteLine
IL_0013: nop
IL_0014: retFixNullArg_NullCoalescingAssignmentOp:
IL_0000: nop
IL_0001: ldarg.1
IL_0002: brtrue.s IL_000B
IL_0004: ldstr "Fix null via ??= operator"
IL_0009: starg.s 01
IL_000B: ldarg.1
IL_000C: call System.Console.WriteLine
IL_0011: nop
IL_0012: retFixNullArg_IsNullOrWhiteSpace:
IL_0 -
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
-
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
-
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
This looks like a script function not in C/C++. As for this example in VC++
void whatEver(int inVal) { // This ? if(inVal==0) inVal = internalDefault; // or this? inVal = (inVal==0)?internalDefault:inVal; } // function whatEver(inVal=NULL)See disassembly code in Debug build as simply:; 16 : // This ? ; 17 : if(inVal==0) cmp DWORD PTR _inVal$[ebp], 0 jne SHORT $LN2@whatEver ; 18 : inVal = internalDefault; mov DWORD PTR _inVal$[ebp], 123 ; 0000007bH $LN2@whatEver:While the other just; 21 : inVal = (inVal==0)?internalDefault:inVal; cmp DWORD PTR _inVal$[ebp], 0 jne SHORT $LN4@whatEver mov DWORD PTR tv66[ebp], 123 ; 0000007bH jmp SHORT $LN5@whatEver $LN4@whatEver: mov eax, DWORD PTR _inVal$[ebp] mov DWORD PTR tv66[ebp], eax $LN5@whatEver: mov ecx, DWORD PTR tv66[ebp] mov DWORD PTR _inVal$[ebp], ecxBut you can't see both in Release build because both optimized in compilation. -
This looks like a script function not in C/C++. As for this example in VC++
void whatEver(int inVal) { // This ? if(inVal==0) inVal = internalDefault; // or this? inVal = (inVal==0)?internalDefault:inVal; } // function whatEver(inVal=NULL)See disassembly code in Debug build as simply:; 16 : // This ? ; 17 : if(inVal==0) cmp DWORD PTR _inVal$[ebp], 0 jne SHORT $LN2@whatEver ; 18 : inVal = internalDefault; mov DWORD PTR _inVal$[ebp], 123 ; 0000007bH $LN2@whatEver:While the other just; 21 : inVal = (inVal==0)?internalDefault:inVal; cmp DWORD PTR _inVal$[ebp], 0 jne SHORT $LN4@whatEver mov DWORD PTR tv66[ebp], 123 ; 0000007bH jmp SHORT $LN5@whatEver $LN4@whatEver: mov eax, DWORD PTR _inVal$[ebp] mov DWORD PTR tv66[ebp], eax $LN5@whatEver: mov ecx, DWORD PTR tv66[ebp] mov DWORD PTR _inVal$[ebp], ecxBut you can't see both in Release build because both optimized in compilation.You are overthinking this. First - it is script-like. The C++ was just a posting choice for formatting - apparently a poor choice on my part as many others also though I meant in the C++ context. Second - this was really a question on preferences. Aside from your disassembly, the clear difference is one would (as written) always MOVe a value and the other only conditionally - both doing the same conditional test. The question is, for most applications, which would you rather see - in your own code and someone else's your stuck looking at. The script style of the function, very PHP-like, was to illustrate the function declaration and content all in one small location. In a PHP script roughly like this it acts in a similar manner to a C++ function overload (one with an arg, one without). On the other hand, I appreciate your thoughts and dis-assembly. I've not disassembled code ( once upon a time I had a x86 commenting disassembler) in a very many years.
"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
-
You are overthinking this. First - it is script-like. The C++ was just a posting choice for formatting - apparently a poor choice on my part as many others also though I meant in the C++ context. Second - this was really a question on preferences. Aside from your disassembly, the clear difference is one would (as written) always MOVe a value and the other only conditionally - both doing the same conditional test. The question is, for most applications, which would you rather see - in your own code and someone else's your stuck looking at. The script style of the function, very PHP-like, was to illustrate the function declaration and content all in one small location. In a PHP script roughly like this it acts in a similar manner to a C++ function overload (one with an arg, one without). On the other hand, I appreciate your thoughts and dis-assembly. I've not disassembled code ( once upon a time I had a x86 commenting disassembler) in a very many years.
"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
Yea, I see your point here on preferences. When saw the subject like More Efficient, it often made me think about actual implementation details. But fine, thanks for your good explanation
-
if(inVal==NULL)
{
inVal = internalDefault;
}Wrong is evil and must be defeated. - Jeff Ello
C# has the null coalescing operator
inVal = inVal ?? internalDefault;
Or with C# 8+
inVal ??= internalDefault;
It doesn’t get much cleaner and clearer that that.
-
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
Keep in mind that modern optimizers are *very* good. I wouldn’t assume that your two examples are actually going to result in different compiled code. Definitely lean toward readability.
-
Make it sexy. Keep code as clean and readable as possible. In the grand scheme of things, the compiler will make it efficient whatever the way you write it.
CI/CD = Continuous Impediment/Continuous Despair
Seen to many times where efficiency is the winning choice for code that is only hit a few times. Efficiency usually only matters on code that is hit 100s of thousands of times or more. Clean Code Rules!!!!!
-
Keep in mind that modern optimizers are *very* good. I wouldn’t assume that your two examples are actually going to result in different compiled code. Definitely lean toward readability.
It was always about readability although I did mention that it saved a step. sometimes, in what I think is the more readable version. Spread across all languages where it's a possibilitya, however, includes scripting languages and compiled versions.
"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
if(inVal==NULL)
{
inVal = internalDefault;
}Ternary operators have their place, but aren't mean to replace "if" blocks. Also using that since the input-validation exceptions follow the same pattern, makes code nicely readable. And yes, always as blocks. Typing two chars extra isn't gonna kill anyone.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
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
Coding is a team sport, even when you're alone: you need to collaborate with you from the past and you from the future. Writing code that's first and foremost efficient, while not actively improving existing code for specific performance goals, is a bad idea. I'm implying that without evidence and without specific performance goals, you should always write code that's concise and easy to understand instead. Easy to understand, however, is a moving target, which depends entirely on your team and your coding language. I've extensively researched the topic of code quality for 20+ years. YMMV
-
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 never want to be in a situation where I had to justify something that was redundant but looked better.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food