-
Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
-
We have made minor adjustments to how the search bar works on ResetEra. You can read about the changes here.
Programmers
- Thread starter Stopdoor
- Start date
A is more readable for me and how I do it usually too.
When I look at an If, I first look at the result of the block. If that block terminates with a return then I do not care what comes after. If it does not, then I add else.
When I look at an If, I first look at the result of the block. If that block terminates with a return then I do not care what comes after. If it does not, then I add else.
Kind of depends on what the function is actually doing, and how much more there is to the code than the simple example, but I'd generally do A. I'm all for being more verbose when it's actually meaningful, but I'd argue B is not inherently more readable in general, and that if the logical branches are not of equivalent "weight"—e.g. guard clause for rarer condition vs. main "happy path" logic—A is better to get the early return checks out of the way and then eliminate the extra conditional block scope for the main logic. In real code, I think excessive conditional block nesting tends to be a bigger readability problem.
(Of course, if the function is actually as few lines as the example, I'd just use a ternary instead.)
The real real crime is not just doing whatever is most conventional for your project or language and moving on to things that actually matter. :)
(Of course, if the function is actually as few lines as the example, I'd just use a ternary instead.)
The real real crime is not just doing whatever is most conventional for your project or language and moving on to things that actually matter. :)
Last edited:
B
I look at A and I feel like the return 2 SHOULD happen. I know that's not the case but that's how my brain automatically interprets anything that comes after an if statement.
B looks more like a binary choice.
I look at A and I feel like the return 2 SHOULD happen. I know that's not the case but that's how my brain automatically interprets anything that comes after an if statement.
B looks more like a binary choice.
A is preferred by clang-tidy and as such is all you'll see in our codebase. We can't merge code that conforms to B.
edit: it originates as an LLVM coding guideline
i feel way more comfortable doing it the second way because basically, i dont program a ton and i still have a pretty rigid style derived from using java in college courses, so i think i tend to do things in like a textbook style
An if-else statement where both branches provides a return value, satisfies at least the recent C++ compilers I've used recently.
I'm an A guy.
But a ternary-like thing would be another option
But a ternary-like thing would be another option
Code:
function doThing() {
return (condition ? x = 1 : 2);
}
Bit of a sidetrack, but in C#, wouldn't case B fail because there's no default Return? Like, I'd have to do this if I wanted to add the explicit else case becuse without the second Return False, it wouldn't compile:
Otherwise, I'd be forced to use A, right? I realise B is clearer to human readability.
Edit: Might this be a compiler quirk if it wouldn't otherwise do this for others?
C#:
bool MyFunc()
{
if (situation)
{
return true;
}
else
{
return false;
}
return false;
}Otherwise, I'd be forced to use A, right? I realise B is clearer to human readability.
Edit: Might this be a compiler quirk if it wouldn't otherwise do this for others?
I prefer B, but then I don't really do OOP, I program microcontrollers mostly in C. But this is a discussion where you won't reach a consensus.
Would vary a lot by the context. Meaning how much is happening in that "return 1" vs "return 2" - if one was more complex Id do A. Also depends what type of data.
Depends on language. Go uses same line opening bracket and it's not optional.
Depends on language. Go uses same line opening bracket and it's not optional.
Yeah, okay, just a weird compiler issue in my case then, I guess? Just wondered as this thread brought that specific quirk to mind.
The argument B is more readable is weird. It's good to explicit and verbose at times, but that hardly matters in this case. Also as pointed out, most linters by default would accept B as the correct solution.
Both are as readable but one has extra clutter in it (but a negligible amount).
Both are as readable but one has extra clutter in it (but a negligible amount).
Which language are you thinking? Because at least in JS that would be overly complex (simply condition ? 1 : 2 would work) and as a side effect, you'd have a global variable x.
Whatever my tech lead says, they're ultimately the owner of code quality at my job.
But I prefer B due to readability; much easier to 'skim'.
But I prefer B due to readability; much easier to 'skim'.
Yeah, because really, it should flag your final return as being unreachable.
In general, I'd take B any day.
In this case it's not a big deal as both are fairly simple to understand, but in general I prefer as much explicit code as possible, even if that bulks up the line count as it's much easier for handover purposes and digestibility.
In this case it's not a big deal as both are fairly simple to understand, but in general I prefer as much explicit code as possible, even if that bulks up the line count as it's much easier for handover purposes and digestibility.
This basically
I prefer there to be as few ways "out" of a function as possible, so would probably use a ternary, or make a boolean variable and assign the value using the if statement and then return the variable at the end
Basically it depends on how complicated the logic in the function is, for one as simple as the examples it doesn't matter a whole deal
if there are only two allowed returns you can also just set one as a default.
Code:
var = 1;
function doThing() {
if (condition) var = 2;
}Or if you have functions that need multiple paramaters you might want to guard against undefined paramaters (so you can use a terniary to just default them if you want).
- readability is much more important than shorter code
- minifiers (js) or compilers care for the build/deployed version
- code style should always be checked automatically
and if it's Javascript, the answer would be
JavaScript:
const doThing = () => condition ? 1 : 2;
So in your example, I'd argue it's a wash, go for legibility (i.e. B). Where I might differ is the point at which you have multiple paths to return the same(ish) thing (for example multiple ways of validating an input prior to processing it leading to multiple error codes).
So for example:
I'd argue in this instance we've started to obfuscate where the major processing will be performed.
I've seen alot of code that nests the processing within an unseemly number of if statements where a flatter structure and multiple return points would be more readable (assuming your language allows this that is). But of course ultimately, alot of this is down to what you'll find legible. Assuming you're running through some sort of intelligent compiler/interpreter, it'll normally produce similar executable code anyway.
So for example:
Code:
function doThing(input) {
if input != NULL {
return ERROR1;
}
else if (valid(input)) {
return ERROR2;
}
else if (someGlobalState == READY) {
return ERROR3;
}
else {
// do thing to input
return result;
}
}I'd argue in this instance we've started to obfuscate where the major processing will be performed.
Code:
function doThing(input) {
if input != NULL {
return ERROR1;
}
if (valid(input)) {
return ERROR2;
}
if (someGlobalState == READY) {
return ERROR3;
}
// do thing to input
return result;
}I've seen alot of code that nests the processing within an unseemly number of if statements where a flatter structure and multiple return points would be more readable (assuming your language allows this that is). But of course ultimately, alot of this is down to what you'll find legible. Assuming you're running through some sort of intelligent compiler/interpreter, it'll normally produce similar executable code anyway.
Once compiled is there even a difference? I prefer readability. My pattern might be more like...
var defaultVal = theDefault;
if (condition) {
defaultVal = newDefault;
}
return defaultVal;
Nice
var defaultVal = theDefault;
if (condition) {
defaultVal = newDefault;
}
return defaultVal;
Nice
Honestly no one will ever need to be fast enough that they can't take their time reading the code in a slightly slower way. The only real benefit here is having linters to maintain consistency across a team. At that point you can justify going ham on every single choice, but unless you're doing that... it's useless and a waste of time to consider legibility to this level of scrutiny.
Obviously the context would matter, but I'd argue the former is more readable, primarily because it's making it explicit that each of the conditions are intended to be mutually exclusive, whereas simply using a number of if statements may not necessarily mean they would all be exclusive.
I voted A assuming that's the only thing the function does.
In reality though I doubt it would be, and if I wrote a function it would only have one return statement.
In reality though I doubt it would be, and if I wrote a function it would only have one return statement.
This is the one. A lead of mine once told me they preferred functions with a single entry and exit point (i.e., only one return statement), and that's become completely ingrained in my coding style ever since.
That's generally worse than either A or B because you've introduced mutable state, and now you have to track its transitions to read the function instead of just follow the control flow.
I think you're often going to produce more convoluted code in trying to hold to the "single return" than you would otherwise. That rule makes more sense in languages with e.g. explicit memory allocation, where you also have to ensure you free resources before you return—so it was less about the pure readability of the single return, than about making it easier to be correct in that regard. Less so in garbage-collected languages where you rarely have to worry about that kind of thing.
Last edited:
I think either are fine.
As long as there isn't any compiler goofiness where it can somehow return two things.
As long as there isn't any compiler goofiness where it can somehow return two things.
Those are functionally two very different code blocks even if the output is the same in this scenario. The first one actually obfuscates the logic more because the blocks are all connected in a single logical chain. Only one of those statements will ever be executed. In the second block, you're guaranteed that each check will occur sequentially and in order if for some reason one of the statements was not actually a return statement. Or if multiple of the logic branches were true (like A < 2, followed by A < 3).
If you were to reduce a set of if statements into an if-else statement, the odds are fairly likely you'd bring in a bug or two.
I prefer readability over simplicity. In the OP we can all clearly see what's going on but I am sure we have all come across code where the return might be another function call (which in turn returns something else). Having an explicit 'else return null' would probably make life easier for the next sucker to come along and try and figure out what's going on.
I'd argue readbility is not if something is explicit or implicit but if the flow of the program can be reasoned about by the reader.
lol
Resharper will whine In visual studio if you write it as b, even though it's my preference.
My preference is using a ternary there as long as the if statement isn't super long. I've seen linters not accept B.
I always follow existing style/formatting when working on someone else's code/project. You can't make me like it though :)
In general I highly prefer readability and verbosity.
But I don't feel like A is less readable than B in this particular instance, so I would probably write it like A.
But I don't feel like A is less readable than B in this particular instance, so I would probably write it like A.