Your code should not look like alien hieroglyphics. TYes many symbols of mystery make your code difficult to understand and maintain.
The problems with the cryptic code
Solutions
- Avoid smart language hacks
- Prefer significant variable names
- I -Extract complex expressions
- Use language features wisely
- Limit the complexity of the expression
Refactorings
Context
Syntactic noise refers to code construction that is not a direct map in real-world concepts.
While symbols such as '{}' are properly syntax in many programming languages, excessive use creates a code that looks like abstract art rather than a solution to a problem.
When you pack a lot of operators, brackets, and special characters in a single expression, you force readers to think of complex syntax before understanding what the code is doing.
Connecting between the symbols and definitions of the real world makes it more difficult to understand, debug, and maintain your code.
Think of your code as a form of communication with other developers (and your future self).
Like so much punctuation !!! Makes text !!?!? Hard to read !!!
Excessive syntactic noise creates similar obstacles to the code.
Sample Code 📖
Wrong ❌
[](){}
/* This valid lambda function:
Captures no variables.
Takes no arguments.
Performs no actions.
[]: This is the capture clause.
It specifies which variables from the surrounding scope
are accessible inside the lambda function.
An empty capture clause [] means the lambda
*does not capture* any variables from the surrounding scope.
(): This is the parameter list.
It defines the arguments the lambda function accepts.
An empty () means the lambda takes *no parameters*.
{}: This is the function body.
It contains the code that the lambda executes when called.
An empty {} means the lambda has no operations
to perform—it does nothing.
*/
const result = arr.filter(x => x !== null && x !== undefined)
.map((y) => ({ val: y.value, meta:
y.meta ? y.meta : {default: true}}))
.reduce((acc, {val, meta}) =>
meta.default ? acc : [...acc,
{processed: val * 2, origin: meta}], [])
.some(({processed}) => processed > 10 && processed < 50);
Right 👉
function isNotNull(x) {
return x !== null && x !== undefined
// Another code smell here
}
function mapToValueAndMeta(y) {
const meta = y.meta ? y.meta : { default: true }
return { val: y.value, meta }
}
function reduceToProcessedList(acc, { val, meta }) {
if (meta.default) {
return acc
}
return [...acc, { processed: val * 2, origin: meta }]
}
function isProcessedInRange({ processed }) {
return processed > 10 && processed < 50
}
// This is more declarative but far from
// Domian business and too generic
const filtered = arr.filter(isNotNull)
const mapped = filtered.map(mapToValueAndMeta)
const processedList = mapped.reduce(reduceToProcessedList, [])
const result = processedList.some(isProcessedInRange)
Discovery 🔍
You can see the syntactic noise by finding lines with multiple levels of brackets of brackets, parentheses, or braces, operations that reach many lines, and expressions that allow you to count the opening and closure of symbols.
The code that requires horizontal scrolling due to the density of the symbol is another red flag, many ternary operators in a single expression, and nested arrow function with implicit return.
Modern ideas and linters can help identify extremely complex expressions.
Eslint rules such as complexity and max-deep flag code with so many nested construction.
The “cognitive complexity” measurement in Sonarqube also helps identify the hard-to-undance code.
Exceptions 🛑
- Code to -PTIMIZE by machines
Tags 🏷️
Level 🔋
Why is bijection important 🗺️
The code should be one-to-one with the real world concepts it represents.
Each variable, function, and expression should match something that is exposed to your domain problem.
When you clutter a code with excessive syntax that does not represent real-world entities, you create an connectivity between the problem and solution.
Note that the code is written once but read several times.
By maintaining a clear bijection between code construction and real-world concepts, you create software that will remain maintained throughout its lifecycle.
AI Generation 🤖
AI code generators sometimes create syntactic noise.
When you request a code with minimal guide guide, AI tools are often optimized for reading brevity, packing multiple dense one-liners.
This method makes a “clever” but hard-to-maintain code with confined methods, nested ternaries, and complex expressions.
Modern AI generators such as GPT models can also create extraordinary dense code when asked to solve problems with small lines, which inadvertently produce solutions syntactically noisy.
They cannot identify if the code crosses the threshold of the ability to read without specific instructions to prioritize clarity in conciseness.
Please do not prompt it.
Ai detection 🥃
AI tools can help to detect and adjust the syntactic noise with the appropriate motivation.
If you use instructions such as a “refactor for the ability to read” or “simplify this expression,” you will get a cleaner code.
Note: Ai assistants make many mistakes
Suggested Prompt: Remove Syntactic noise and make it more declaration
Conclusion 🏁
Syntactic noise is like static communication interference – valid, but getting in the way of understanding. When you prioritize clear code in smart one-liners, you create software that is easier to understand, debug, and maintain.
The next time you are tempted to pack a lot of operations with a dense expression, keep in mind that you are not just writing for the computer – you are writing for people.
Break complex operations with named steps that reflect real-world concepts, and your code will tell a story that everyone can follow.
Related reading
Additional information 📕
Denial: The smell of code is my opinion.
The function of good software is to simplify the complex
GRACIANO CRUZ
This article is part of the Codesmell series in Hakernoon
