0
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?

5
  • 3
    At least in this example, I'd call it "pointlessly worrying about micro-optimisations". Sep 23 '20 at 10:36
  • 3
    This is not an error. At all. There is literally no problem here. The worst thing you can worry about is that it's slightly less optimized than possible. But that's not a problem. At all.
    – user253751
    Sep 23 '20 at 10:37
  • What about "less efficient code"?
    – JensG
    Sep 23 '20 at 10:58
  • 1
    It’s a really bad example. There are two situations, and you want to encode that they exclude each other, when there is no reason to exclude it. Nothing wrong.
    – gnasher729
    Sep 23 '20 at 16:44
  • 1
    While I wouldn't bother "fixing" this code in a commit of its own, I would do this minor improvement if I had any other reason to change this class.
    – Llewellyn
    Sep 23 '20 at 22:10
7

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.

1
  • Thomas, can we please do a sweep of the front page and clear out the heap of crappy questions that are currently there? Sep 24 '20 at 22:36
0

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".

3
  • 1
    JensG, ever heard of “premature optimisation”? If you asked me to change the code, I’d say “go away”.
    – gnasher729
    Sep 23 '20 at 16:45
  • My saying is “Beginners save nanoseconds. Experts save microseconds”. I don’t look at nanoseconds savings. And no, there are no milliseconds here.
    – gnasher729
    Sep 23 '20 at 16:47
  • You completely misunderstood the text. If one's general habit is to write sloppy code because all else would be "premature optimization", one just generally tends to write sloppy code, regardless of the excuse one may come up with. And I would not have written the above unless I had to deal with a lot of sloppy code from other people in my career. The whole reason why I cheer that question so much is, because it tells me there are people out there who actually really care about what they are doing.
    – JensG
    Sep 24 '20 at 14:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.