Sometimes while I'm editing something I see some useless code added by other developers, probably due to habit.

Editing this code will not make any difference, so is it appropriate?

In my specific case I'm talking about Java private fields like this:

private int aSimpleInt = 0;
private boolean myBool = false;
private MyObject obj = null;

declaring the default values is redundant and useless.
Should I remove them or just skip?

  • 1
    Or is it?
    – Vorac
    May 23 '14 at 8:09
  • related (possibly a duplicate): Make a big deal out of == true? "There is a colleague of mine who constantly writes: if (someBool == true) It drives me up the wall! Should I make a big deal of it or just drop it?"
    – gnat
    May 23 '14 at 8:09

Declaring values that would already have been assigned by the compiler is useless for the behaviour of the program. However, that isn't what you should be optimizing as a professional developer. Instead, you should maintain your code base in the state that best supports ongoing development.

If code were only about its semantics here and now, you could think really hard once, slam out the necessary assembler code and never think about it again. But in the real world, requirement changes, fixes, maintenance, format changes etc. etc. keep coming one after another without end. It is crucial that your code base not only does what it's supposed to, but also remains in a state that lets you do the ongoing work that will be required.

Spelling out things that would already be the default can be helpful for that, so it's not automatically a bad idea. After all, you don't pay the compiler by the number of characters it consumes. You should declare things when doing so makes the code more readable.

In Java, global variables are automatically initialized, but local ones aren't; depending on the experience levels in your team (your current team and the expected future team!) it may be a good idea to spell things out so nobody ever has to think, even for a second, what value some variable will have at run-time, or it may not be. But "It doesn't change anything in the compiled program" is not a sufficient argument to call code "useless".

  • 1
    "It doesn't change anything in the compiled program"... a great example is inlining. Sure, you could do that by hand and it wouldn't change anything in the compiled program...
    – Móż
    May 23 '14 at 8:34
  • // false by default - compiler is happy, JVM is happy, and humans are happy. Nov 28 '16 at 7:13

The purpose of code is not so much communicating with the machine, but with fellow developers, so that a program can be maintained and effort is not wasted. To me, redundant code is bad in the sense that it obscures the purpose of the program. The compiler does not get tired to read lines, but a human reader does.

Let's consider a silly example:

int addTwo(int someNumber) {
    return someNumber + 2;

You could have n lines adding and subtracting from someNumber before you did the actual operation. The hit on compilation time and performance is probably minimal. However, if another developer has to scroll hundreds of lines (and in the worst case, think hard about them just to find out that they are useless), then you have wasted many minutes, and human effort.

So, my answer would be: remove redundant code and let readers focus on the purpose of your program.

  • Well, the field declarations are not redundant. Only the initializations, which are short.
    – Jan Hudec
    May 23 '14 at 9:17
  • @JanHudec: you are right, I meant the initialization, not the declarations. My example was focused on "lines of code", but I meant any character that has to be read and understood but does not add to the meaning.
    – logc
    May 23 '14 at 10:14
  1. Quite often such things do have a function, in fact in Java in some situations it's required to do such an assignment.
  2. Even if not explicitly required, for clarity it's often a good idea to do such an assignment, even if only for readability.
  3. You should not generally change code unless there's a technical or functional reason, changes just because "it would look nicer otherwise" are not a good idea and all too often lead to bugs, especially if performed by people not intimately familiar with the system and/or language who can't predict all possible side effects of their changes.

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.