This content originally appeared on HackerNoon and was authored by Maximiliano Contieri
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
\
This content originally appeared on HackerNoon and was authored by Maximiliano Contieri
Maximiliano Contieri | Sciencx (2025-03-17T12:23:00+00:00) Overusing Implicit Returns Makes Your Code Harder to Read and Debug. Retrieved from https://www.scien.cx/2025/03/17/overusing-implicit-returns-makes-your-code-harder-to-read-and-debug/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.