-
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 for myself or ternary op if simpler to write, B if I'm handing it of to someone else, but I'll follow whatever code style the commit process says to do, doesn't really bother me.
I always prefer explicit over implicit. Yes, A isn't hard to understand, but B makes the intention clear at a glance in all circumstances.
And for the record, I'm fine with the ternary operator in quick and dirty code, but I wouldn't dare use it in code that actually mattered.
And for the record, I'm fine with the ternary operator in quick and dirty code, but I wouldn't dare use it in code that actually mattered.
B - let's be clear about what's happening
yeah, looks ugly OP come on
yeah, looks ugly OP come on
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.
Explicit is always better. It's important that code can be easily understood afterwards too (and by people other than you, too).
Although the example in the OP isn't very good. One of those insane JS oneliners vs 10 lines of code would be a better example, I think.
Although the example in the OP isn't very good. One of those insane JS oneliners vs 10 lines of code would be a better example, I think.
Having a "no early return" rule is usually a symptom of a team's imperative style where functions/methods can be extremely long to digest or hard to grok. It makes sense in that case.
I prefer FP style (immutable FP style even) and breaking behavior into small functions. Then early returns, commonly for guard clauses, are much better because it allows for more expressiveness inside your short/specific functions.
I prefer FP style (immutable FP style even) and breaking behavior into small functions. Then early returns, commonly for guard clauses, are much better because it allows for more expressiveness inside your short/specific functions.
Well, I came across an example that looked pretty much as simple as A just the other day which is why it came to mind that way 🤔 but yeah, as some people highlighted context can make certain approaches more readable even if the same functionally.
When you browse leetcode solutions it's like the biggest chest bumping of who can write the smallest code possible.
After working in a massive code library of abstracted code in more abstracted code I'd much prefer verbosity over less lines (within reason obviously)
B, it accomplishes exactly what you set out to make it do. I prefer to make my code crystal clear when I can.
Depends on language and details obviously.
For a simple statement ternary if supporter. Otherwise, A for an early return (ie the main function logic at the end).
But in Kotlin for example, it would be:
Since the if statement is an expression and the ternary operator does not exist.
For a simple statement ternary if supporter. Otherwise, A for an early return (ie the main function logic at the end).
But in Kotlin for example, it would be:
Code:
fun x() = if (condition) 1 else 2Since the if statement is an expression and the ternary operator does not exist.
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?
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?
Two thoughts:
1) This is what teams/companies have coding guidelines for. Individual preferences need not apply at work (unless they happen to agree with guidelines).
2) About 95% of discussions of this type shouldn't even exist today as the debate is around entirely decorative/style concepts. But we still have them because programming world never moved on from 'code as text' paradigm.
1) This is what teams/companies have coding guidelines for. Individual preferences need not apply at work (unless they happen to agree with guidelines).
2) About 95% of discussions of this type shouldn't even exist today as the debate is around entirely decorative/style concepts. But we still have them because programming world never moved on from 'code as text' paradigm.
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.
Well it took them two weeks to even start onboarding me at all, so...yeah. Trainwreck.
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.
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.
If we stick with the answers, A all day. B is just noise. It's harder to read.
Otherwise, ternary.
Otherwise, ternary.
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.
Yeah, early returns.
whoever said ultimately this is a standards question is right though. Whatever the team decided, do that for this thing.
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.
This. Though our linter would had already forced me to change B to A.
this is the code I would expect and write myself but all depends on the context and if the language allows if
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.
As teams scale, feature output doesn't necessarily increase it just means code quality, unit and e2e testing, qa, code review and tooling are all much better.
Ultimately, coding standards save you time and money in the future, it's just a matter of whether that burden is worth it and aligned with business goals.
A, not for minimalization, but because in this case "2" is the default value and you want to make it clear that it is such.
I work in a codebase that tends to have a complex and volatile state, and most functions need to be ready to gracefully and silently "fail" if the state has changed by the time they're invoked. As such, I actually find A to be more clear to me, since it makes it apparent that "2" is meant to be a special default fallback value (would typically be "0" in a real scenario of course), and it makes it easier for people to make future changes to the function while still maintaining that single default return.
I work in a codebase that tends to have a complex and volatile state, and most functions need to be ready to gracefully and silently "fail" if the state has changed by the time they're invoked. As such, I actually find A to be more clear to me, since it makes it apparent that "2" is meant to be a special default fallback value (would typically be "0" in a real scenario of course), and it makes it easier for people to make future changes to the function while still maintaining that single default return.
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 🤔
*Arguably* being a strong keyword there.
In general, I don't think most people would agree with you that having returns other than in the last line makes code paths harder to follow. Personally especially returns makes it easier for me to follow - when you see a return statement, you immediately know that the path ends there. Breaks I don't really like anyway since nowadays I mostly use JavaScript and functional loops are generally more preferable to imperative loops.
Also the entire philosophy of functional programming (which is very trendy at the moment) kind of goes against your idea. Immutability is a huge part of functional programming and your example after the ternary breaks that idea. The thinking goes that once you present a variable to be modified like that, you now have to track its changes across the whole method (or potentially multiple methods if you pass it as a reference parameter) which makes it harder to read.
Obviously that's not an objective truth either though.
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.
However, even though OP's case is very close to a lot of real life cases, it's still very simplified and in a larger project, there would be a lot of similar but more complex cases.
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.
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.
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;
}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.
This is definitely true. There have been scenarios where I want to stop execution and return an error to the client, and in such a case it makes total sense to have more than one return to me.
Yeah, funny how what you're familiar with is easier to read! Who would have thought.
Hence why this is just a question for standards and that's about it.
Early returns all day IMO.
BBBBBBBBBBBBB FOR FUCKS SAKE B
(assuming no ternary or you don't want to return earlier yadda yadda)
I'm that asshole who spends half the meeting scolding vague variable names and attempts to save 5 characters by doing things like example A. People just hate the idea that your code is never done, it needs to be as maintainable as possible.
(assuming no ternary or you don't want to return earlier yadda yadda)
I'm that asshole who spends half the meeting scolding vague variable names and attempts to save 5 characters by doing things like example A. People just hate the idea that your code is never done, it needs to be as maintainable as possible.
Yeah but for what it's worth, it's still an interesting thread and interesting results. There are never enough programming threads here.
