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?
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.)
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.
= 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++
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.
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.
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.
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
}
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.
falsevalues 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 atint someSetting=2500orstring textSetting="pretty", we should be perfectly comfortable with initializingisSomething=true.