Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

PeterRitchie — Sun, 15 Jun 2008 16:37:01 GMT

In most OO languages you can allocate data as needed, not like most procedural languages where you have to allocate data at the top of a function.

If you get away from that procedural method of allocation, SESE becomes very difficult--time better spent writing value-added code.

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

Eric Eilebrecht — Sun, 15 Jun 2008 15:39:26 GMT

I always thought the big benefit of SESE was that it allowed you to do some things at the top of the method (set up data structures, validate args, etc.) or at the end of the method (cleanup, etc.) and be sure that those things would actually be executed.

OO doesn't have anything to do with this. Exceptions do foil it, as many have pointed out.

But every modern language I'm familiar with has some way of automating back-out/cleanup code. C++ stack-allocated object destructors, most other languages' "finally" constructs, etc. And the single-entry thing is just assumed these days (coroutines are not an exception to this; a C# iterator method is conceptually a single method with a single entrypoint - the fact that the compiler breaks it up is an implementation detail. You still get to do some initialization at the top, and any cleanup can be put in finally blocks that will run with the enumerator is disposed.)

I've found that most people who try to religiously follow the SESE ideal don't end up writing the kind of code people have been posting here (with lots of nice nested ifs and such.) What they do is write a bunch of "goto CLEANUP;" statements, and then do their cleanup at the end. This is an abomination in a world that has "finally" or its equivalents.

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

Gopi Chand — Thu, 05 Jun 2008 02:05:08 GMT

We don't have to go overboard with the "single exit" rule but I have seen code that doesn't even attempt to reduce the number of exits. For instance the following code taken from one of the posts above...

public static bool IsNullOrEmpty(string value)

{

if (value != null)

{

return (value.Length == 0);

}

return true;

}

... can be rewritten as follows (by putting short-circuit booleans to good use):

public static bool IsNullOrEmpty(string value)

{

return value == null || value.Length == 0;

}

See how the implementation matches the method name.

I sincerely believe that structured programing is an art that vastly reduces code complexity and those that don't believe in it don't know what they are missing. With the exception of exceptions/gaurds/assertions, it's easy enough to write code with a single exit. Nesting can be minimized by breaking down large methods into smaller ones. If a method is over a page long, it's probably too long.

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

Jason — Tue, 06 May 2008 15:57:35 GMT

I view "return" and "exception" differently. A return is the path back from a method, while an exception is...well, an exception. I will aim towards having a single return, and an exception whereever it is logical.

I generally dispise multiple return statements. I can't recall having a real problem (either authoring, or reading others' code) with overly deep nesting, and I think this can be addressed with other coding practices and guidlines.

If you have four nestings or four return statements, your method is likely not refactored to begin with.

All this being said, I think the most important and unbreakable rule is that all the rules can be broken if done with thought and reason. I have seen a few cases where there have been multiple returns and have thought, "Ok...that makes sense..."

Now, let's get to a real topic of contention: ternary operation!!

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

PeterRitchie — Sun, 04 May 2008 13:43:08 GMT

A method all on it's own as shown as an example can't really assume anything; which is why the example checks parameters. It's advisable for any publicly available method to always check it's arguments.

What if(!(text is string)) actually compiles to is:

if(text == null)

Replacing that with String.IsNullOrEmpty avoids having to begin a for loop with no iterations. So, we're back to what I have (minus the extraneous Length check, that someone else pointed out).

But, for some algorithms you don't want to throw an exception. Let's say we did throw an exception if we passed an invalid string (in your example). What would it mean to an algorithm that needs the count of commas in a string? If it doesn't pass a valid string, would it continue processing any differently if it caught the exception? I.e. it's likely just going to assume in the light of an InvalidArgumentException that what it passed obviously doesn't have an commas in it and process as such.

But, the point isn't to write a perfect CountCommas method, it's just an academic example showing the difference between SESE and non-SESE styles.

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

Sun, 04 May 2008 13:21:37 GMT

The preconditions should not have to be checked. As they are assumed to be valid.

int CountCommas(string text)

