snippetjavascriptTip
Explicit code is always better
Viewed 0 times
javascriptbetterexplicitcodealways
Problem
I recently had the misfortune of working with a little-known JavaScript library and boy did I hate it! From naming conventions that are hard to follow to abstractions that feel like black magic, in my mind it's exactly what's wrong with overengineered tools and a justification for a move back to explicit, albeit potentially verbose and boilerplate-heavy, code.
I know what you may be thinking but hear me out: explicit code _is_ always better. It beats magic. It makes intent obvious. It reduces time spent chasing down nasty bugs.
Implicit behavior can feel clever. It can also be a silent source of mistakes. When a framework maps files to routes or renames properties automatically, you must remember the transformation. You must trace it across files and sometimes across languages.
Explicit code shows the path. An explicit import, export, or variable name tells the reader where a value comes from and how it is used. That clarity is worth a few extra lines.
When writing code with maintainability in mind, prefer a named intermediate variable to a long chain of anonymous transforms. The name becomes a breadcrumb for future readers. Remember that clever one-liners can be elegant. But, they can also be cryptic. Favor explicit, readable implementations over terseness when clarity matters. It also makes the code easier to test and reuse.
I know what you may be thinking but hear me out: explicit code _is_ always better. It beats magic. It makes intent obvious. It reduces time spent chasing down nasty bugs.
Implicit behavior can feel clever. It can also be a silent source of mistakes. When a framework maps files to routes or renames properties automatically, you must remember the transformation. You must trace it across files and sometimes across languages.
Explicit code shows the path. An explicit import, export, or variable name tells the reader where a value comes from and how it is used. That clarity is worth a few extra lines.
When writing code with maintainability in mind, prefer a named intermediate variable to a long chain of anonymous transforms. The name becomes a breadcrumb for future readers. Remember that clever one-liners can be elegant. But, they can also be cryptic. Favor explicit, readable implementations over terseness when clarity matters. It also makes the code easier to test and reuse.
Solution
// Hard to follow
const result = data.
map(item => item.value).
filter(v => v > 10).
reduce((a, b) => a + b, 0);
// Easier to follow
const values = data.map(item => item.value);
const filteredValues = values.filter(v => v > 10);
const result = filteredValues.reduce((a, b) => a + b, 0);Implicit behavior can feel clever. It can also be a silent source of mistakes. When a framework maps files to routes or renames properties automatically, you must remember the transformation. You must trace it across files and sometimes across languages.
Explicit code shows the path. An explicit import, export, or variable name tells the reader where a value comes from and how it is used. That clarity is worth a few extra lines.
When writing code with maintainability in mind, prefer a named intermediate variable to a long chain of anonymous transforms. The name becomes a breadcrumb for future readers. Remember that clever one-liners can be elegant. But, they can also be cryptic. Favor explicit, readable implementations over terseness when clarity matters. It also makes the code easier to test and reuse.
@You may also like
I've recently dabbled in Go and I was surprised how intuitive I found its type system and how much use I got out of it. While I used to dislike the rigidity of static types, I have now come to appreciate their value in making code more predictable and easier to maintain.
Static typing documents intent. It signals which fields are required and which are optional. It narrows the space of valid values and makes refactors safer.
Code Snippets
// Hard to follow
const result = data.
map(item => item.value).
filter(v => v > 10).
reduce((a, b) => a + b, 0);
// Easier to follow
const values = data.map(item => item.value);
const filteredValues = values.filter(v => v > 10);
const result = filteredValues.reduce((a, b) => a + b, 0);type User = {
id: string;
name: string;
email?: string;
};
function findUser(id: string): User | null {
// implementation
return null;
}// Explicit imports
import express from 'express';
import userRoutes from './routes/user.js';
const app = express();
app.use('/users', userRoutes);
// Explicit exports
export default app;Context
From 30-seconds-of-code: explicit-code-is-always-better
Revisions (0)
No revisions yet.