
I’m a senior software engineer loving clean code, and declarative designs. S.O.L.I.D. and agile methodologies fan.
Search for a command to run...

I’m a senior software engineer loving clean code, and declarative designs. S.O.L.I.D. and agile methodologies fan.
No comments yet. Be the first to comment.
In this series, we will see several symptoms and situations that make us doubt the quality of our developments. We will present possible solutions. Most are just clues. They are no hard rules.
Cryptic Code is Bad Code
Approve the logic once, then let it run the same way forever.

Different stages need different brains.

One Second Brain doesn't scale past one skull.

Style errors double when nobody enforces them.

Know who speaks before the skill runs TL;DR: Always define a clear role at the top of every skill file so you know whose perspective drives the execution. Common Mistake ❌ You write a skill full of

TL;DR: Functions with unclear names hide intent and confuse readers. Use descriptive, action-oriented names.
Functions named with generic terms force readers to dive into the implementation to understand their behavior.
This wastes time and increases the chance of errors.
Naming becomes even more critical when working with standalone functions, where the class name doesn't provide additional context.
This issue directly relates to the Tell, Don’t Ask principle.
Instead of exposing ambiguous behaviors that force the caller to infer functionality, imperative names convey the exact action, guiding the reader without needing to inspect the code.
When you name functions descriptively, you eliminate unnecessary guesswork and align with this principle.
public String dateFormatting(Date date) {
return new SimpleDateFormat("yyyy-MM-dd").format(date);
}
public void load() {
System.out.println("Loading...");
}
public String formatDate(Date date) {
return new SimpleDateFormat("yyyy-MM-dd").format(date);
}
public void loadUserPreferences() {
System.out.println("Loading user preferences...");
}
[X] Manual
You can detect this smell by reviewing function names that use vague terms like do, run, process, load, etc.
Automated linters can flag these patterns or highlight functions with overly generic names.
[X] Beginner
Function names should create a clear one-to-one correspondence between their name and functionality.
Breaking this Bijection forces developers to examine code details for context, slowing down debugging, reviews, and extensions.
AI tools sometimes generate generic function names without understanding your domain.
When using AI, specify that function names must be descriptive and action-oriented.
AI models can help detect ambiguous names by comparing function signatures with predefined naming best practices.
Combining AI with manual code review yields the best results.
Remember: AI Assistants make lots of mistakes
| Without Proper Instructions | With Specific Instructions |
| ChatGPT | ChatGPT |
| Claude | Claude |
| Perplexity | Perplexity |
| Copilot | Copilot |
| Gemini | Gemini |
Function names are not just labels; they are contracts with the reader.
Ambiguous names break this contract and lead to confusion.
Descriptive, action-oriented names simplify communication and make your code easier to maintain and extend.
Code Smells are my opinion.
Photo by britishlibrary on Unsplash
A function name should be a verb or a verb phrase, and it needs to be meaningful
Robert C. Martin
This article is part of the CodeSmell Series.