Programmers

[Roxas]

I'd take B all day long man, having to do code review I vastly prefer readable, correct code, specially if what you're doing is complex A could get kinda noisy to read. I get it if you're doing micro controllers and just want to save space, but otherwise, nope.

 

[SteveMeister]

A

function doThing() {
    if (condition) {
        return 1;
    }
    return 2;
}

B

function doThing() {
    if (condition) {
        return 1;
    } else {
        return 2;
    }
}

Seen a lot of the former practice at my workplace lately and tbh it's totally bothering me, I'd put human readability above most things. Are you all about saving characters? Is the former actually somehow "safer" in your opinion?

(Edit: I should've made the example more dirty to make using a ternary not the easy answer, but yeah, just assume that's not plausible here)

Click to shrink...

My personal preference is for open and close braces to be in the same column. If a line ends up being wider than your visible columns you won't see the trailing brace. Makes for more easily readable code as the code gets more complex. And if you're not using an IDE that highlights corresponding braces or has outlining features, you can position the cursor over the open or close brace & mousewheel up or down to see its counterpart.

My personal preference is to avoid multiple return statements, and instead have a result variable that gets set appropriately and returned at the end of the function. The only exception is an early out at the beginning of a function. Break is ok if it's available. But a function should have the minimal number of returns as possible. If you find yourself using more, rethink your function design, maybe make use of switch or break the function up into multiple functions.

My personal preference with simple conditions is to use a ternary. But if the conditions become complex or you end up with nested ternaries, it's better to break them up.

So I'd write this:

int doThing()
{
    return condition ? 1 : 2;
}

That said, I'm not a stickler for varying code styles, as long as they're readable and consistent.

 

[shnurgleton]

Everybody voting B is paid by LOC or is really afraid to deviate from textbook examples

Also I prefer a more functional style anyways. In current arrow-style Javascript I'd do

const doThing = () => condition ? 1 : 2;

Terser code with fewer LOC generally means fewer places for bugs

 

[Tony B]

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.

Click to shrink...

That's more laziness of my part. I was going to make it a bunch of nested if/else statements but didn't want to muddy the waters of the argument by presenting something too different to the original examples.

 

[Kelsdesu]

No need for the else. A.

 

[Z-Beat]

In this case I'd probably go with A since all you're doing are return statements but functionally there isn't much of a difference.

if it was doing something besides returns I'd go with B, obviously

 

[Composer]

A is the correct format is most situations. B has issues. The else is completely redundant in this situation. This is how we code at Google and you would be expected to make this clean up 99/100 times.

 

[TitanicFall]

I tend to add default values at the beginning.

function doThing() {
var thing = "default";

if (condition) {
thing = "nondefault";
}
return thing ;
}

 

[shnurgleton]

I present C.

function doThing() {
    var x = 2;
    if (condition) {
        x = 1;
    }
    return x;
}

Click to shrink...

I just vomited in my mouth

 

[iapetus]

Neither. If it's that short, ternary if. Otherwise I'll rearrange it so that there's only one return statement.

 

[Eblo]

B is better when working with others, but I do A in personal projects.

 

[GK86]

Between the two options, I almost always do A.

 

[EJS]

B is probably a better answer for transparency but I always implement A.

 

[EJS]

Neither. If it's that short, ternary if. Otherwise I'll rearrange it so that there's only one return statement.

Click to shrink...

This is the real answer.

 

[GringoJB]

I'd instinctually do it like B if I was writing it, but I really don't care either way... holy wars over this sort of thing drive me up the wall

 

[MatchaMouse]

Not a fan of the brackets in either but I choose B. I feel like most people I've met that are all about minimalism in their code end up being elitist types and won't admit that it's much less intuitive to read.

 

[Tony B]

I present C.

function doThing() {
    var x = 2;
    if (condition) {
        x = 1;
    }
    return x;
}

Click to shrink...

As someone who's had to work in environments which enforce single return statement rules (MISRA C for example), I do have a fair amount of code which follows this pattern.

 

