I worry about youHa! Y'all are 100% right. I haven't had my coffee yet and my brain substituted "print" where "return" was written.
I need my coffee now.
Regardless, I prefer the readability of B
The real crime here is not putting opening braces on a new line.
Code:function doThing() { if (condition) { return 1; } return 2; }
The trivial example in the OP doesn't represent anything real or reasons why people would actually use A. There are many cases where you want to return early and then the rest of the (much longer) function body continues. Having that at an additional scope/nesting level just because you had an early return doesn't make it more readable.
Newbies out of school will love the elegance of shorter code. People who have worked a few years will appreciate the explicitness of longer form code.
fun x() = if (condition) 1 else 2
Technical debt is a hell of a thing. In smaller teams you may or may not be working on code that is years old or the key owner is no longer around.Do people really care about stuff like this that much? Maybe it's different working with a larger team. I've worked with a small team the past 5 years and I can't tell you how many times we've gotten high GPA fresh college grads who fret over things like this but can't actually do the complex tasks we need help with.
On the other side, our two best hires have been non-CS majors who don't really know syntax but could brainstorm solutions all day.
Is the concern here that when you have enough people working on a set of code it just gets messy if people don't conform to the same coding style?
Thinking on it, this is fair, I just find I get reading B. If else often expands. I feel like if there's more than two conditions - sometimes it's unavoidable- refactor more, unless it's impossible.When I'm coding, I do A.
When others are coding, I hope they do B.
B is better, always be explicit and make no assumptions when it comes to future readability. The seconds you save typing out A instead of B might cause someone unnecessary confusion later down the road.
Yeah, early returns.
Technical debt is a hell of a thing. In smaller teams you may or may not be working on code that is years old or the key owner is no longer around.
Standards do matter but in this case none of the options are hard to read or more difficult to parse, unless you're a developer of low ability to begin with.
Unfortunately, strict coding standards can also have the side effect of reducing ones output, efficiency or reliability.
Coding and solutions architecture are two separate things, people who possess the ability to do both are a lot more rare than one would expect.
in my job if I wrote B, I would be asked to refactor it to A for sure
If your syntax allowed it, it's essentially the exact same as option 1 but then I'd question why you didn't do
Code:function doThing() { if (condition) return 1; else return 2; }
or even
Code:function doThing() { return condition ? 1 : 2; }
There it is.
Time efficiency is especially difficult with smaller teams. I've worked on large teams or teams with 5 devs that had comparable feature sets to products with 200 or more devs, the code quality, tooling and testing was nowhere near that level though.Okay gotcha. This example might just be too simple then. I've worked with so many people who are really focused on things like what's in the OP that I couldn't read the tone of this thread haha. Not sure if people were trying to say little diffences like the example really mattered or if it was more light hearted. In the example in the OP I figured your coworkers should understand either method and if it was truly confusing for some reason you should add comments.
Yeah finding the right balance between standards and time efficiency has been a constant battle at my job.
If we stick with the answers, A all day. B is just noise. It's harder to read.
Otherwise, ternary.
*Arguably* being a strong keyword there.The first one is especially bad, but both incur in arguably bad practices. If at all possible, you shouldn't use return except as the very last line in a function. The reason for this is that return, like break or goto, bypasses normal execution flow and makes code paths harder to follow.
Yeah I think anyone who really strongly cares about small things like this hasn't really programmed enough with different people. Things like this are something that you generally get used to very quickly depending on the team's coding practices.Do people really care about stuff like this that much? Maybe it's different working with a larger team. I've worked with a small team the past 5 years and I can't tell you how many times we've gotten high GPA fresh college grads who fret over things like this but can't actually do the complex tasks we need help with.
On the other side, our two best hires have been non-CS majors who don't really know syntax but could brainstorm solutions all day.
Is the concern here that when you have enough people working on a set of code it just gets messy if people don't conform to the same coding style?
I think the actual poll question vs the example used might actually make the results a bit untrustworthy - someone actually liking the A option might end up voting B because they agree with the wording of the option in the poll even if in this specific case would think the A option is more readable or that the A case might even be more explicit in their opinion.I do find it interesting this is apparently "settled" by linting but the majority seems to prefer the latter. Not that majority has much influence on what's "correct" but in a case like this where it's mostly about readability maybe that says something.
It's tiring to argue about this stuff but at least I can sleep content knowing I'm in the majority lol.
I think the actual poll question vs the example used might actually make the results a bit untrustworthy - someone actually liking the A option might end up voting B because they agree with the wording of the option in the poll even if in this specific case would think the A option is more readable or that the A case might even be more explicit in their opinion.
But dunno.
DataStructures.Numbers.IntegerContainer doThing() {
DataStructures.Numbers.IntegerContainer returnObject = ObjectFactoryFactory.getInstance()->getNumberContainerFactory()->getInstance(DataTypes.NumberTypes.TypeInteger)->getNewContainer();
if ( EqualityCheckFactory.getInstance()->isEqual( Booleans.Value_True, condition ) ) {
returnObject->setValue( Integers.Value_1 );
} else {
returnObject->setValue( Integers.Value_2 );
}
return returnObject;
}
To be fair, your disclaimer is well after the code. Usually a post would be the question then the examples, yours is the code then the question. The question isn't required to be read based on the examples and poll options.Considering people can't even read my edited in disclaimer that ternary isn't a "valid" answer here, yeah, it's probably not a very clean poll, but I can't be bothered with catering to the majority of Era users who don't read OPs lol.
Oh no...doThing enterprise edition:
Code:DataStructures.Numbers.IntegerContainer doThing() { DataStructures.Numbers.IntegerContainer returnObject = ObjectFactoryFactory.getInstance()->getNumberContainerFactory()->getInstance(DataTypes.NumberTypes.TypeInteger)->getNewContainer(); if ( EqualityCheckFactory->getInstance()->isEqual( Booleans.Value_True, condition ) ) { returnObject->setValue( Integers.Value_1 ); } else { returnObject->setValue( Integers.Value_2 ); } return returnObject; }
The trivial example in the OP doesn't represent anything real or reasons why people would actually use A. There are many cases where you want to return early and then the rest of the (much longer) function body continues. Having that at an additional scope/nesting level just because you had an early return doesn't make it more readable.
Yeah, funny how what you're familiar with is easier to read! Who would have thought.It's funny people are so certain of objective "harder to read" when the poll seems to indicate majority of people would prefer the opposite for what I can only imagine is that reason 🤔
Yeah but for what it's worth, it's still an interesting thread and interesting results. There are never enough programming threads here.Considering people can't even read my edited in disclaimer that ternary isn't a "valid" answer here, yeah, it's probably not a very clean poll, but I can't be bothered with catering to the majority of Era users who don't read OPs lol.