"Always use early returns" - LinkedIn Edition

11/25/2024

5 minute read

Ahhhh dear LinkedIn - a pool of gems where everyone is expert in everything. Over the time I collected some trophies from there and today I want to discuss one of them: "Always use early returns".

The original post

^{Image credit: https://www.linkedin.com/in/dev-mbabar/}

The author claims higher readability, maintainability and efficiency. Quote:

Edge cases are handled immediately, focusing the main logic on processing.

Key Takeaway: Embrace early returns to handle edge cases upfront and keep your code clean and efficient.

Now is this statement true? Let's start with the fact, that the first example seems to be more convoluted on purpose. But more to that later. But is nesting ternary operators clean and efficient? Do you see what the main logic here is? Well, me neither. Maybe indentation would have helped:

public List<int> ProcessData(List<int> data) =>
  data == null
    ? null
    : data.Count == 0
      ? new List<int>()
      : data.Select(d => d*2).ToList();

But also this helps only slightly. But it doesn't really matter. No always is almost always a red flag and should raise your suspicion! Yes of course there are cases where it helps to have an early return, especially if you need some sanity checks in the beginning. And that is why I said earlier, the first example is convoluted. For starters, turn around the initial if (And for bonus, use nullability hints if you can - they increase also readability and maintainability).

public List<int>? ProcessData(List<int>? data)
{
  if (data is null)
  {
    return null;
  }
	
  return data
    .Select(d => d*2)
    .ToList();
}

I omitted the check for Count > 0 because the code above and the LINQ code here is virtually the same in the outcome. Yes, there is a slight difference in performance. But that probably doesn't matter (in >95% of cases). But we can go further and eliminate even the first return:

public List<int>? ProcessData(List<int>? data) =>
  data?
    .Select(d => d*2)
    .ToList();

I said this a lot and I gladly repeat this: Check fact the stuff. It doesn't matter if someone has 20 Followers or 25k. Everyone can make mistakes and has a different context and environment. Something which might be true for them doesn't necessarily be true for you. Fact check the stuff I am writing here. Am I right 100% of the time? Sure, but that isn't a standard you should have for everyone. Just kidding - of course I also write stuff which is sometimes false, sometimes too vague and/or not applicable for your case. And people could and should call me out on those topics (and I happy so that they did in the past^{In the comments}).

Bonus Edition

I found another one, which keeps me puzzling whether or not LinkedIn is a real place. And I know that this is from a Java Snippet, but this could be .NET as well. Now is this really more readable? Does it increase maintainability? Sure, it is only a very slim function and probably it wouldn't matter much. And also that is just an example and should showcase the idea rather than concrete example. But I can almost assure you, that people will go into their codebase and "refactor" their code because someone with Xk Followers (in this case over 170k followers!) showed them this "trick". And also this whole "Junior", "Senior" thing is just odd and now I did officially run out of quotes. Maybe I should call it a day here!

Bonus

I can also recommend @NickChapsas Series "Code Cop" also tackling similiar gems of the internet (including questionable advice from yours truly - me).

Bonus 2: .NET Edition

PS: Of course I did not took long until this popped up - which is basically a copy-cat of the original snippet (at least the "Senior" / "Junior" tag is gone).

Because of the echo chamber effect, this can be seen as the "norm". Something your code should look like. These days the word Clean Code will be thrown around as there is this "wisdom of the crowd" what it really means. But it isn't: Ask 5 developers about a piece of code and how it should look "clean" and you probably will get 3,4 or even 5 different answers. The important bid is that it has to work for you and your team (given that the team has a certain standard of quality).

Conclusion

Okay, now I've let off some steam. And what do we do next? It's important to understand that “simple” and easily digestible content simply performs very well on platforms like LinkedIn. I'm not taking myself out of the equation here. You only have to scroll back a little on my LinkedIn timeline and you'll discover just such wonderful code snippets. I strongly assume that some people shook their heads when they saw my content. Therefore: Check to what extent such tips are valid for your specific context.

Overload resolution in C#

On a recent LinkedIn Post from Saeed Esmaeelinejad, he asked what is the outcome of:

bool flag = SomeMethod();

M(flag ? 1 : 2);

void M(long number) => Console.WriteLine("long");
void M(short number) => Console.WriteLine("short");

What is the outcome?

"Use always a StringBuilder" - Internet myths

Use always a StringBuilder

That is what you can read from time to time. The basic idea is, that a StringBuilder is "better" ^{to be defined}.

Why are people telling that ^lie? Let's discuss this and see what it isn't true.

How not to benchmark!

I came across a recent LinkedIn post about the let statement in LINQ and it's performance implication. And in typically influencer fashion it out right claimed that using let in LINQ is a bad idea and should be avoided. But is it a bad idea?

Table of Contents