Errors that don't make code behave wrong from user's point of view - how would you call them?

Question

var file_extension = 'txt';

if (file_extension === 'txt')
    alert('plain text');
else if (file_extension === 'md')
    alert('markdown');

var file_extension = 'txt';

if (file_extension === 'txt')
    alert('plain text');
if (file_extension === 'md')
    alert('markdown');

The second example is wrong: there is no need to use the second if. I would say the use of the second if is an error (since it should be else if instead), but this error doesn't make the code behave wrong from the user's point of view.

If you write documentation, how would you call such errors to differentiate them from those causing crashes, wrong messages, and so on?

Answer 1

Since there's no unexpected or incorrect behavior, I'd consider it technical debt. It's unclear why the code is the way it is, and this unclear structure can slow down the ability to maintain the system. This is a relatively simple example of technical debt, however.

Answer 2

Although everybody seems to believe that there is no problem with it, or no problem to worry about, I tend to disagree. Because this is about professionality.

First, as software developers we (should) strive for writing the best code we can. Even in this case, where the problem seems small, everybody will agree that this is not the best code possible - assumed "best" is defined in terms of

1. correct
2. performant
3. maintainable

Second, even if the performance drop is minimal, one cannot decide without knowing the use case context whether it should be fixed sooner or later. If some piece of code is called a few thousand times in in a short time frame for some reason, every msec I can save per call will become seconds quickly. Last not least, if you are writing a library, one can't even tell less, because you don't know who is going to use it in which way and for what purpose.

Third, todays compilers do a lot of optimization work. New hardware we buy is usually faster than the old one. The average developer seems to use this as kind of an excuse. "Sure, my code is less efficient, but my brand new CPU can do it still faster than the old one, even without optimizations. So why bother?" Because the added hardware performance or the better compiler optimizations is not there for you to waste them! The idea is to get computations done quicker and with less resources, not as compensation for sloppy code.

As with everyhing, there are no fixed rules, because the mileage may vary with every piece of code and every project. But the OP just for thinking about it and asking that question he would deserve a double upvote.

PS: To qualify as an answer to the question: I'd call it "inefficient code".