I am sick and tired of “X is a code smell” articles. Everything in software development depends on context. What makes perfect sense in context A makes zero sense in context B. If (for example) all you know is front-end JavaScript development then don’t make claims about anything outside of that context. Have you ever only worked in one industry? Then perhaps realise that your experience might be limited to that context. While being completely and utterly wrong in a different context. I have worked in many different contexts in my 25+ years career. AAA game development, high-performance compilers, low-powered embedded systems, typescript/react front-end development, enterprise software applications, mobile apps etc. And the #1 thing I have learned is that nothing is true or false in all contexts. Everything depends on your particular situation and context. So be aware of your limited context and perhaps think about what would no longer be true/false when you change the context.
I recall at one point a code smell meant something more like “this may be off, but not necessarily, so you should investigate and be sure in your context.” It was better than “considered harmful”, which was more absolute. That nuance may once again be lost.
In my experience, complexity arises from a mismatch between data structure and data usage patterns, and it can be eliminated by changing the data structure to match its usage.
Ye. But if the problem to solve is complex or convoluted enought so will the solution be. Somewhere the code has to actually do something no matter the approuch.
> I am sick and tired of “X is a code smell” articles. Everything in software development depends on context.
Your comment sounds like you didn't even read the submission. Here's, quite literally, the second paragraph:
> "In my opinion these are code smells. Smells don’t necessarily indicate actual issues, just patterns that are likely to be used incorrectly and thus warrants extra care."
You see, the author points out quite unambiguously that context is key.
Then to the extent that “code smell” has become heard as “code stink” it is not useful as a descriptor. Then again, I suppose “maybe be careful with that pattern” isn’t quite the click-inducing thought leadership demanded in our present day.
> Then to the extent that “code smell” has become heard as “code stink” it is not useful as a descriptor.
It's a very appropriate descriptor. Think about it for a second. A smell all by itself is not a sign of a problem.
> Then again, I suppose “maybe be careful with that pattern” isn’t quite the click-inducing thought leadership demanded in our present day.
Your personal assertion does not make any sense. "Code smell" is a widely-established, age-old concept. The concept of a "code smell" even precedes the concept of a "click".
I've just come to hate the term "code smell". There are times when you need to take a deeper look at someone else's code, but the implementation may be completely fine given the context.
If you look at the compiler output from anything, even the "safe" languages like Rust, and I mean really get right down to assembler instructions, you know what you'll see?
Global variables and computed gotos, all over the shop.
Does it work, well, safely, and quickly? Of course.
Would you write code like that? Well, that kind of depends, eh? Is it the correct solution to the problem you have *absolutely right now* and will it remain the correct solution in the face of changing requirements?
> instead of flags you could use some convoluted array of pointers to the objects for each flag to separate concerns
Which is absolutely lovely if you have limitless memory and processing cycles. Make a sparse hash table of values to make sure you're only storing valid flags? Genius! How much memory is that going to take up?
I don't even know how much memory this modern desktop PC I have here has, hundreds or possibly even thousands of kilobytes of RAM. One of the microcontrollers I write code for has 128 bytes of RAM (this paragraph wouldn't fit) and a clock speed in the hundreds of kHz, so, if you're implementing hash tables Good Luck With That.
It reminds me of the BCS guys who reckoned that every bit of code should be written in Java, no matter what.
The second para of the article addresses this, as does the summary at the bottom. Maybe read the article and respond if your concerns about this particular article are still valid? Maybe it applies to the general "X is a code smell" article.
> Smells don’t necessarily indicate actual issues, just patterns that are likely to be used incorrectly and thus warrants extra care.
Code smells are easier to spot in changes. When function/method arguments are added repeatedly and you realize it's time for a refactor. Or better, it's time to use monads (oh well).