[808s & Villainy]

Honestly? Depends on how many if statements there are
If there's just one, I'd go with A. If there are many, I'd opt for B, just be I think that looks nicer.
Extending it further, if multiple statements require curly braces, I'll apply that even to the ones that don't just for visual consistency

 

[ivantod]

I know that else is not needed here but I like to put it in anyway because it seems to me to be a bit clearer for the person who is reading the code at some later point. So my choice usually would be B, although for an example as simple as this I would just use the ?: operator in one line.

 

[EJS]

function doThing() {
    return condition ? 1 : 2;
}

This is honestly what I would do. Simplistic expressions like this is what ternary's were made for, in my opinion.

 

[MattEnth]

function doThing() {
    return condition ? 1 : 2;
}

This is honestly what I would do. Simplistic expressions like this is what ternary's were made for, in my opinion.

Click to shrink...

This is the correct answer.

 

[subrock]

Id do 1 but in Swift I'd use a guard instead of an if. Looks a lot cleaner than an if else

func foo() {
  guard condition else { return 2 }
  return 1
}

edit: ternary is also a good solution, but in that case I'd likely remove the function call altogether and just do it inline

 

[SunBroDave]

readability > brevity imo

The only time I would do A is for something like a continue or break

 

[EJS]

Id do 1 but in Swift I'd use a guard instead of an if. Looks a lot cleaner than an if else

func foo() {
  guard condition else { return 2 }
  return 1
}

edit: ternary is also a good solution, but in that case I'd likely remove the function call altogether and just do it inline

Click to shrink...

True, lol, I might just assign an integer in-line to the outcome of the expression - unless it really didn't go with the flow / purpose of the function, for some reason.

 

[Brandino]

Condition==true? return 1 : return 2

I may have my ? and : backwards

 

[Mills]

Mostly boils to style/preference absent established norms of the codebase. I prefer single return statement for many reasons but I have no issue with any of the suggestions IFF the function is very short and very unlikely to get more complex, in which case I expect even a novice can read any of these and know what's going on at a glance. Most important is to pick one and stay with it so others or yourself at a later date don't need to expend mental energy making sure it isn't different for a reason.

I tend to add default values at the beginning.

function doThing() {
var thing = "default";

if (condition) {
thing = "nondefault";
}
return thing ;
}

Click to shrink...

My man.

 

[EJS]

Condition==true? return 1 : return 2

I may have my ? and : backwards

Click to shrink...

It could be further simplified to:

return condition ? 1 : 2

I am being annoying now, my fault. I hate code snobs and I am being one :/

 

[ChrisR]

Id do 1 but in Swift I'd use a guard instead of an if. Looks a lot cleaner than an if else

func foo() {
  guard condition else { return 2 }
  return 1
}

Click to shrink...

Guard s seems pretty cool.

I'd probably go with A in production code, a base "fail state" with any conditional stuff above it. Tertiary is great if you 100% know whatever you are dealing with will be one value or another.

 

[KhandoleezzaRice]

It doesn't really make a difference to me, I do whatever standards have been laid out by the employer because if I don't it's going to get dinged in code review anyway.

 

[thesoapster]

It could be further simplified to:

return condition ? 1 : 2

I am being annoying now, my fault. I hate code snobs and I am being one :/

Click to shrink...

The last company I worked at (...2 months, cuz yeah) banned use of the ternary operator. 🤣

 

[EJS]

The last company I worked at (...2 months, cuz yeah) banned use of the ternary operator. 🤣

Click to shrink...

I know a lot of people that really, really don't like them and think they're really hard to read. I think nested ones are gross and don't serve a purpose, but clean, simple ones? I think they're great but everyone is different :)

 

[subrock]

The last company I worked at (...2 months, cuz yeah) banned use of the ternary operator. 🤣

Click to shrink...

Wow... I would have left in 2 hours

 

[correojon]

In fact I usually do something a bit different:

