Overusing Implicit Returns Makes Your Code Harder to Read and Debug

Your language adds clever features. Making YOU more obsolete

TL;DR: Overusing implicit returns makes your code harder to read and debug.

Problems 😔

• Reduced readability
• Hidden logic and unclear intent
• Debugging difficulties
• Misleading simplicity
• Over-reliance on syntax
• Language dependency
• Loss of explicitness
• Inconsistent style

Solutions 😃

1. Use explicit returns
2. Break down complex logic
3. Avoid nested closures
4. Prioritize clarity over brevity
5. Stick to conventions

Refactorings ⚙️

Context 💬

Recently, I wrote an article on this series:

One of my readers, Marcel Mravec pointed out this “feature”:

New in Swift 5.1: The return keyword can now be omitted when declaring functions and computed properties that only contain a single expression, which is really nice when declaring simpler convenience APIs:

This kind of “language feature” creates more friction when transitioning from accidental languages. In this era you need to be ready to transition between accidental languages quickly.

Some languages allows you to omit the return keyword in single-expression functions and closures.

While this can make your code concise, overusing it can lead to confusion, especially in complex or nested logic.

When you rely too much on fancy tricks like implicit returns or ridiculous castings, you risk making your code harder to understand and debug.

Sample Code 📖

Wrong ❌

func calculatePrice(items: [Double], taxRate: Double) -> Double {
    items.reduce(0) { $0 + $1 } * (1 + taxRate / 100)
    // If you are not familiar to swift 
    // you cannot understand what is returning
}

Right 👉

func calculatePrice(items: [Double], taxRate: Double) -> Double {
    let subtotal = items.reduce(0) { sum, item in 
        sum + item 
    }
    let taxFactor = 1 + taxRate / 100
    return subtotal * taxFactor
}

Detection 🔍

This is a language feature.

Using Abstract syntax trees most linters can warn you, but they don’t flag it as a smell.

Level 🔋

Why the Bijection Is Important 🗺️

When you learn to program in pseudocode, you acknowledge functions return values.

Writing less code is not always better.

Sometimes you break the Bijection between your knowledge and the code you write.

When you abuse implicit returns, you break the MAPPER by hiding the logical flow of your program.

It’s harder for others (and your future self) to understand the intent behind the code.

AI Generation 🤖

AI generators often favor concise code, which can lead to overuse of implicit returns.

While this makes the code shorter, it may sacrifice readability and maintainability.

AI Detection 🥃

AI tools can identify and refactor implicit returns into explicit ones with simple instructions.

You should always review the changes to ensure they improve clarity without introducing unnecessary verbosity. You are the pilot!

Try Them! 🛠

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Convert it using explicit returns

Conclusion 🏁

Abusing implicit returns might save a few keystrokes but costs you readability and maintainability.

You should be explicit when your logic gets complex or spans multiple lines.

Sadly, many languages encourage this code smell.

Some of them allow it on single expressions like:

Some of them allow it on lambdas:

And many other allow your tu omit the return anytime:

• Ruby
• CoffeeScript
• Haskell
• Elixir
• F#
• Erlang
• Clojure

You will notice this a feature present on most functional languages.

Relations 👩‍❤️‍💋‍👨

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-ii-o96s3wl4

https://hackernoon.com/code-smell-292-missing-return

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxxii

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiv

Disclaimer 📘

Code Smells are my opinion.

Credits 🙏

Thank you Marcel Mravec for this suggestion.

Photo by 愚木混株 cdd20 on Unsplash

Explicit is better than implicit.

Tim Peters

This article is part of the CodeSmell Series.