{

// pre: text is a string

// we add overhead to check if the text is a string (which is a bit of misplaced check imho)

if (!(text is string))

{

// maybe this is only possible if text == null but then, how would we know if this holds in the near future

// maybe in the near future we can also call CountCommas(infinitestringofcommas); where infinitestringofcommas is a new type

// so we cannot anticipate on the text being null

throw new ArgumentException("text is not a valid string");

}

// lets count comma's

int N = text.Length;

int numberOfCommas = 0;

for (int n = 0; n != N; n++)

{

if (text == ',')

{

numberOfCommas++;

}

// one exit

return numberOfCommas;

}

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

Kumosan — Mon, 28 Apr 2008 07:23:22 GMT

There is no rule in software development, which cannot be broken, when there is a pressing need to do so. For some rules this justification is harder (rarer) to find, for some rules it is easier to find. IMHO the SESE rule is one of the weakest rules, i.e. it is very easy to find examples where it makes sense to break SESE in many real world examples. Personally I prefer to avoid long if/else if constructs and replace them with many similar looking code blocks:

if(statement1)

{

do stuff

return

}

if(statement2)

{

so stuff2

return;

}

If 'statements' and 'do stuffs' are similar in size and function this is very easy to read and understand. If there are only two or three such blocks I usually don't bother and let them as they are. If there are more it is easy to see where to refactor and to apply a behavioral pattern like state, strategy or command. This very often leads back to a heeded SESE rule.

Single-Entry, Single-Exit em Java ?! « TJRN Developers

Single-Entry, Single-Exit em Java ?! « TJRN Developers — Mon, 07 Apr 2008 01:25:55 GMT

Pingback from Single-Entry, Single-Exit em Java ?! « TJRN Developers

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

David Nelson — Fri, 14 Mar 2008 02:08:15 GMT

Like pretty much every programming concept/idiom/pattern ever conceived, its not a black and white issue. Religiously adhering to or ignoring SSEE will not make more readable code. Single-exit can create deep nesting or excessive guard clauses; multiple-exit can result in code that is hard to trace by visual inspection. Both of these are undesirable; the key is finding an appropriate balance between the two by understanding the pros and cons of each. As always, there is no silver bullet.

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

PeterRitchie — Tue, 11 Mar 2008 20:45:52 GMT

@Dave: multiple exceptions in a method is multiple exits, not single exit. The argument for a single exit with regard to return statements is easier to take than a single throw per method; but they're tantamount the same thing.

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

Dave — Tue, 11 Mar 2008 20:25:35 GMT

I would submit that throwing exceptions whenever they need to be thrown (throughout the method when they are encountered) and having at most one return statement in each function doesn't have to be conflicting.

For example, look at the last chunk of code you wrote. That is the one I prefer. Maybe this means I'm not strict SESE? If so thats fine. Being strict anything is limiting.

What if you want to add some form of tracing at the end of a method to log the result?

What if there is some extra work you need to do on the return value before it leaves the method?

If I am stuck with debugging 1 of 2 existing projects... One with all methods having (potentially) multiple exit points anywhere in the method. Versus another with all methods having exactly 1 exit point. I know which one I'm choosing.

That said, I do recognize the issue of deeper nesting and that IS a problem.

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

PeterRitchie — Tue, 11 Mar 2008 14:54:04 GMT

@Dave: multiple return statements in a method does not preclude being able to set a break-point at the end of a method to break when the method is complete. "return" is just a language syntax detail; pretty much every language must generate prolog and epilog code for methods, meaning it does implement an single exit; but that's an implementation detail of the language. SESE was created before these high-level languages started doing this, and is useful is that particular context. But, in higher-level languages this "sense of security" makes you limit what you can do with evolving capabilities of the language. Point in case are exceptions, it makes no sense for them to follow single-exit; which means you now have conflicting (confusing, hard-to-maintain, hard to test, etc.) styles.

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

Dave — Tue, 11 Mar 2008 14:13:34 GMT

I still use the single exit strategy. I sometimes wince when I am reading someone elses method and halfway through I see return statement.

I like the ability to set a break point at the very end of a function and let the code run to see what i'm going to get while still being in the context of that method.

Theres something reassuring about knowing all code paths will leave my function at 1 spot and 1 spot only. That way if I later find myself needing to .ToUpper() my string result or something, I only need to do it in 1 spot.

And as far as exceptions go, I throw them at the point they need to be thrown rather than holding onto them.

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

Troy DeMonbreun — Mon, 10 Mar 2008 17:57:45 GMT

@Peter

Gotcha. :-)

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

PeterRitchie — Mon, 10 Mar 2008 14:15:54 GMT

@Troy: I choose a academic example that was supposed to exemplify multiple returns. A caveat of "pay no attention to the logic" should have been added :-). It's an academic example that shows two different ways of implementing some logic (one where null/zero-length strings are not errors, and one where they are--and generate exceptions).

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

Ron — Mon, 10 Mar 2008 13:47:00 GMT

I agree with the idea of multiple exit points. Your example shows how much cleaner the code can look (by the way, the length==0 check is superflouous, String.IsNullOrEmpty already checks that).

However, when you're dealing with developers who aren't exactly the brightest of the bunch, on large projects, you end up with massive multi-thousand-line functions that have dozens of exit points, and it becomes an absolute maintenance nightmare. However, this is more a problem with huge functions than it is with the multi-exit principle.

So yeah, I completely agree that SEME is a good idea, but you just need to make sure your team isn't dumb enough to make functions more than 2-3 dozen lines long.

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

vP — Mon, 10 Mar 2008 11:32:22 GMT

I often use a flag to keep track whether operations are successful or not. This can give us SESE approach without too deep nested structures. As exceptions should be exceptional, I'd rather throw them right away in the beginning of a method, just like the last example has done.

The final solution takes a shortcut. If the business case would require the method to handle null (not likely) and String.Empty objects (more likely), more checks are required in code.

Here is my take for comma counter with flag variable.

public static int CountCommas(string text){

// Exceptions would be thrown right here. Maybe for null parameter?

// Non-exceptional code starts here.

bool success;

int result = 0;

success = !String.IsNullOrEmpty(text) ? true : false;

if(success){

success = text.Length > 0 ? true : false;

}

if(success){

int index = 0;

while (index > 0){

index = text.IndexOf(',', index);

if (index > 0){

++result;

}

return result;

}

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

Matt — Mon, 10 Mar 2008 08:44:18 GMT

Just for the ones that don't know, checking text.Length is included in IsNullOrEmpty():

public static bool IsNullOrEmpty(string value)

{

if (value != null)

{

return (value.Length == 0);

}

return true;

}

Reflective Perspective - Chris Alcock » The Morning Brew #49

Reflective Perspective - Chris Alcock » The Morning Brew #49 — Mon, 10 Mar 2008 08:21:03 GMT

Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #49

re: Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages?

Nikola Malovic — Mon, 10 Mar 2008 06:55:52 GMT

I am not following the Single Exit mantra because it leads to multi level nested statements and in case that level>3 that is very hard to read

Instead of SESE mantra, I prefer Fowler "Guard clause" style which IMHO increase code readibility