Code Smell 129 - Structural Optimizations
We love to improve time and space complexity by guessing not real scenarios

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...
We love to improve time and space complexity by guessing not real scenarios

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.
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: Don't optimize anything until you have a real-use scenario benchmark.
Cover your scenarios with tests.
Write readable (and possibly non-performant) code.
Do a real benchmark with real user data. (No, iterating your code 100,000 times might not be a real use case).
If you have conclusive data, you need to improve the benchmark's found bottlenecks using the Pareto principle.
Attack the worst 20% of problems causing 80% bad performance.
In university and online courses, we learn algorithms, data structures, and computational complexity before good design rules.
We tend to overestimate the (possible) performance problems and underestimate code readability and software lifetime.
Premature optimization often has no evidence of solving real problems.
We need to surgically improve our code when the facts tell us we have a real issue.
for (k = 0; k < 3 * 3; ++k) {
i = Math.floor(k / 3);
j = k % 3;
console.log(i + ' ' + j);
}
// This cryptic piece of code iterates a
//two-dimensional array
// We don't have proof this will be useful
// In real contexts
for (innerIterator = 0; innerIterator < 3; innerIterator++) {
for (outerIterator = 0; outerIterator < 3; outerIterator++) {
console.log(innerIterator + ' ' + outerIterator);
}
}
// This is a readable double for-loop
// 3 is a small number
// No performance issues (by now)
// We will wait for real evidence
[X] Manual
This is a semantic smell.
We might find the code harder to read.
We need to stop optimizing for machines and start optimizing for human readers and code maintainers.
We need to avoid programming languages designed for premature optimization and favor robust ones.
Photo by Priscilla Du Preez on Unsplash
Optimism is an occupational hazard of programming: feedback is the treatment.
Kent Beck
This article is part of the CodeSmell Series.