int doThing(){
    result = 2;
    if condition{
        //Other code
        result = 1;
    }
    return result;
}

I know it's now widely accepted but I still don't like to exit functions mid-way through return statements, or loops with breaks/exits (I only do it if there's a notable performance gain).

 

[EJS]

All of my fellow ternary friends, hit me up if your company is hiring remote devs, lol.

 

[Deleted member 79451]

We usually avoid more than one return statement, but that doesn't matter so much in small code.

 

[The Albatross]

Example in the op is basically the same, but Im very explicit in my code over being concise. Personally it's much easier for me to read through explicit functions and if/else than those reductive switch statements or ternaries which do like 3 things in a single line. I basically only write ternaries in react statements.

I'm just naturally verbose. Also with minification and uglifying I don't really see the need to be super concise in a statement when my toolchain will end up reducing the size of my statements anyway.

I also prefer writing one function per operation. Like, a function does one thing. One function might map through something, then another function filters the results and a third reduces it. Rather than a single statement that does all three.

Whenever I take over a project and it's written in the most concise way possible it's super frustrating for me to take it over and step back thru the code.

 

[Thorrgal]

A is how I do it

 

[Firebricks]

For the love of God I don't care how efficient and pretty your code is, 2 years later you aren't going to remember why you did it that way, your comment is going to be likely wrong or not there in the first place. Making your code dumb and readable is so important. Compilers are going to do the leg work anyways.

 

[shadow2810]

I prefer B but at work it's A due to eslint rule

 

[KevdotL]

Both are fine but I personally prefer B

 

[ShapeGSX]

The machine code would likely be identical if the compiler is good enough.

 

[Stopdoor]

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.

 

[L.E.D.]

A is the correct way, a function should always have a default return value of some kind.

 

[Zej]

Ternary can be ugly, but I can live with it usually. I vote A.

def thing
    return 1 if condition
  
    2
end

At the end of the day, this is a style thing; you want to be consistent with team patterns/practices. If using JS, then a slightly modified StandardJS linter is great. Having good linters and something like codeclimate is great for a team.

 

[Deleted member 4494]

For me the simplest is always the best:

func x() {
if (y) return 1;
return 2;
}

 

[Mills]

Wow... I would have left in 2 hours

Click to shrink...

I absolutely love the idea of someone going through the potential months long process of application, phone interview, possible background check/drug test, multiple stages of in-person interviews, offer negotiation, resigning your previous position, potentially relocating, orientation and onboarding only to walk out once they see ternary operator is not allowed in the style guide.

 

[ratcliffja]

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.

Click to shrink...

I've been programming professionally for 11 years and prefer the former. Redundancy is a pet peeve of mine.

 

[lightchris]

B is better (less error prone in the long run) than A.
But usually I don't do returns in the middle of a function, so it's this instead:

A is cursed

String result;
if(condition) {
result = 1;
} else {
result = 2;
}
return result;

Click to shrink...

 

[ratcliffja]

Also, I think the last line of a return function should always return something (typically the default value) and not live in a code block.

 

[Weltall Zero]

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.

I would use:

function doThing() {
    return condition ? 1 : 2;
}

Or if the language doesn't support the ? : operator:

function doThing() {
    int ret;
    if (condition) {
        ret = 1;
    } else {
        ret = 2;
    }
    return ret;
}

By the way, in the second example, leaving ret uninitialized helps catch potential situations where you don't set a correct value to it, since modern IDEs will display an error or warning that you're returning a potentially uninitialized value. E.g. this will display an error / warning:

function doThing() {
    int ret;
    if (condition) {
        ret = 1;
    } else if (condition2) {
        ret = 2;
    }
    return ret;
}

Of course, if your IDE doesn't warn about uninitialized values, then the safest option is to initialize it to a valid default value at the beginning.

B is better (less error prone in the long run) than A.
But usually I don't do returns in the middle of a function, so it's this instead:

Click to shrink...

Hahah, beaten by a minute. But yeah, exactly this.