Comments and Code Style

A comment is a note for humans; Dart ignores it.

// A single-line comment

/* A block comment,
   rarely used in Dart */

final taxRate = 0.2; // a comment after code

Documentation comments

Comments starting with /// document the declaration below them. Editors show them on hover, and dart doc turns them into a documentation website. Square brackets link to other names:

/// Returns [price] with 20% tax added.
///
/// Throws an [ArgumentError] if [price] is negative.
double withTax(double price) {
  if (price < 0) throw ArgumentError.value(price, 'price');
  return price * 1.2;
}

What to comment

Clear names explain what code does. Comments are for why:

// Bad: repeats the code
count++; // increase count

// Good: explains a non-obvious reason
// The API numbers pages from 1, so shift our 0-based index.
final page = index + 1;

Dart's tools do the style work

• dart format . formats every file to the one official style. Most editors run it on save.
• dart analyze reports errors and lint warnings — rules from the lints package (or flutter_lints), configured in analysis_options.yaml.
• dart fix --apply automatically fixes many lint issues.

The official Effective Dart guide (on dart.dev) explains the conventions: lowerCamelCase names, UpperCamelCase types, prefer final, and so on.

What's next

You now know enough Dart to build real programs. Try the Beginner Projects, then continue to Level 2 — Intermediate, which starts with classes.