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, 2018 at 6:41
  • I've recently seen some fellow engineers prefer false values to initialize their bools, prompting them to use more confusing "negative" variable names for features that should be on by default, e.g. bool isFeatureDisabled=false. Just like we wouldn't bat an eye at int someSetting=2500 or string textSetting="pretty", we should be perfectly comfortable with initializing isSomething=true.
    – Jeremy
    Oct 10, 2023 at 22:55

3 Answers 3


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

  • 18
    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, 2018 at 7:12
  • 11
    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, 2018 at 9:19
  • 8
    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, 2018 at 9:28
  • 3
    I write things like private boolean active=false; quite often if I want to stress that the initial value declared here is important for understanding the code. I use private boolean active; mainly if some other places (e.g. multiple constructors) will initialize the field with individual values. Aug 2, 2018 at 15:58
  • 5
    @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, 2018 at 17:06

Erik Uzureau and Cameron Yick provide some interesting insight on this article about this question. Their recommendation is for avoiding negative values whenever possible, but naming such that the default is negative when the parameter is optional:


Some benefits we received from choosing default-to-false names:

No Double Negatives: We avoid double negatives, because these overridden properties would only be ever assigned to the value of “true”. (See “implicit default” above). Note this is a guideline in Standard English, but isn’t true across all spoken languages.

Implicit Default: In many languages, the absence of a boolean property is interpreted as if the property were false (e.g. Javascript / Python). Optional properties with false defaults mean there’s no need to explicitly declare the default value in the code. We are also absolved of the responsibility of documenting the default value. All this means fewer details for the reader to process in order to understand how your widget works.

Convenience through Convention: Users of the widget get consistent behavior where they can assume that all optional properties are set to false. This is preferable to having an inconsistent mix of true and false possibilities, and helps people understand how a widget behaves without needing to inspect the documentation or source code.

  • I propose prioritizing default values of false for bools (especially when it produces negative variable names) is still usually an anti-pattern. For example, is 0 always the right default for an optional number parameter in JS? Is '' always the right default for an optional string? Similarly, the default value for an optional bool parameter should depend on the parameter & its context, not someone's shortsighted desire to initialize everything to false.
    – Jeremy
    Oct 10, 2023 at 22:32

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, 2018 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, 2018 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, 2018 at 9:18
  • Sure, we can agree on that ;)
    – David Arno
    Aug 2, 2018 at 9:27
  • 1
    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, 2018 at 12:02

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