I don’t know enough Rust to understand by what you mean by the last one. My understanding was that mod name was just declaring the module that this file depends on. Could you explain what I should do instead? Since your other statements I totally agree with, I should probably agree with the last one.
mod name declares that the module should be compiled and reachable as a submodule of the current module. This assumes that you have a file or directory of the name in the right place. This is what you should do.
You can also declare a module like this: mod name {...} where you just put the content in the block. The two are functionally equivalent, from the compilers perspective.
This point advocates against the use of mod with content in a file unless it is used for a testing module. A common pattern is to have the unit tests for a module inside the main module file. Tests in rust are just specially tagged functions. To avoid compilation costs in non-test builds and false unused code warnings you can put all test related code in a submodule and tag that module with #[cfg(test)]. That way the module will only be included and compiled if the crate is being compiled to run tests.
The Star wars thing refers to scrolling long text files similar to the intro of the starwars movies where a long text is scrolled for the viewer.
Oh so its just referring to writing the mod’s code in the same file the mod is declared in being bad form? That seems very reasonable; since the point of a module is code separation so it makes sense to always put it in its own file. Good, I’m already doing that at least!
Why have an async block spanning the whole function when you can mark the function as async? That’s 1 less level of indentation. Also, this quite is unusable for rust. A single match statement inside a function inside an impl is already 4 levels of indentation.
A single match statement inside a function inside an impl is already 4 levels of indentation.
How about this?
The preferred way to ease multiple indentation levels in a switch statement is to align the switch and its subordinate case labels in the same column instead of double-indenting the case labels. E.g.:
switch (suffix) {
case 'G':
case 'g':
mem <<= 30;
break;
case 'M':
case 'm':
mem <<= 20;
break;
case 'K':
case 'k':
mem <<= 10;
/* fall through */
default:
break;
}
I had some luck applying this to match statements. My example:
let x = 5;
match x {
5 => foo(),
3 => bar(),
1 => match baz(x) {
Ok(_) => foo2(),
Err(e) => match maybe(e) {
Ok(_) => bar2(),
_ => panic!(),
}
}
_ => panic!(),
}
Is this acceptable, at least compared to the original switch statement idea?
I mean, I use formatters everywhere I can exactly so I don’t have to think about code style. I’ll take a full code base that’s consistent in a style I dislike, over having another subjective debate about which style is prettier or easier to read, any day. So whatever cargo fmt spits out is exactly what I’ll prefer, regardless of what it looks like, if only for mere consistency.
i personally find this a lot less readable than the switch example. the case keywords at the start of the line quickly signify its meaning, unlike with => after the pattern. though i dont speak for everybody.
the problem is that, while skimming the start of each lines, nothing about 'G' | 'g' tells me that its a branch. i need to spend more time parsing it. mind you, this may simply be a problem with rust’s syntax, not just ur formatting.
Well, of course you can have few indent levels by just not indenting, I don’t think the readability loss is worth it though. If I had give up some indentation, I’d probably not indent the impl {} blocks.
I just got some idea yesterday regarding impl blocks, ready to be my respondent?
I had a big impl block with 4 levels of indentation, so I cut the block, and replaced
impl InputList {
//snip
}
with mod impl_inputlist; and moved the impl block to a new file, and did not indent anything inside that block.
The advantage this has over just not indenting the impl block in place, is that people will have difficulty distinguishing between what’s in the block and what’s outside, and that’s why the impl was moved to its own exclusive file, impl_inputlist.rs
Maybe I am overstressing indentation. Ss there something wrong with my setup that prevents me from accepting 4-space indentation?
I’ve heard similar from the worst first year CS students you could ever meet. People talk out their ass without the experience to back up their observations constantly. The indentation thing is a reasonable heuristic that states you are adding too much complexity at specific points in your code that suggests you should isolate core pieces of logic into discrete functions. And while that’s broadly reasonable, this often has the downside of you producing code that has a lot of very small, very specific functions that are only ever invoked by other very small, very specific functions. It doesn’t make your code easier to read or understand and it arguably leads to scenarios in which your code becomes very disorganized and needlessly opaque purely because you didn’t want additional indentation in order to meet some kind of arbitrary formatting guideline you set for yourself. This is something that happens in any language but some languages are more susceptible to it than others. PEP8’s line length limit is treated like biblical edict by your more insufferable python developers.
IDK, but if the reason is “to break stuff into multiple functions”, then I’m not necessarily writing yet another single-use function just to avoid writing a comment, especially in time critical applications. Did that with a text parser that could get text formatting from a specifically written XML file, but mainly due to it being way less time critical, and had a lot of reused code via templates.
Indentation implies there’s some control structure causing it. Too many control structures nested gets hard to mentally keep track of. 3 is arbitrary, but in general more indentation => harder to understand, which is bad.
Honestly I don’t mind the indentation since C isn’t going to give us many ways to address this with as little code.
That said, with compilers that are good at inlining trivial functions, I really do appreciate the “it does what it says on the tin” approach to using functions on things like this. Even if they’re only used once. Comments would help too.
The logic in these if statements is inscrutable on a cold read like this. To me, that’s a maintenance risk; imagine seeing a snippet this size on a PR. Having functions that name what the hell is going on could only help.
Like with everything, context matters. Sometimes it can indicate poorly structured control flow, other times inefficient loop nesting. But many times it is just somebody’s preference for guard clauses. As long as the intent is clear, there are no efficiency problems, and it is possible to reach the fewest branches necessary, I see no issues.
It’s important to remember that Linus is primarily writing about C code formatting. C doesn’t have things that tend to create more deeply nested structures, such as a formal class syntax, or nested functions.
Going too deep is still bad–as zea notes, it’s an indication of control structures run amok–but the exact number is dependent on the language and the context.
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.)
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.
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.
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.
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.
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.
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
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 ‘!’.
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.
In theory, not a terrible idea, but then you get this kind of hate crime:
Obviously, might just be me again, but not having these letters align, just looks so much worse to me.
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.
This posts entire comment chain is an interesting example of people that have extensive knowledge in completely different areas of programming to me. And have some concepts I had never heard/thought of.
You get one level at the get go because everything is in a function. So just two levels of indentation? A pretty basic if… for…if nesting has to be refactored? Into what? Goto? Should I sprinkle return statements all over the place?
Y’all gotta understand that Linus is often kind of an ass.
And I have a fucking conniption because just move that shit into a variable before the return. I get it when sometimes you just need to resolve something inline, but a huge amount of the time that ternary can be extracted to a variable before the ternary, or just rewrite the function to take multiple types and resolve it in the function.
In my codebase? I’d pull a “let’s linger after standup about your PR” and have the coder sweat through a 10 minute soapbox about nothing before laying down the law.
Yeah, the annoying thing is the people who I generally have found to be the worst about stuff like this are old school Senior C developers, who still program like it’s 1987 and we have to fit everything into 4K of RAM.
Fortunately there’s nothing like that in my code base, I just run into stuff like that periodically when I’m digging around in other team’s server code looking for something.
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.
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
While I totally agree with that philosophy, it heavily depends on the language.
For Rust, my philosophy is more like this:
I don’t know enough Rust to understand by what you mean by the last one. My understanding was that
mod namewas just declaring the module that this file depends on. Could you explain what I should do instead? Since your other statements I totally agree with, I should probably agree with the last one.mod namedeclares that the module should be compiled and reachable as a submodule of the current module. This assumes that you have a file or directory of the name in the right place. This is what you should do.You can also declare a module like this:
mod name {...}where you just put the content in the block. The two are functionally equivalent, from the compilers perspective.I don’t understand how to follow this bullet point that I was replying to.
I already know what mod does in a basic sense, I wanted to know what the commenter meant by this.
This point advocates against the use of mod with content in a file unless it is used for a testing module. A common pattern is to have the unit tests for a module inside the main module file. Tests in rust are just specially tagged functions. To avoid compilation costs in non-test builds and false unused code warnings you can put all test related code in a submodule and tag that module with
#[cfg(test)]. That way the module will only be included and compiled if the crate is being compiled to run tests.The Star wars thing refers to scrolling long text files similar to the intro of the starwars movies where a long text is scrolled for the viewer.
Oh so its just referring to writing the mod’s code in the same file the mod is declared in being bad form? That seems very reasonable; since the point of a module is code separation so it makes sense to always put it in its own file. Good, I’m already doing that at least!
Why have an async block spanning the whole function when you can mark the function as async? That’s 1 less level of indentation. Also, this quite is unusable for rust. A single match statement inside a function inside an impl is already 4 levels of indentation.
Those async blocks exist when doing async in traits.
And I never said I respected the 4 level of indentations. That’s exactly the point of those rules. Keep it lowly indented but still readable
How about this?
I had some luck applying this to
matchstatements. My example:Is this acceptable, at least compared to the original
switchstatement idea?It’s a lot less readable imo. As well than a
cargo fmtlater and it’s gone (unless there’s a nightly setting for it)Formatters are off-topic for this, styles come first, formatters are developed later.
My other reply:
I mean, I use formatters everywhere I can exactly so I don’t have to think about code style. I’ll take a full code base that’s consistent in a style I dislike, over having another subjective debate about which style is prettier or easier to read, any day. So whatever
cargo fmtspits out is exactly what I’ll prefer, regardless of what it looks like, if only for mere consistency.i personally find this a lot less readable than the
switchexample. thecasekeywords at the start of the line quickly signify its meaning, unlike with=>after the pattern. though i dont speak for everybody.How about this one? it more closely mirrors the switch example:
How about this other one? it goes as far as cloning the switch example’s indentation:
the problem is that, while skimming the start of each lines, nothing about
'G' | 'g'tells me that its a branch. i need to spend more time parsing it. mind you, this may simply be a problem with rust’s syntax, not just ur formatting.Well, of course you can have few indent levels by just not indenting, I don’t think the readability loss is worth it though. If I had give up some indentation, I’d probably not indent the impl {} blocks.
I just got some idea yesterday regarding
implblocks, ready to be my respondent?I had a big
implblock with 4 levels of indentation, so I cut the block, and replacedwith
mod impl_inputlist;and moved theimplblock to a new file, and did not indent anything inside that block.The advantage this has over just not indenting the
implblock in place, is that people will have difficulty distinguishing between what’s in the block and what’s outside, and that’s why theimplwas moved to its own exclusive file, impl_inputlist.rsMaybe I am overstressing indentation. Ss there something wrong with my setup that prevents me from accepting 4-space indentation?
I use:
Editor: Neovide
Font: “FiraCode Nerd Font Mono:h16” (16px fonts are addicintg)
Monitor: 1366x768, 18.5 inch, 10+ years old, frankenstein-ly repaired Samsung monitor.
Distance: I sit at about 40-60 Cm from my monitor.
That leaves me with a 32x99 view of code excluding line numbers and such.
what if I need to nest
if letsUse a
match? Unless it’s for guard clauses, a match is fine enoughwhat if i need to
if leton the result of anotherif letOh, then you use
and_then()or something similar.There’s also the possibility to use the guard clauses patern and do
let <...> = <...> else {}.And finally, you can always split into another function.
It’s not straight rules. It depends on what makes it more readable for your case.
what about
ifon a boolean followed by anif letI’ma gonna steal this.
Sadly, that’s not code Linus wrote. Nor one he merged. (It’s from git, copied from rsync, committed by Junio)
Plus it shows three levels of indentation. Well… there is the extra one created by the compiler directives, but do they really count?
You really think someone would do that? Just go on the internet and tell lies?
here you go, linux 0.01
line 152 is the only thing past 3 levels and I’d say that one gets a pass.
Isn’t that from 1991 while the quote is from 1995? If we’re nitpicking maybe we shouldn’t time travel 🤓
Damn it Time Patrol! You can’t stop me!
I mean it was 0.01, at that point he was screwed anyway, and he fixed his program.
He wouldn’t make that statement unless he experienced the horror himself.
Now, if he still does it these days…
I’ve heard similar from the worst first year CS students you could ever meet. People talk out their ass without the experience to back up their observations constantly. The indentation thing is a reasonable heuristic that states you are adding too much complexity at specific points in your code that suggests you should isolate core pieces of logic into discrete functions. And while that’s broadly reasonable, this often has the downside of you producing code that has a lot of very small, very specific functions that are only ever invoked by other very small, very specific functions. It doesn’t make your code easier to read or understand and it arguably leads to scenarios in which your code becomes very disorganized and needlessly opaque purely because you didn’t want additional indentation in order to meet some kind of arbitrary formatting guideline you set for yourself. This is something that happens in any language but some languages are more susceptible to it than others. PEP8’s line length limit is treated like biblical edict by your more insufferable python developers.
He barely ever code these days.
Why is multiple levels of indentation bad?
IDK, but if the reason is “to break stuff into multiple functions”, then I’m not necessarily writing yet another single-use function just to avoid writing a comment, especially in time critical applications. Did that with a text parser that could get text formatting from a specifically written XML file, but mainly due to it being way less time critical, and had a lot of reused code via templates.
Indentation implies there’s some control structure causing it. Too many control structures nested gets hard to mentally keep track of. 3 is arbitrary, but in general more indentation => harder to understand, which is bad.
Honestly I don’t mind the indentation since C isn’t going to give us many ways to address this with as little code.
That said, with compilers that are good at inlining trivial functions, I really do appreciate the “it does what it says on the tin” approach to using functions on things like this. Even if they’re only used once. Comments would help too.
The logic in these if statements is inscrutable on a cold read like this. To me, that’s a maintenance risk; imagine seeing a snippet this size on a PR. Having functions that name what the hell is going on could only help.
Like with everything, context matters. Sometimes it can indicate poorly structured control flow, other times inefficient loop nesting. But many times it is just somebody’s preference for guard clauses. As long as the intent is clear, there are no efficiency problems, and it is possible to reach the fewest branches necessary, I see no issues.
It’s important to remember that Linus is primarily writing about C code formatting. C doesn’t have things that tend to create more deeply nested structures, such as a formal class syntax, or nested functions.
Going too deep is still bad–as zea notes, it’s an indication of control structures run amok–but the exact number is dependent on the language and the context.
And you never include the switch-case-block indentation levels.
He obviously meant 13, because 3 is WTF 😭
I didn’t know why, but *++p bugs me
welcome to C
That
*++operator from C is indeed confusing.Reminds me of the goes-to operator:
-->that you can use as: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.
Where do you think we are?
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
Humoron the name, not here.)Well, I guess nobody expects.
deleted by creator
I thought it was just incrementing the address and dereferencing it, but I don’t write C or C++. What is being overloaded there?
It’s very likely plain old C
deleted by creator
Not if you’ve done a lot of pointer math
Perhaps *(p += 1) will be to your liking?
++pwill increase the value and return the new valuep++will increase the value and return the old valueI think
p = p + 1is the same asp++and not as++p. No?In C an assignment is an expression where the value is the new value of what was being assigned to.
In
a = b = 1, both a and b will be 1.is the same as
, so ++p.
What I meant was:
In the screenshot it said
x = *(++p)and iirc that is not the same as sayingx = *(p++)orx = *(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
++pand (p++orp+= 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
(p += 1) resolves to the value of p after the incrementation, as does ( p = p + 1).
Yes.
p++==p+= 1==p = p + 1are all the same if you use it in an assignment.++pis different if you use it in an assignment. If it’s in its own line it won’t make much difference.That’s the point I was trying to make.
No.
++p returns incremented p.
p += 1 returns incremented p.
p = p + 1 returns incremented p.
p++ returns p before it is incremented.
Right. So i had them the other way around. :D
Thanks for clarifying.
Much better… but can we make it
*((void*)(p = p + 1))?How about some JavaScript
p+=[]**[]?Why are you casting to
void*? How is the compiler supposed to know the size of the data you are dereferencing?This would probably cause a compiler error…
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.
Uses multiple returns… I’m switching to Windows.
deleted by creator
That was the joke. 😂 I bet Windows is worse.
What’s wrong with multiple returns?
Maintainability.
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:
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
ifandelse, 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.
deleted by creator
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?
as opposed to this?
Using a retval has the exact problem that you want to avoid: at the point where we do
return retval, we have no idea howretvalwas 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 whenreturn retvalis hit must now be examined to know whyretvalhas 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.
deferExample of option 1
Example of option 2
Example of option 3
Example of option 4
goto is used in C for this exact kind of early return management. The person you answered to does not maintain code I think
goto cleanup is not the same as return. I didn’t badmouth goto cleanup.
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:
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.
I hate it when some blame early returns for the lack of maintainability.
Early returns are a great practice when doing argument validation and some precondition checks. They also avoid nested blocks that worsen readability.
What’s being described there is a function that tries to do too much and should be broken down. That’s the problem, not early returns.
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.
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.
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.
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.
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.
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.
I meant assigning a return value then returning it is the sam as rnultiple returns. Anyway.
Right. Like I said.
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.
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 mean you are early-returning to windows, uh? You can’t do that by your own rules.
Fuck.
Ligatures 🤢🤮🤮
I mean, we read code more than we write it. You just vomitted over something that increases readability. Maybe a time for a rethink?
You’re brave (I don’t agree)
deleted by creator
What’s wrong with Ligatures? It makes reading code a bit more tolerable.
I mean, I certainly wouldn’t give someone else shit for using ligatures, but personally, I don’t like them, because:
The IDEs I’ve used had the ligatures be of the same character width as the original operator.
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
morw, to reach into the space of neighboring characters, if those neighboring characters are narrow, like ani.In theory, not a terrible idea, but then you get this kind of hate crime:
Obviously, might just be me again, but not having these letters align, just looks so much worse to me.
¹: It’s this font: https://monaspace.githubnext.com/
Do you also get surprised when you backspace a tab and suddenly it removes more whitespace than 1 characters worth?
Or did you learn it fast and really never think about it?
I think it’s more a “getting used to” thing, that once learned, you don’t think about, but it makes things more readable.
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≠.Studies show that ligatures improve readability, but I acknowledge that it’s likely untrue for outliers.
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.
I fucking hate that
Ifstyle.SCSS go brrrr
This posts entire comment chain is an interesting example of people that have extensive knowledge in completely different areas of programming to me. And have some concepts I had never heard/thought of.
Broad generalizations aren’t for the people who make them, they’re for the suckers who consistently fall for them
You get one level at the get go because everything is in a function. So just two levels of indentation? A pretty basic if… for…if nesting has to be refactored? Into what? Goto? Should I sprinkle return statements all over the place?
Y’all gotta understand that Linus is often kind of an ass.
Only the sith deal in absolutes
You must be a sith…
They might be a sith.
Ah shit…
Ah bowel movement…
It could be a fart brewing
Absolutely.
My personal code readability axe to grind is nested complex ternary operators.
Every now and then I’ll see something like this
return (checkFormatType(currentObject.type==TYPES.static||currentObject type==TYPES.dynamic?TYPES.mutable:TYPES.immutable)?create format("MUTABLE"):getFormat(currentObject));And I have a fucking conniption because just move that shit into a variable before the return. I get it when sometimes you just need to resolve something inline, but a huge amount of the time that ternary can be extracted to a variable before the ternary, or just rewrite the function to take multiple types and resolve it in the function.
no but bro, the code complexity tool says that this scope has 14 complexity instead of 13, we gotta cram it in a single ternary for code legibility
That example looks like the PowerShell equivalent of piping complex things around 20 times before actually doing something with the results.
In a one-liner competition, sure.
In my codebase? I’d pull a “let’s linger after standup about your PR” and have the coder sweat through a 10 minute soapbox about nothing before laying down the law.
Yeah, the annoying thing is the people who I generally have found to be the worst about stuff like this are old school Senior C developers, who still program like it’s 1987 and we have to fit everything into 4K of RAM.
Fortunately there’s nothing like that in my code base, I just run into stuff like that periodically when I’m digging around in other team’s server code looking for something.
The number one thing that gets in my way of refactoring to function is figuring out what to name the functions takes too long.
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.
deleted by creator
I had a similar thought
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.
🤷♂️ Or fnck it.
Sometimea the smallest logical unit of an algorithm uses more than 3 levels of indentation
rules aren’t there to be enforced, they’re there so that when you break them you take a second to think about why.