Then perhaps the code you are trying to extract doesn't make a clear and cohesive procedure. Maybe include more or less of the code, or rework the code into logical pieces or steps. Write the algorithm in human language first, then implement the steps using functions.
Pick something and change it when inspiration strikes. Sometimes you need a big picture view of something to get the right abstractions or even just name things.
I mean, I certainly wouldn't give someone else shit for using ligatures, but personally, I don't like them, because:
they break with monospacedness. Everything is in a nice grid and you've randomly got these character combinations that needlessly stick out.
they sometimes happen in places where they really shouldn't.
they hide what the actual characters are. Especially, if go to edit that code, my brain will really struggle for a split-second when there's a '≠', then I delete one character and rather than the whole thing disappearing, I'm left with a '!'.
Sure, I could get used to it. But it being more readable is not even true for me, because the thing I got used to instead, is that != is the unequals-operator. I see that much more often than ≠.
For monospace fonts? I've heard of such research for proportional fonts, where ligatures definitely make sense to me. But yeah, I wouldn't assume such research to automatically translate to monospace.
Oh, yeah, I meant that it makes two characters into one big one, visually reaching across two or three widths, or just having one of the characters larger than the usual grid, e.g. in := the equals sign reaches into the width of the colon.
This reminds me of a recent Microsoft font¹, so naturally here's a rant about that: They developed a feature, called "texture-healing", which basically allows characters that normally need to cramp into one monospace width, like m or w, to reach into the space of neighboring characters, if those neighboring characters are narrow, like an i.
Ligatures are great. Don't use them if you don't like them, but don't try to shame people for having different preferences.
The biggest exception to using ligatures is in documentation. I believe Kotlin used (uses?) ligatures in some of its documentation, leaving the reader to figure out if they actually need to type ≠ or if != will suffice. Not a great move, even if the IDE will render the ligatures just fine!
You can't read a block of code and as quickly and understand its control flow without reading every line, especially in regards to resource cleanup.
For example say you have:
...
if this:
something
or other
and many more...
...
else:
yet another thing
and some more
...
do some cleanup
return
...
Say you aren't exactly interested in what happens inside each branch. If you can assume that there's one return at the end of the block, you can see the if and else, you can reason about what values would trigger each branch, you can also see that no matter which branch is executed, the cleanup step will be executed before returning. Straightforward. I don't have to read all the lines of the branches to ensure the cleanup will be executed. If I can't assume a single return, I have to read all those lines too to ensure none of them jumps out of the function skipping the cleanup. Not having to think about such cases reduces the amount of reading needed and it makes reasoning about the block simpler. The bigger the blocks, the more the branches, the stronger the effect. You have one less foot-shotgun to think about. The easier you make it for your brain, the fewer mistakes it's gonna make. For all those days when you haven't slept enough.
E: Oh also refactoring blocks of code out into functions is trivial when you don't have multiple returns. Extracting a block with a return in it breaks the parent control flow and requires changes in the implementation.
E2: Shorter blocks do not obviate this argument. They just make things less bad. But they make almost everything less bad. Shorter blocks and single returns make things even better.
Early out makes the error conditions explicit, which is what one is interested in 90% of the time. After the last if you know that all of the above conditions are false, so you don’t need to keep them in your head.
And this is just a silly example with 3 predicates, imagine how a full function with lots of state looks. You would need to keep the entire decision tree in your head at all times. That’s the opposite of maintainable.
I'm sure you are capable of rewriting that in 3 lines and a single nested scope followed by a single return. In fact in languages that use exceptions you have to use at least one subscope.
Notice that in my example I didn't even broach the example with error conditions, cause it's trivial to write cleanly either way. Instead I talked about returns inside business logic. You can't unfuck that. 🐞
Since my previous example didn't really have return value, I am changing it slightly. So if I'm reading your suggestion of "rewriting that in 3 lines and a single nested scope followed by a single return", I think you mean it like this?
int retval = 0;
// precondition checks:
if (!p1) retval = -ERROR1;
if (p2) retval = -ERROR2;
if (!p3 && p4) retval = -ERROR3;
// business logic:
if (p1 && !p2 && (p3 || !p4))
{
retval = 42;
}
// or perhaps would you prefer the business logic check be like this?
if (retval != -ERROR1 && retval != -ERROR2 && retval != -ERROR3)
{
retval = 42;
}
// or perhaps you'd split the business logic predicate like this? (Assuming the predicates only have a value of 0 or 1)
int ok = p1;
ok &= !p2;
ok &= p3 || !p4;
if (ok)
{
retval = 42;
}
return retval;
Using a retval has the exact problem that you want to avoid: at the point where we do return retval, we have no idea how retval was manipulated, or if it was set multiple times by different branches.
It's mutable state inside the function, so any line from when the variable is defined to when return retval is hit must now be examined to know why retval has the value that it has.
Not to mention that the business logic then needs to be guarded with some predicate, because we can't early return. And if you need to add another precondition check, you need to add another (but inverted) predicate to the business logic check.
You also mentioned resource leaks, and I find that a more compelling argument for having only a single return. Readability and understandability (both of which directly correlate to maintainability) are undeniably better with early returns. But if you hit an early return after you have allocated resources, you have a resource leak.
Still, there are better solutions to the resource leak problem than to clobber your functions into an unreadable mess. Here's a couple options I can think of.
Don't: allow early returns only before allocating resources via a code standard. Allows many of the benfits of early returns, but could be confusing due to using both early returns and a retval in the business logic
If your language supports it, use RAII
If your language supports it, use defer
You can always write a cleanup function
Example of option 1
// precondition checks
if(!p1) return -ERROR1;
if(p2) return -ERROR2;
if(!p3 && p4) return -ERROR3;
void* pResource = allocResource();
int retval = 0;
// ...
// some business logic, no return allowed
// ...
freeResource(pResource);
return retval; // no leaks
Example of option 2
// same precondition checks with early returns, won't repeat them for brevity
auto Resource = allocResource();
// ...
// some business logic, return allowed, the destructor of Resource will be called when it goes out of scope, freeing the resources. No leaks
// ...
return 42;
Example of option 3
// precondition checks
void* pResource = allocResource();
defer freeResource(pResource);
// ...
// some business logic, return allowed, deferred statements will be executed before return. No leaks
// ...
return 42;
Example of option 4
int freeAndReturn(void* pResource, const int retval)
{
freeResource(pResource);
return retval;
}
int doWork()
{
// precondition checks
void* pResource = allocResource();
// ...
// some business logic, return allowed only in the same form as the following line
// ...
return freeAndReturn(pResource, 42);
}
Not sure why you had to do the inverted predicate check again in your first example. You already have the information encoded in the value of retval. It can be written like this:
int result = 0;
if (!p1) result = -ERROR1;
if (p2) result = -ERROR2;
if (!p3 && p4) result = -ERROR3;
if (result != 0) {
result = 42;
}
return result;
With a return value you have to add 4 extra lines. This overhead remains constant as you add more checks and more business logic.
Yes all the other suggestions are better than early returns in business logic and would help with leaks. Would be nice if we had RAII outside of C++. I think Rust has it? Haven't done Rust yet.
Early returns are very similar to gotos. One level of nesting to take care of validation is trivial in comparison. You're replacing logical clarity for minimal visual clarity. This is true regardless of the size of the function which shows that the size of the function isn't the determinant. You're not alone in your opinion, clearly, and I'm not going to convince you it's a bad practice but I'll just say what I think about it. 😅 This practice doesn't make it my team's codebase.
You can say any execution flow controls are like gotos - continue, break, exceptions, switch, even ifs are not much more than special cases of gotos.
This is true regardless of the size of the function which shows that the size of the function isn’t the determinant
Logical clarity does tend to worsen as the function grows. In general, it is easier to make sense of a shorter function than a longer one. I don't know how you could even say otherwise.
Early returns are still great for argument validation. The alternative means letting the function execute to the end when it shouldn't, just guarded by if conditions - and these conditions any reader would have to keep in mind.
When a reader comes across an early return, that's a state they can free from their reader memory, as any code below that would be unreachable if that condition was met.
I never said longer functions are not less clear. I said my argument is valid irrespective of the length of the function which shows that the problems I claim multiple returns bring are independent of function length. 😊
Any validation you can write with a few early returns you can write with an equivalent conditional/s followed by a single nested block under it, followed by a single return. The reader is free to leave if the validation fails nearly the same, they have to glance that the scope ends at the end of the function. Looks at conditional - that's validation, looks at the nested block - everything here runs only after validation, looks after the block - a return. As I mentioned in another comment, validation is a trivial case to do either way. Returns inside business logic past validation is where the problematic bugs of this class show up which requires more thorough reading to avoid.
If you gave me a PR with early returns only during validation, I probably won't ask you to rewrite it. If I see them further down, it's not going in.
Any validation you can write with a few early returns you can write with an equivalent conditional/s followed by a single nested block under it, followed by a single return. The reader is free to leave the validation behind just the same.
And that conditional indents your entire function one level - if you have more validation checks, that's one level of indentation per check (or a complicated condition, depends whether you can validate it all in one place). It's pretty much the case the other user illustrated above.
Returns inside business logic past validation is where the problematic bugs of this class show up
That much we agree. But again, this is not an early return issue, putting too much logic in a function is the issue. Rewriting it without early returns won't make it much clearer. Creating other functions to handle different scenarios will.
Again, if you can write it with conditionals and returns, you can write it with equivalent number of conditionals and a single nested scope. No further scopes are needed. The conditional will even look nearly identically.
If your function is so long that keeping track of returns becomes burdensome, the function is too long.
I'm not a fan of returning status codes, but that's a pretty clear example of early return validation where you can't just replace it with a single condition check.
Having a return value that you set in various places and then return at the end is worse than early return.
I don't think it's worse, I think it's equivalent. Also I don't like the risk of resource leaks which is inherent to multi-returns beyond input validation. And that's true beyond C because memory isn't the only resource that can be leaked.
It's not about how readable the branches are, it's about having to read all of them to ensure you understand the control flow so that you don't leak. Length of functions is a red herring. You want me to read the contents of short blocks to ensure the control flow is correct. I don't want to read the contents of those blocks, other than the conditional and loop statements. Reading short blocks is better than reading long blocks. Reading just the control flow lines is better than reading short blocks.
And I'm going to make you read those blocks because they are there for a damn reason. What are you even reading at this point if you're not reading the preconditions? That's how you end up dereferencing null pointers, when you have ten nested ifs you can barely see it on your screen
You said yourself they're equivalent. You either have to read the blocks in both cases or neither case.
You need to read the blocks to know what gets returned (either early or in a single return). You need to read the blocks to see what resources get created but not released. What are you hoping to achieve by only reading control flow?
At least with an early return you can stop reading.
What are you hoping to accomplish by only reading control flow and not the contents of the blocks? You keep raising concerns like not properly releasing resources, but if you don't read the blocks you don't know what resources we're allocated.
I think your argument depends on both having your cake and eating it.
Yes clearly someone has to read the blocks at least once to ensure they are correct.
In subsequent reads, when I'm interested in the second block out of two, say during a defect analysis, I don't have to read the first one to be sure I'm going to reach the second. I can straight head for the second one and any subsequent stuff I care about. Multiple returns force me to read both blocks. I don't know what else to tell you. To me this is obvious and I think it's probably even provable. I don't know about you but I have to read a lot of existing code and every bit helps. We have pretty strict code style guides for that reason.
If you're reading the control flow, and the control flow tells you the first block isn't being entered, then it doesn't matter if the first block contains an early return or not, because it wasn't being entered. If it was being entered then you have to read it anyway to make sure it's not manipulating state or leaking resources.
To use your example: in subsequent reads, when I'm interested in the second block out of n, say during defect analysis, I can head straight to the second block in either case since control flow shows the first block was skipped - but in the case of early return from the second block I can stop reading, but in the case of a single return I need to read the flow for all subsequent n blocks and the business logic of any subsequent blocks that get entered. The early return is a guarantee that all subsequent blocks may be ignored.
To me this is also obvious. I've been doing this for quite a while and 95% of the time, reviewing and debugging code with a single return is far more tedious.
Clearly I'm not referring to an if/else by saying two blocks. Even in my original example I show the exact issue. You don't understand it. I can't explain it better.
Have you stopped to consider why you can't explain it better? Perhaps the reason is because you're wrong.
Your toy example does not show the issue you think it shows. You've moved your cleanup block away from the context of what it's cleaning up, meaning that you've got variables leaking out of their scopes. Your cleanup code is now much more complex and fragile to changes in each of the blocks its cleaning up after.
You tried to use your toy example to show A is better, but then we showed that actually B is just as good. So fix your toy example to show what you actually want to say, because everything you said so far depends on you setting different standards for each scenario.
Have you stopped to consider why you can't explain it better? Perhaps the reason is because you're wrong.
Yes I have. You've already assumed I'm not too bright more than once and worked from there. There's no point in investing more work on my end. If what I said worked, good. If not, that's fine too.
I blame C for forcing users to use goto, conditional returns, or terribly nested code. Language features like defer or even try/catch/finally make it much easier to write readable code with limited returns.
In the screenshot it said x = *(++p) and iirc that is not the same as saying x = *(p++) or x = *(p += 1)
As in my example using ++p will return the new value after increment and p++ or p+=1 will return the value before the increment happens, and then increment the variable.
Or at least that is how I remember it working based on other languages.
I'm not sure what the * does, but I'm assuming it might be a pointer reference? I've never really learned how to code in c or c++ specifically. Though in other languages ( like PHP which is based on C ) there is a distinct difference between ++p and (p++ or p+= 1)
The last two behave the same. Though it has been years since I did a lot of coding. Which is why I asked.
I'll install the latest PHP runtime tonight and give it a try xD
But assuming it doesn't the context is p_ch = the bits above... the code declaring p_ch isn't shown but I'm guessing that the value here is actuality a pointer to a pointer so nothing illegal would be happening.
Lastly... C++ is really lacking in guarantees so you can assign a char to the first byte of an integer - C++ doesn't generally care what you do unless you go out of bounds.
The reason I'm casting to void* is just pure comedy.
That's not a real operator. You've put a space in "i--" and removed the space in "-- >". The statement is "while i-- is greater than zero". Inventing an unnecessary "goes to" operator just confuses beginners and adds something else to think about while debugging.
And yes I have seen beginners try to use <-- and --<. Just stop it.
The sheer number of people that do not expect a joke on this community... (Really, if you are trying to learn how to program pay attention to the one without the Humor on the name, not here.)
Did you know that in 1831 a group of seamstresses burned down a sewing machine factory because they were out of work. It wasn't really about the sewing machines, it was about the working conditions and the sewing machines were just a good bad guy
Ah yes, the cable kitties. First the orange one approached the food from the front, and all was well and simple if a little diagonal. Then the white one approached from the left. Now it could have gone around and kept things tidy, but that's not how cable kitties work. It walked right over the orange cable kitty's head and started eating. Then when the black cable kitty came from the right, there was only one food socket left. Now this cable kitty could have gone around, but cable kitties always take the shortest path. Up and over the black cable kitty went, and thus the tangle of cable kitties was complete.
I ain't no programmer, but I was a toolmaker and ME that designed machines to be used in factories. I learned to not be surprised at how operators could find new and interesting ways, (sometimes dangerous), run the machines I designed and built. They did things I never would have dreamed possible or meant with them.
I have one you should love. And by that I mean hate.
Over a decade ago I was installing some equipment I designed, training the operators, etc. There were electrical and software components to the system, and it was used to test products coming out of final assembly.
The very first thing that happened was the operator taking the stapled-together stack of detailed instructions I gave them, dropping it on the work bench, and using it as a mouse pad to start aimlessly clicking around.
I've actually worked with a genuine UX/UI designer (not a mere Graphics Designer but their version of a Senior Developer-Designer/Technical-Architect).
Lets just say most developers aren't at all good at user interface design.
I would even go as far as saying most Graphics Designers aren't all that good at user interface design.
Certain that explains a lot the shit user interface design out there, same as the "quality" of most common Frameworks and Libraries out there (such as from the likes of Google) can be explained by them not actually having people with real world Technical Architect level or even Senior Designer-Developer experience overseeing the design of Frameworks and Libraries for 3rd party use.
Yes you should. I think most comments here are about products that have millions of users where it's actually worthwhile spending all that extra time and money to perfect things.
For most development, it isn't worthwhile and the best approach is to wing it, then return later to iterate, if need be.
The same goes for most craftsmanship, carpentry in particular. A great carpenter knows that no-one will see the details inside the walls or what's up on the attic. Only spend the extra time where it actually matters.
It triggers me immensely when people say "I could have made a better job than that" about construction work. Sure maybe with twice the budget and thrice the time.
Exactly. I'd also like to add, look at Google stuff their ui / ux is routinely horseshit. So don't tell me there are ui/ux gurus out there GIGAchading user interfaces.
A lot of this shit is trial and error and even then they still fuck it up.
Make it accessible, make it legible and then fine tune it after.
Many Designers are not good at knowing what their users need, because they don't have the resources, background or education to understand user behaviour.
Programmer Humor
Hot
This magazine is not receiving updates (last activity 52 day(s) ago).