Programming style
-
As a rule, I like to have one exit point for functions, but I sometimes make an exception for initial state checks. Which do you prefer Button btn = sender as Button; if (btn != null) { } OR Button btn = sender as Button; if (btn == null) return;
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
As a rule, I like to have one exit point for functions, but I sometimes make an exception for initial state checks. Which do you prefer Button btn = sender as Button; if (btn != null) { } OR Button btn = sender as Button; if (btn == null) return;
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
First one...
------------------------------------------- Don't walk in front of me, I may not follow; Don't walk behind me, I may not lead; Just bugger off and leave me alone!!
-
I agree with that, in theory. But, if you need to check 4 variables at the top of your code, and if they cascade, so that you need to use each one to grab the next, so it can't be done in one line, you end up with four nested brackets, which make the code harder to read, and you need to read all of the function, to verify that in fact, if that control was null, your code does nothing. So, I would advocate some basic checks at the top, which return, then one exit point over the body of a function, which ideally is no longer than 30 lines of code.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
I generally go with the second one...
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
I tend to the second also, if it's a case of 'if this isn't true, I can't do anything here', especially when I presume that it will always be true, I just want to make sure I add checks for my assumptions. Especially in event code, which the framework may call before I want it called ( as in, during initialisation ), and my code will stop an intermittent crash, or make the designer work, but once the program is up and running, I can be sure the check is never going to fail.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
As a rule, I like to have one exit point for functions, but I sometimes make an exception for initial state checks. Which do you prefer Button btn = sender as Button; if (btn != null) { } OR Button btn = sender as Button; if (btn == null) return;
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
The 2nd one, but I'd add a comment to remind myself why I did what I did when I revisit the code several months later, even though it may be obvious to me today.
// Only interested in events sent by buttons because ...
Button btn = sender as Button;
if (btn == null)
return;/ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
As a rule, I like to have one exit point for functions, but I sometimes make an exception for initial state checks. Which do you prefer Button btn = sender as Button; if (btn != null) { } OR Button btn = sender as Button; if (btn == null) return;
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
The last one. I hate tracing all the way through a method - whether reading it or actually stepping in the debugger - only to find that there is no alternate code path. If it's a sanity check, if the method does nothing when the condition fails, then i want to know that from the start. I mean, just think about it - if you were asking me the question aloud, "Shog, what happens if btn is null?" - and i replied, "well, CG, if it isn't null, then we change the text and the color and attach a little icon which we load from resources, and if the user is logged in then we enable it but otherwise we disable it and set up a tool tip with a little message explaining that they have to log in, and"... at this point, you should have already hit me upside the head with a 2x4, having had plenty of time to go out and buy a 2x4 while i was busy reading off the novella that was the tooltip text... My point here is that you wouldn't put up with that sort of madness in any other medium, so why allow it in code? Also, i hate excessive indentation.
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger, Online Poker Players?
-
The 2nd one, but I'd add a comment to remind myself why I did what I did when I revisit the code several months later, even though it may be obvious to me today.
// Only interested in events sent by buttons because ...
Button btn = sender as Button;
if (btn == null)
return;/ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
Yeah, comments are always good. I do like to do it in one line, maybe I feel a *little* dirty about the multiple exit points, so I make it as small as I can if (btn == null) return;
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
The last one. I hate tracing all the way through a method - whether reading it or actually stepping in the debugger - only to find that there is no alternate code path. If it's a sanity check, if the method does nothing when the condition fails, then i want to know that from the start. I mean, just think about it - if you were asking me the question aloud, "Shog, what happens if btn is null?" - and i replied, "well, CG, if it isn't null, then we change the text and the color and attach a little icon which we load from resources, and if the user is logged in then we enable it but otherwise we disable it and set up a tool tip with a little message explaining that they have to log in, and"... at this point, you should have already hit me upside the head with a 2x4, having had plenty of time to go out and buy a 2x4 while i was busy reading off the novella that was the tooltip text... My point here is that you wouldn't put up with that sort of madness in any other medium, so why allow it in code? Also, i hate excessive indentation.
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger, Online Poker Players?
Yeah, that pretty much sums up my position.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Yeah, comments are always good. I do like to do it in one line, maybe I feel a *little* dirty about the multiple exit points, so I make it as small as I can if (btn == null) return;
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Christian Graus wrote:
maybe I feel a *little* dirty about the multiple exit points
This seems overly purist to me, for reasons unknown. Where do you draw the line with one exit point? If you're in nested for loops and you get to where you're ready to return, do you use a goto to go to the end? Or set a flag and break? Ridiculous. I go with method two - I don't care how many years from now I look at it - in a reasonably sized method/function I can see the exit points clearly. My 2 cents :) Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Christian Graus wrote:
maybe I feel a *little* dirty about the multiple exit points
This seems overly purist to me, for reasons unknown. Where do you draw the line with one exit point? If you're in nested for loops and you get to where you're ready to return, do you use a goto to go to the end? Or set a flag and break? Ridiculous. I go with method two - I don't care how many years from now I look at it - in a reasonably sized method/function I can see the exit points clearly. My 2 cents :) Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
Mark Salsbery wrote:
Where do you draw the line with one exit point?
Honestly ? Where it makes sense. But, I would always look for a single exit point, no question.
Mark Salsbery wrote:
If you're in nested for loops and you get to where you're ready to return, do you use a goto to go to the end? Or set a flag and break?
I'd probably write it so that it breaks, and work out that it broke, I sure would not use a goto. But, I may look to see if there's a more readable way to write it. At the end of the day, if I have to write convoluted code to conform to an ideal, I would set out to avoid doing that. But, I do have an ideal in mind, and I will try to achieve it.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
I agree with that, in theory. But, if you need to check 4 variables at the top of your code, and if they cascade, so that you need to use each one to grab the next, so it can't be done in one line, you end up with four nested brackets, which make the code harder to read, and you need to read all of the function, to verify that in fact, if that control was null, your code does nothing. So, I would advocate some basic checks at the top, which return, then one exit point over the body of a function, which ideally is no longer than 30 lines of code.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
IMO -- multiple exit points for a function, is akin to the dreaded "goto" -- in that it is a poor programming practice. Personally, I prefer nested code, where you wind in, and then back out -- there is a certain degree of balance and beauty to it when done correct -- however I know I am probably in the minority. The authoritive solution to excessive nesting is supposed to be the creation of more modular functions and/or the introduction of the entire concept of exception handling -- not more returns.
-
The last one. I hate tracing all the way through a method - whether reading it or actually stepping in the debugger - only to find that there is no alternate code path. If it's a sanity check, if the method does nothing when the condition fails, then i want to know that from the start. I mean, just think about it - if you were asking me the question aloud, "Shog, what happens if btn is null?" - and i replied, "well, CG, if it isn't null, then we change the text and the color and attach a little icon which we load from resources, and if the user is logged in then we enable it but otherwise we disable it and set up a tool tip with a little message explaining that they have to log in, and"... at this point, you should have already hit me upside the head with a 2x4, having had plenty of time to go out and buy a 2x4 while i was busy reading off the novella that was the tooltip text... My point here is that you wouldn't put up with that sort of madness in any other medium, so why allow it in code? Also, i hate excessive indentation.
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger, Online Poker Players?
-
As a rule, I like to have one exit point for functions, but I sometimes make an exception for initial state checks. Which do you prefer Button btn = sender as Button; if (btn != null) { } OR Button btn = sender as Button; if (btn == null) return;
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
The second. I find that the second approach allows me to forget about having to think about the null case before reading/writing the meat of the function.
Regards Senthil [MVP - Visual C#] _____________________________ My Blog | My Articles | My Flickr | WinMacro
-
As a rule, I like to have one exit point for functions, but I sometimes make an exception for initial state checks. Which do you prefer Button btn = sender as Button; if (btn != null) { } OR Button btn = sender as Button; if (btn == null) return;
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
I guess I tend to go with the 1st, though it sometimes depends.
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
-
As a rule, I like to have one exit point for functions, but I sometimes make an exception for initial state checks. Which do you prefer Button btn = sender as Button; if (btn != null) { } OR Button btn = sender as Button; if (btn == null) return;
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
I tend to the second also, if it's a case of 'if this isn't true, I can't do anything here', especially when I presume that it will always be true, I just want to make sure I add checks for my assumptions. Especially in event code, which the framework may call before I want it called ( as in, during initialisation ), and my code will stop an intermittent crash, or make the designer work, but once the program is up and running, I can be sure the check is never going to fail.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
I would actually give it some kind of return value. In this case, return a false if nothing can be done, or something like that.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
-
As a rule, I like to have one exit point for functions, but I sometimes make an exception for initial state checks. Which do you prefer Button btn = sender as Button; if (btn != null) { } OR Button btn = sender as Button; if (btn == null) return;
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
For C++ the first one. I think it was something to do with the compiler code generation and stack winding. The C++ compiler generated lot more code in machine language when a function had multiple return points. For C#, Java, VB.NET etc, the second one: Since the code gets compiled to IL first and then into Machine language. My experiments revealed that there was not much difference in code generation.
-
As a rule, I like to have one exit point for functions, but I sometimes make an exception for initial state checks. Which do you prefer Button btn = sender as Button; if (btn != null) { } OR Button btn = sender as Button; if (btn == null) return;
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
I like the one-entrance-one-exit style because I think it is technically beautiful. And I like the other style because it is easier conceptualize the logic. I would prefer to use the first way as long as the decisions don't become too numerous and indented, and I would switch to the second way as soon as the first way became unwieldy. That's actually one of the ways we technical nerds gain an opportunity for artistic expression. Don't tell yourself that you must choose one or the other. Tell yourself that you will know when to use either one!
-------------------------------- "All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke
-
As a rule, I like to have one exit point for functions, but I sometimes make an exception for initial state checks. Which do you prefer Button btn = sender as Button; if (btn != null) { } OR Button btn = sender as Button; if (btn == null) return;
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
I use the second style. Although multiple exit points, it is still top-down, so debugging or tracing how things happen is not so bad. With the first case if you have multiple conditions to test, you end up with code staring on the 40th column and a lot of braces. I guess that is more confusing than keeping the main code at the first ident label. Also, the multiple-exit points for debugging argument is slashed by saying that if the funcion returns null at the very end, you still have to find which of the 8 ifs failed.
Luis Alonso Ramos Intelectix Chihuahua, Mexico
-
The last one. I hate tracing all the way through a method - whether reading it or actually stepping in the debugger - only to find that there is no alternate code path. If it's a sanity check, if the method does nothing when the condition fails, then i want to know that from the start. I mean, just think about it - if you were asking me the question aloud, "Shog, what happens if btn is null?" - and i replied, "well, CG, if it isn't null, then we change the text and the color and attach a little icon which we load from resources, and if the user is logged in then we enable it but otherwise we disable it and set up a tool tip with a little message explaining that they have to log in, and"... at this point, you should have already hit me upside the head with a 2x4, having had plenty of time to go out and buy a 2x4 while i was busy reading off the novella that was the tooltip text... My point here is that you wouldn't put up with that sort of madness in any other medium, so why allow it in code? Also, i hate excessive indentation.
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger, Online Poker Players?
> Also, i hate excessive indentation. One day when reviewing resumes, a coworker told me -- never read each from top to bottom -- read backwards -- from the bottom up -- because the most important information is at the bottom, not the top. I think that applies to your reply as well. Obviously, your ultimate point was that you hate excessive indentation. Excessive indentation, however (as per best programming practices), is not solved by multiple returns -- but instead through other means.
