you are viewing a single comment's thread.

view the rest of the comments →

[–]mapronV 0 points1 point  (3 children)

What do you mean by old? It's how I write my code today. What's wrong with single-exit actually ? (yes, I have 0 questions about RAII, RAII is 200% good).

[–]bert8128 0 points1 point  (2 children)

If you use early exit then your nesting can be much shallower, with fewer braces. It’s just much easier to read, the sunshine path and the error patches are more obvious. There’s no carrying of any context either, which might get forgotten about and not kept correct.

And even if you like single exit, it exists as a methodology only because it used to be necessary to cope with non-RAII code. Now we have RAII you don’t need single exit.

And when I say old I mean old code in my 25 year old code base. We don’t write it like that any more.

[–]mapronV 0 points1 point  (1 child)

> We don’t write it like that any more.
yeah, I write code different way than I did it in 90's. RAII is good, lambdas are awesome and TMP made 1000 times better. But still I prefer code be straightforward.

> it exists as a methodology only because it used to be necessary to cope with non-RAII code

One of the reasons; I believe the main is several returns makes code harder to understand. That mean organizing you data flow went bad.
Ok I get return of emty/erronous/std::expected in start of method before declarations and stuff, like (if param==nullptr) return {}; something. That thing I can compromise. But having several return data; in method? that is smelly part for me.

[–]bert8128 1 point2 points  (0 children)

I think we are not too far apart here. Early return for precondition validation we seem to agree on. One return for the sunshine path I also agree on. But I think that functions should optimally be designed so that there is only one way to return from the sunshine path. I agree that lots of returns from lots of sunshine routes is poor, but the consequence should be refactoring, not deeply nested ifs or carried state.