Which code you suggest?
-
Quote:
You can't be serious!
I do like to joke around a lot, but yes, I can be serious at times.
There are only 10 types of people in the world, those who understand binary and those who don't.
So if the array contained a million strings, the first of which was "ABC", you'd check every single string even though you already know you have a match? :confused: /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
So if the array contained a million strings, the first of which was "ABC", you'd check every single string even though you already know you have a match? :confused: /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
No. I would exit the loop.
There are only 10 types of people in the world, those who understand binary and those who don't.
And that's what example #1 does, not #2. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
And that's what example #1 does, not #2. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Yes, but it returns out of the function, which is the actual debate. So, example 2, even though it has several issues, it does not exit the function, which is what I support. However, what I would do is set the variable as in example #2 and then exit the loop.
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Code1:
Boolean DoSomething(string\[\] values) { foreach (string s in values) if (s == "ABC") return true; return false; }Code2:
Boolean DoSomething(string[] values)
{
bool retValue = false;
foreach (string s in values)
if (s == "ABC")
retValue=true;
return retValue;
}in the above 2 codes which code you will suggest and why? waiting for your valuable comments. Thanks --RA
Neither; I prefer not to end a
foreachwhen aforwill work just as well (if not better).bool result = false ;
for ( int i = 0 ; !result && i < values.Length ; i++ )
{
result = values [ i ] == "ABC" ;
}return ( result ) ;
This could also lead to a discussion of ifless programming. :-D
-
Yes, but it returns out of the function, which is the actual debate. So, example 2, even though it has several issues, it does not exit the function, which is what I support. However, what I would do is set the variable as in example #2 and then exit the loop.
There are only 10 types of people in the world, those who understand binary and those who don't.
ryanb31 wrote:
However, what I would do is set the variable as in example #2 and then exit the loop.
Ah, OK then. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
But you're missing the fact that you can exit a loop when you find what you need. You don't have to continue processing.
There are only 10 types of people in the world, those who understand binary and those who don't.
Just because you can doesn't mean you should.
-
... until you introduce code that needs clean-up at one point or another. Many of the functions I look at every day are a decade old or more, and consist of several hundred lines of codes with half a dozen levels of nesting or more. Every single one of them allocates stuff, or does something else requiring cleanup. More often than not, this happens before something else happens that necessitates a premature return. Some of the really old functions use
goto exit;to immediately jump to the cleanup code. I use a flag. Sure, not everyone works on such a codebase. But the truth is, the majority of programmers doesn't work on brand-new projects either. 80% work on internal programs designed to improve certain processes inside of a single company. Lots of code, and sometimes with a lifetime higher than that of some of their current programmers. In that context, IME, premature returns are almost always a bad idea.Stefan_Lang wrote:
premature returns are almost always a bad idea
:thumbsup: Definitely a code smell.
-
Just because you can doesn't mean you should.
-
Code1:
Boolean DoSomething(string\[\] values) { foreach (string s in values) if (s == "ABC") return true; return false; }Code2:
Boolean DoSomething(string[] values)
{
bool retValue = false;
foreach (string s in values)
if (s == "ABC")
retValue=true;
return retValue;
}in the above 2 codes which code you will suggest and why? waiting for your valuable comments. Thanks --RA
I guess, I would try something like:
Boolean DoSomething(string[] values)
{bool retValue = false; if (values != null) for(int i = 0; i < values.Count(); i++) { if (values\[i\] == "ABC") { retValue = true; i = values.Count(); } } return retValue; }I know the example is a simple loop, but thinking in maintenance and performance this will: - Avoid the internal context and memory usage of a FOREACH (FOR is recommended when u do only 1 single access to the object[i]) - Use of a state variable for a return is recommended rater that having a lot of returns. (readability?) - The Return in the for or foreach cause a BREAK, if I'm not wrong that was expensive in the past, not sure with modern languages.
-
Code1:
Boolean DoSomething(string\[\] values) { foreach (string s in values) if (s == "ABC") return true; return false; }Code2:
Boolean DoSomething(string[] values)
{
bool retValue = false;
foreach (string s in values)
if (s == "ABC")
retValue=true;
return retValue;
}in the above 2 codes which code you will suggest and why? waiting for your valuable comments. Thanks --RA
the first because it will terminate the loop on the first found string, and is thus faster. The second loops the whole array regardless.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein -
I refuse to hire anyone who subscribes to that inane single exit nonsense. And that code is awful for other reasons too. The correct code is
return values.Any(s => s == "ABC")
unless it can be proved to be a performance bottleneck.
That may be OK for C#; but how does it translate to other languages?
-
Code1:
Boolean DoSomething(string\[\] values) { foreach (string s in values) if (s == "ABC") return true; return false; }Code2:
Boolean DoSomething(string[] values)
{
bool retValue = false;
foreach (string s in values)
if (s == "ABC")
retValue=true;
return retValue;
}in the above 2 codes which code you will suggest and why? waiting for your valuable comments. Thanks --RA
I know you were asking for another thing - but the code and alternative you presented are not equal - so someone has to choose Option 1, because this code is the correct one (exit Loop on found string) - so you second DoSomething should do break the loop after a value was found (you will have to add the brackets you left away ;P ) Btw. are you new on "the Internet"? :laugh: It feels about the billionth discussion about early exit vs. single return point - AFAIK this will forever be a matter of style and choise...
-
I guess, I would try something like:
Boolean DoSomething(string[] values)
{bool retValue = false; if (values != null) for(int i = 0; i < values.Count(); i++) { if (values\[i\] == "ABC") { retValue = true; i = values.Count(); } } return retValue; }I know the example is a simple loop, but thinking in maintenance and performance this will: - Avoid the internal context and memory usage of a FOREACH (FOR is recommended when u do only 1 single access to the object[i]) - Use of a state variable for a return is recommended rater that having a lot of returns. (readability?) - The Return in the for or foreach cause a BREAK, if I'm not wrong that was expensive in the past, not sure with modern languages.
Hm, interesting, I can agree a Little on your first point - although this is no practical thinking for most .NET developers, because the "perfomance" impact is outweighted by more expressive code - I do express something when I write "foreach" (I express I want to do something FOR EACH element, don't depend on index or IList, just IEnumerable, I won't need an index, I don't need a break condition, ...). So the additional 2 context variables used internally by the foreach loop are fast earned back... Point 2 will never be decided on "the Internet" - recommended? - not by me - it depends to much on overall style of the code (a lot of coders first evaluate all arguments and do early returns) and personal choice - and if you do "Microoptimazations" in .NET like you/I did in old c++ days, you should do early returns - so, readability (for you) or performance? Point 3, though irrelevant for this discussion because this code should break on any found case (op alternatives are not equivalent), but I'm wondering why you think setting the variable to the break condition and evaluate it again is faster than a break statement? If this is any faster (I will test) this is intersting to know - it seems you are the master of "high perfomance super optimized .NET code" - but I'm not shure if .NET is the right realm for code which needs this kind of optimizations - shouldn't we do such perf. critical things in native code? Kind regards Johannes
-
Hm, interesting, I can agree a Little on your first point - although this is no practical thinking for most .NET developers, because the "perfomance" impact is outweighted by more expressive code - I do express something when I write "foreach" (I express I want to do something FOR EACH element, don't depend on index or IList, just IEnumerable, I won't need an index, I don't need a break condition, ...). So the additional 2 context variables used internally by the foreach loop are fast earned back... Point 2 will never be decided on "the Internet" - recommended? - not by me - it depends to much on overall style of the code (a lot of coders first evaluate all arguments and do early returns) and personal choice - and if you do "Microoptimazations" in .NET like you/I did in old c++ days, you should do early returns - so, readability (for you) or performance? Point 3, though irrelevant for this discussion because this code should break on any found case (op alternatives are not equivalent), but I'm wondering why you think setting the variable to the break condition and evaluate it again is faster than a break statement? If this is any faster (I will test) this is intersting to know - it seems you are the master of "high perfomance super optimized .NET code" - but I'm not shure if .NET is the right realm for code which needs this kind of optimizations - shouldn't we do such perf. critical things in native code? Kind regards Johannes
Good reply!, I already don't remember if the Break is expensive, hasn't google.... but I remember it was like using the old GOTO, developer just avoids it when possible. Yes, if we just think in the original code example, there is like no discussion, the code is so simple that it will return with the first find, so no real issues. But you have talk about something that I has been seen in the "modern" developers and languages (not sure if can apply to the original topic):
"it seems you are the master of ""high perfomance super optimized .NET code"" - but I'm not shure if .NET is the right realm for code which needs this kind of optimizations - shouldn't we do such perf. critical things in native code?"
With modern PCs, the increase of memory and processors speeds (also number of CPUS) developers are forgetting about performance, speed and memory issues, its like they don't remember that the memory is not infinite, and that with the speed of data increase the application can go from 1 minute process to 1 week in a couple of months... I'm no a Performance maniac, but I worked like 4 year in Windows Mobile (C#) and I learned how important it is, and in fact has been a good ADD ON in today projects, I can "easy-sly" understand where our current project will fall and in fact they has fail (I was totally ignored by no mobile developers, then they didn't toke my recommendation, 2 months later the application was failed with Out of memory, with Time out, bandwidth, channel amount of data, with tooo long process).. today my coworkers are taking care of it, but they learned in the wrong way, when it failed in Production. I can say I'm a little worried about modern programing, because our Junior are not facing those Memory and Performance issues, even my Cell Phone have more CPUs and Memory than my 4 years old PC... then neither current mobile developers are facing performance issues until its too late and they will be the Senniors of tomorrow
-
What if you have two nested loops? It's a lot harder to exit them both...
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
goto
-
Good reply!, I already don't remember if the Break is expensive, hasn't google.... but I remember it was like using the old GOTO, developer just avoids it when possible. Yes, if we just think in the original code example, there is like no discussion, the code is so simple that it will return with the first find, so no real issues. But you have talk about something that I has been seen in the "modern" developers and languages (not sure if can apply to the original topic):
"it seems you are the master of ""high perfomance super optimized .NET code"" - but I'm not shure if .NET is the right realm for code which needs this kind of optimizations - shouldn't we do such perf. critical things in native code?"
With modern PCs, the increase of memory and processors speeds (also number of CPUS) developers are forgetting about performance, speed and memory issues, its like they don't remember that the memory is not infinite, and that with the speed of data increase the application can go from 1 minute process to 1 week in a couple of months... I'm no a Performance maniac, but I worked like 4 year in Windows Mobile (C#) and I learned how important it is, and in fact has been a good ADD ON in today projects, I can "easy-sly" understand where our current project will fall and in fact they has fail (I was totally ignored by no mobile developers, then they didn't toke my recommendation, 2 months later the application was failed with Out of memory, with Time out, bandwidth, channel amount of data, with tooo long process).. today my coworkers are taking care of it, but they learned in the wrong way, when it failed in Production. I can say I'm a little worried about modern programing, because our Junior are not facing those Memory and Performance issues, even my Cell Phone have more CPUs and Memory than my 4 years old PC... then neither current mobile developers are facing performance issues until its too late and they will be the Senniors of tomorrow
Very good points. I feel we may have quite similar experiences. I also worked for the last 7 years on Windows CE and Embedded with .NET CF and native code. On Win CE 5 (which was a big step already) we had the 32 MB memory limit per process - How funny, that TODAY one of these old CE 5 devices "showed up" on my office-desk with a "pretty" .net machine-visualization on it - customer (programmer) is telling me that he ran into problems... Guess what? -> Out of Memory! So I totally agree with your points about "Juniors" - And I think we as programmers, will face the same story again, after someone comes up with the idea of the next IThing and want's to play tetris on it. When I was a C++ programmer and realized that I didn't do so much optimizing and inlinig and what not any more, I thought: "Finally we arrived where Memory and CPU perf. is "enough" for my use-cases". But when I startet my first embedded device project a few years later, it was the old story again... So I never mean't that Performance/Memory consumption doesn't matter, and in reality I think about it on every line of code I write (a habit hard to discard if you started programming in a time where it was "expensive"). - Like you said: a good Add On even in todays projects. But I think that today the "code" has to do so much more than just "crunch the numbers". We write code in patterns, abstractions, with test support, support for different plattforms or frameworks, for services, devices, serialization scenarios, for easy maintenance, for whatever is needed on the project at hand, and only sometimes there are performance or memory constraints now (when I started this was ALWAYS one of the most important things - "unreadable guru code for safing 2 bytes? - no problem"). It may be a project where RAD and easy "junior-flipping" is wanted - so go for .NET, easy constructs, no optimazitions where deep knowledge is needed (a case where perf. of foreach vs. for should not matter). But another time you will have todo something very "fast" or "cheap on memory", then comes the time to optimize algorithms and code for specific tasks. But if I'm on a CE device, found a perfomance/memory bottleneck, I would hardly think about optimizing the IL code - I'd go for a native solution (maybe C++) and use Interop to call it (if marshalling perfomance impact is not a problem). Because from my experience the "biggest" gain on using native code, is to circumvent the GC... Of course using unsafe code can be an alternative, and optimizing perf/memory is the onl
-
Code1:
Boolean DoSomething(string\[\] values) { foreach (string s in values) if (s == "ABC") return true; return false; }Code2:
Boolean DoSomething(string[] values)
{
bool retValue = false;
foreach (string s in values)
if (s == "ABC")
retValue=true;
return retValue;
}in the above 2 codes which code you will suggest and why? waiting for your valuable comments. Thanks --RA
How about with little refinements?
bool DoSomething(string[] values)
{
bool blnReturnValue = false;foreach (string s in values) { blnReturnValue = s.Equals("ABC"); if (blnReturnValue) break; } return (blnReturnValue); }Vasudevan Deepak Kumar Personal Homepage BRAINWAVE/1.0 Status-Code: 404 Status-Text: The requested brain could not be found. It may have been deleted or never installed.
--Brisingr Aerowing -
Oh, you must be lots of fun to work with. The "correct code"? The "correct code" is something that is easy to maintain and produces the desired result. In addition your comment does not address the original question. Which is better, multiple returns or a single return? As a maintenance programmer, I fully support a single return statement. Multiple returns are lazy and prone to creating code that doesn't get tested before getting sent to QA. Granted the example was trivial but the underlying question was not.
I'm a pleasure to work with because I know my craft and I write readable, maintainable code, not the kind of garbage that was posted here ... a result of a) harebrained adherence to a pointless single-return dogma and b) not being familiar the available tools, such as LINQ, and not being familiar with the state of the art, which now includes the sort of functional programming that LINQ represents. Functional programming is the ultimate in "single return", because there are no return statements, there are just functions that yield expressions. But if you're writing crufty imperative code, single return is bad because a) several empirical studies show that it has high cognitive load, making it difficult to interpret and subsequently more likely have bugs in the original and more likely to be broken when changed, and b) it results in the Arrow Anti-Pattern (http://www.codinghorror.com/blog/2006/01/flattening-arrow-code.html). Multiple returns are lazy and prone to creating code that doesn't get tested before getting sent to QA. Oh, you must be a joy to work with as you dishonestly defend positions by making up BS arguments. Laziness and failing to unit test has nothing whatsoever to do with single vs. multiple returns (but it does have a lot to do with people who don't read the literature and so know nothing about the technology of software construction). Multiple returns in guard clauses as mentioned at codinghorror are not "lazy", they are orderly and logical. It's not laziness that leads good programmers to avoid unnecessary structure and condition variables, it's competence.
-
That may be OK for C#; but how does it translate to other languages?
