variables.md

Variable

Begin global constant names with prefix "k"

Examples:

const double kParagraphSpacing = 1.5;
const String kSaveButtonTitle = 'Save';
const Color _kBarrierColor = Colors.black54;

However, where possible avoid global constants. Rather than kDefaultButtonColor, consider Button.defaultColor. If necessary, consider creating a class with a private constructor to hold relevant constants. It’s not necessary to add the k prefix to non-global constants.

class Button{
   static const defaultColor = Colors.black54;
}
Button.defaultColor;

Avoid abbreviations

Unless the abbreviation is more recognizable than the expansion (e.g. XML, HTTP, JSON), expand abbreviations when selecting a name for an identifier. In general, avoid one-character names unless one character is idiomatic (for example, prefer index over i, but prefer x over horizontalPosition)

Good:

for(int i = 0; i < 5; i++){
   for(int j = 0; j < 5; j++){
   }
}
double latitude = 50.0;
double longitude = 50.0;

Bad:

for(int index = 0; index < 5; index++){
  for(int innerIndex = 0; innerIndex < 5; innerIndex++){
  }
}
double lat = 50.0;
double long = 50.0;

Avoid anonymous parameter names

Provide full type information and names even for parameters that are otherwise unused.

Good:

onTapDown: (TapDownDetails details) { print('hello!'); },

Bad:

onTapDown: (_) { print('good bye'); }, // BAD

Naming rules for typedefs and function variables

When naming callbacks, use FooCallback for the typedef, onFoo for the callback argument or property, and handleFoo for the method that is called. If you have a callback with arguments but you want to ignore the arguments, give the type and names of the arguments anyway. That way, if someone copies and pastes your code, they will not have to look up what the arguments are. Never call a method onFoo. If a property is called onFoo it must be a function type. (For all values of "Foo".)

Spell words in identifiers and comments correctly

Our primary source of truth for spelling is the Material Design Specification. Our secondary source of truth is dictionaries. Avoid "cute" spellings. For example, 'colors', not 'colorz'. Prefer US English spellings. For example, 'colorize', not 'colourise', and 'canceled', not 'cancelled'. Prefer compound words over "cute" spellings to avoid conflicts with reserved words. For example, 'classIdentifier', not 'klass'.

Capitalize identifiers consistent with their spelling

If a word is correctly spelled (according to our sources of truth as described in the previous section) as a single word, then it should not have any inner capitalization or spaces.

For examples, prefer toolbar, scrollbar, but appBar ('app bar' in documentation), tabBar ('tab bar' in documentation). Similarly, prefer offstage rather than offStage. Avoid starting class names with iOS since that would have to capitalize as Ios which is not how that is spelled. (Use "Cupertino" or "UiKit" instead.)

Good:

String toolbar;
String scrollbar;
String offstage;

Bad:

String toolBar;
String scrollBar;
String offStage;

Boolean Variables

Name your boolean variables in positive ways, such as "enabled" or "visible", even if the default value is true.

This is because, when you have a property or argument named "disabled" or "hidden", it leads to code such as input.disabled = false or widget.hidden = false when you’re trying to enable or show the widget, which is very confusing.

Good:

if (socket.isConnected && database.hasData) {
  socket.write(database.read());
}

Bad:

if (!socket.isDisconnected && !database.isEmpty) {
  socket.write(database.read());
}

Variables and methods for debugging

If you have variables or methods (or even classes!) that are only used in debug mode, prefix their names with debug or _debug (or, for classes, _Debug). Do not use debugging variables or methods (or classes) in the production code.