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 )
It depends how much state the method is carrying along with it when you exit. As long as you don't have to delete objects or readjust state of shared objects in order to return from the method I say go for it. The reason multiple exit points are considered bad is that if you have to clean up your state before you return, you end up duplicating that cleanup with every exit point, which leads to duplicate code which is hard to maintain. In procedural code, there isn't any way to get around that other then writing cleanup methods, which is ugly since you are writing an extra function just so you can exit cleanly from another method. In object oriented code you can have a number of classes that perform generic operations and reset state on destruction/disposal so you can manage state cleanly, and still focus on writing the code that is easiest to maintain. Also, I never write an if statement in under 2 lines.
if (btn == null)
return;or
if (btn == null)
{
//do something
//do something else
}
This blanket smells like ham
-
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 second style is the better in this case. in order to not feel so 'dirty' think of it as a form of pre-condition check - if the language supported pre and post conditions you would do the check there. multiple exit points from within the method are not such a great idea, as Jackson said. The key thing is to keep the complexity of the code down. The early exits for parameter checks accomplish this - exit points in the middle of the method are unlikly to and it might be better to restructure the code and/or create more functionaly cohesive methods. In reply to another email you don't really need to put comments in here as it is pretty obvious what is going on as the checks are so early.
-
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 )
I like the second one, since that one supports the "happy flow" principle I use at work. This principle states that the code should have a main flow that runs all the way to the end and not have too much if() { } else { if() { } else { } } statements.
WM. What about weapons of mass-construction? "What? Its an Apple MacBook Pro. They are sexy!" - Paul Watson My 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'm similar to you. I generally go for one exit point but occasionally it's simpler to return after an initial check fails.
Kevin
-
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?
Shog9 wrote:
i hate excessive indentation.
Me too. Though if methods are as short as good style says they should be there should not be an excuse for excessive indentation.
Kevin
-
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 )
If the function is relatively short (will fit on my screen without scrolling) I go with option 1. If it's longer, I go with option 2. I don't mind a lot of indentation as long as the code is formatted appropriately and there's a dearth of comments. Also, if a function does exceed the height of my screen, I try to find ways to abstract some the functionality into smaller re-usable functions. Some of the code I've had to maintain over the last three years had functions in it that exceeded 500 lines, and some files exceeded 6000 lines. Those were a pain in the ass to debug.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
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 go with second one as i find it easier and makes more sence to me. if(btn == null) return; i have the return on a second line.
Code Project Lounge 101 by John Cardinal :beer::bob::beer:
-
If the function is relatively short (will fit on my screen without scrolling) I go with option 1. If it's longer, I go with option 2. I don't mind a lot of indentation as long as the code is formatted appropriately and there's a dearth of comments. Also, if a function does exceed the height of my screen, I try to find ways to abstract some the functionality into smaller re-usable functions. Some of the code I've had to maintain over the last three years had functions in it that exceeded 500 lines, and some files exceeded 6000 lines. Those were a pain in the ass to debug.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
Some of the code I've had to maintain over the last three years had functions in it that exceeded 500 lines, and some files exceeded 6000 lines. Those were a pain in the ass to debug.
Tell me about it! :mad:
Kevin
-
John Simmons / outlaw programmer wrote:
Some of the code I've had to maintain over the last three years had functions in it that exceeded 500 lines, and some files exceeded 6000 lines. Those were a pain in the ass to debug.
Tell me about it! :mad:
Kevin
-
If the function is relatively short (will fit on my screen without scrolling) I go with option 1. If it's longer, I go with option 2. I don't mind a lot of indentation as long as the code is formatted appropriately and there's a dearth of comments. Also, if a function does exceed the height of my screen, I try to find ways to abstract some the functionality into smaller re-usable functions. Some of the code I've had to maintain over the last three years had functions in it that exceeded 500 lines, and some files exceeded 6000 lines. Those were a pain in the ass to debug.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
Some of the code I've had to maintain over the last three years had functions in it that exceeded 500 lines, and some files exceeded 6000 lines.
That is way too excessive. Gotta stick to it being able to fit on the screen all at once. Hope the original coder doesn't work there anymore...
"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 )
The first, always. Though of course I'd probably use
israther thanas. -
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 )
neither. i try to avoid dogmatically following arbitrary rules. i let the problem design the code, instead of forcing the problem into a template.
image processing toolkits | batch image processing | blogging
-
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 too use the second style for initial state checks, but sometimes I get a little lazy and use it in other places. Of course, in these modern days where methods throw exceptions, the single exit point has become a bit moot.
Michael Thanks to all for your kind words and support on my return to CP. This place and you guys and gals are just the best
-
achimera wrote:
Excessive indentation, however (as per best programming practices), is not solved by multiple returns -- but instead through other means.
Wait, are you implying i need to reduce my tab size... :suss: ;)
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?
Shog9 wrote:
Excessive indentation
This has ceased to be a problem for me ever since I started writing code in MS Word. /ravi PS: Your sig is unreadable (moved below the boundary of the light blue reply area) in IE. Dunno if that's intentional. See this[^] screenshot.
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 )
-
John Simmons / outlaw programmer wrote:
Some of the code I've had to maintain over the last three years had functions in it that exceeded 500 lines, and some files exceeded 6000 lines.
That is way too excessive. Gotta stick to it being able to fit on the screen all at once. Hope the original coder doesn't work there anymore...
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
Paul Conrad wrote:
Hope the original coder doesn't work there anymore.
He dopes, but it doesn't matter. I turned in my two-week notice last week. :)
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Paul Conrad wrote:
Hope the original coder doesn't work there anymore.
He dopes, but it doesn't matter. I turned in my two-week notice last week. :)
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
He dopes, but it doesn't matter.
Yeah, it does. People on dope can't code...
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
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 )
I prefer the 1st one since 1) its easier to debug w/one exit point 2) its easier to enforce.
Todd Smith
