For example, to store whether sound is on, I have a boolean originally named "isSoundOn":

private boolean isSoundOn=true;

however, the default value of boolean is false, but I want my application to turn on the sound at start. My question is, should I change the name of isSoundOn into isMute, so that it becomes "false" correctly by default?

Or in general, should I keep a boolean be false by default, even if I may need to reconsider the name of boolean?

  • 1
    Is there a particular reason why you can't leave it as is? Making a change like that is the kind of thing which is likely to create bugs. You'd have to check logic everywhere where it is used as well. – Neil Aug 2 '18 at 6:41

No, you absolutely should not choose variable names to conform to your language's default values.

The point of variable names is to make reading code easier for the maintainer. Default values are a detail of the language specification (or sometimes even of the implementation) and may or may not match with your intent in using a flag variable. Therefore it's much, much better to choose the variable name to be as clear as possible for the reader, and use explicit initialization if this is necessary to get the desired initial value.

(By the way, IMO there is no reason to use initialization if the well-defined default value does match your program semantics. Expressions like private boolean active = false; look uncomfortably as if the author didn't know about the language specification and make me wonder what else they don't know.)

  • 14
    I disagree about the last paragraph, though. Explicit assignments can clarify the programmer's intent. Reading from an unassigned variable is well-defined as far as the Java language is concerned, but could very well represent a bug in the business logic. – amon Aug 2 '18 at 7:12
  • 2
    Since when? The Java compiler doesn’t allow you to read a variable unless it can prove it has a value assigned to it. – gnasher729 Aug 2 '18 at 7:51
  • 8
    I agree with amon (and disagree with Kilian and Arno) here: Even if the default initialization of private boolean active gives active the desired value of false, it creates ambiguity - did the developer really think "I know the default value is false, no need to write = false" or did he just happen to forget to write the initialization (= true). I do not think there is any developer (me included) who never ever forgot to initialize a variable (by accident). By writing this = trueor = false you train yourself to both initalize your stuff and remove that ambiguity. – CharonX Aug 2 '18 at 9:19
  • 6
    Addendum: Two more issues: 1) By writing = true or = false you make the code easier to read (since it is explicitely written what the variable holds, instead of implicitely). 2) Training yourself to rely on language-specific default values turns horrible when you find yourself switching to a language that has no default value - like switching from Java to C++ – CharonX Aug 2 '18 at 9:28
  • 2
    @17of26 I really think you should reassess. I only leaving something unassigned in the declaration if there's isn't a known obvious default i.e. it will be assigned in the constructor. Java has these rules about defaults because of the havoc unassigned variables cause in C and C++, not because they are the 'right' value. Code that depends on default values for variables looks sloppy and amateurish to my eyes. – JimmyJames Aug 2 '18 at 17:06

Alternative approach would be to have an enum (or based on your programming language a type with only two possible values, but with more descriptive names then true/false)

public enum SoundState
    On = 0,  // 'On' by default
    Off = 1

Then your code will looks more straightforward about it's intention.

public class Setting
    public SoundState Sound { get; set; }

var settings = new Setting();

if (settings.Sound == SoundState.On)
    // do something
  • Downvoter, feel free to leave a comment, will be glad to improve an answer – Fabio Aug 2 '18 at 8:59
  • 1
    I've upvotes, but I'd question your On = 0 and Off = 1. The = n parts are not needed: On is specified first, so will be the default and will have the value 0 by default. This ties into the last paragraph of Kilian's answer: don't explicitly repeat default, implicit compiler behaviour. – David Arno Aug 2 '18 at 9:10
  • @DavidArno, true in case you have only 2-5 items and will not save/serialize them in form of integer. With more items you end up counting them to find correspondent name or will re-order them by accident or intentionally which will mess up with serialized values. This kind of rules are usually opinion based and every developer/team should just select one and follow it. – Fabio Aug 2 '18 at 9:18
  • Sure, we can agree on that ;) – David Arno Aug 2 '18 at 9:27
  • I am the downvoter. I am strongly against non-obvious pick of numeric values just to align with the default value. You should not ever use the default anyway (see the other answer and also discussion there). – max630 Aug 2 '18 at 12:02

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.