Programming style

[Mark Salsbery]

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]

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 )

[achimera]

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.

[Ravi Bhavnani]

Shog9 wrote:

Also, i hate excessive indentation.

Agreed. It can make code hard(er) to read. Perhaps the best reason for choosing #2. /ravi

This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com

[S Senthil Kumar]

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

[Jim Crafton]

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

[Nemanja Trifunovic]

There was a similar discussion[^] at Artima recently.

---

Programming Blog utf8-cpp

[Paul Conrad]

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

[Rama Krishna Vavilala]

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.

[Richard Andrew x64]

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

[Luis Alonso Ramos]

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

My Blog!

[achimera]

> 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.

[Shog9 0]

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?

[Leslie Sanford]

Christian Graus wrote:

As a rule, I like to have one exit point for functions, but I sometimes make an exception for initial state checks.

I call these "guards." Typically, I set them off from the rest of the method:

public void SetSomeValue(int value)
{
#region Guard

if(value == someValue)
{
    return;
}

#endregion

// Expensive operation here.

}

The guard prevents the method from running if doing so would be redundant and more importantly expensive. I look at guards as being different from preconditions. It's possible for the preconditions of a method to have been met but to have triggered the guard nontheless. As long as the postconditions of the method are still met, then everything's cool. After the guard, I generally avoid early returns, but bend this rule from time to time.

[Andy Brummer]

Well said.

---

This blanket smells like ham

[Andy Brummer]

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

[Andrew Drummond]

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.

[Lost User]

The first, it is clear why you are returning.

Visit http://www.readytogiveup.com/[^] and do something special today.

[WillemM]

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

[Kevin McFarlane]

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