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 😃

Use explicit returns
Break down complex logic
Avoid nested closures
Prioritize clarity over brevity
Stick to conventions

Refactorings ⚙️

https://hackernoon.com/improving-the-code-one-line-at-a-time?embedable=true

Context 💬

Recently, I wrote an article on this series:

https://hackernoon.com/code-smell-292-missing-return?embedable=true

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:

https://www.swiftbysundell.com/tips/omitting-the-return-keyword/?embedable=true

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 🔍

Automatic

This is a language feature.

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

Tags 🏷️

Readability

Level 🔋

Intermediate

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

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Qwen	Qwen

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:

Swift
Kotlin
Scala

Some of them allow it on lambdas:

Javascript
Python

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

https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true

This article is part of the CodeSmell Series.

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd?embedable=true

Overusing Implicit Returns Makes Your Code Harder to Read and Debug