4

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?

ocomfd
  • 5,652
  • 8
  • 29
  • 37
  • 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 02 '18 at 06:41

3 Answers3

9

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

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
  • 17
    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 02 '18 at 07: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 02 '18 at 07:51
  • 1
    @amon, completely disagree with you and agree with Kilian. Clearly an opinion thing therefore. :) – David Arno Aug 02 '18 at 09:08
  • 10
    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 `= true`or `= false` you train yourself to both initalize your stuff **and** remove that ambiguity. – CharonX Aug 02 '18 at 09:19
  • 7
    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 02 '18 at 09:28
  • 1
    @gnasher729 Java's rules for initialization depend on the kind of variable (e.g. local versus instance variables). See [JLS §4.12.5](https://docs.oracle.com/javase/specs/jls/se10/html/jls-4.html#jls-4.12.5) for details. In short, all boolean values are initialized to false except local variables which require explicit initialization. I'd prefer if the “definite assignment” rules for locals would also apply to other variables, but I understand why that is impossible. – amon Aug 02 '18 at 09:33
  • If I see "private boolean active;", I assume the programmer knows what they're doing. If I see "private boolean active = false;", it says to me that they don't really understand the language and everything they write is suspect. – 17 of 26 Aug 02 '18 at 13:21
  • 2
    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. – Ralf Kleberhoff Aug 02 '18 at 15:58
  • 4
    @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 02 '18 at 17:06
  • `as if the author didn't know about the language specification and make me wonder what else they don't know`. We can never assume that other developers are as smart or smarter than us. In the same way, we can't assume they share the same level of expertise and coding practices. Assumptions are the seed of evil. Working on clear statements makes life easier for everyone. By initializing the const we also get used to this practice and we so do it in other languages, which defaults are not so clear `const active;` – Laiv Oct 18 '22 at 14:47
2

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:

https://www.serendipidata.com/posts/naming-guidelines-for-boolean-variables

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.

Thiago Pereira Maia
  • 143
  • 4
1

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
}
Fabio
  • 3,086
  • 1
  • 17
  • 25
  • Downvoter, feel free to leave a comment, will be glad to improve an answer – Fabio Aug 02 '18 at 08: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 02 '18 at 09: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 02 '18 at 09:18
  • Sure, we can agree on that ;) – David Arno Aug 02 '18 at 09: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 02 '18 at 12:02
  • @max630, reason for using enum is not a default value, but more comprehensible usage of the values names. In comparison with continuous battle between variable names `isMute` or `isEnabled` and possible usage of negated conditions. – Fabio Aug 02 '18 at 12:13
  • This is good. But making `On = 0` you are trying to utilize its default value, so that it could be written as `SoundState Sound`, with no initialization. Which is very implicit. – max630 Aug 02 '18 at 12:44