Basically, code as described in the [Effective Dart Style guide](https://www.dartlang.org/guides/language/effective-dart/style).

> **Note:** We have pretty strict linter rules that are also shown in VS Code and validated when opening a PR. They help you write readable and uniform code :)

Here are some amendments specific to this project:

## Imports

There are basically 3 types of imports that should be organized into four distinct groups, separated by a newline:

* Dart-Imports like `import 'dart:ui';`.
* Package imports like `import 'package:flutter/flutter.dart';` or imports of other modules like `import 'package:schulcloud/app/app.dart';`.
* Imports of files in the same module. To make the code more succinct, these should be relative imports like `import '../bloc.dart';`

<details>
<summary>Example</summary>

```dart
import 'dart:math';

import 'package:flutter/material.dart';
import 'package:provider/provider.dart';
import 'package:schulcloud/app/app.dart';

import '../model.dart';
import 'article_image.dart';
import 'article_screen.dart';
import 'section.dart';
import 'theme.dart';
```

</details>

## Visibility

Only make stuff non-private if it's accessed outside of the file.

<details>
<summary>Example</summary>

```dart
class _SampleWidgetState extends State<SampleWidget> {
  void _counter = 0;

  Widget build(BuildContext context) {...}

  void _countUp() => setState(() => _counter++);
}
```

</details>

## Unused parameters

If arguments to a function are not used by that function, they can be named `_` (an underscore), `__` (two underscores) etc., to indicate to the reader that their value is not relevant.

<details>
<summary>Example</summary>

```dart
StreamBuilder<Update>(
  stream: /* ... */,
  builder: (_, snapshot) => MyWidget(snapshot),
)
```

</details>

## Widgets

The widget tree in the `build` function should not contain any closures that are longer than one line (or are similarly simple). Rather, move these functions out into a new method that has a descriptive name. That helps readers of the `build` method to quickly understanding the action without interrupting their flow (they're probably trying to figure out how the widget tree is built, not what happens if an action is taken).

If the widget tree gets very deep, consider two options:

* If there are parts of the widget tree that don't need to rebuild if the whole widget rebuilds, consider refactoring them to standalone widgets.
* Otherwise, consider defining helper methods (descriptively named `_buildButton`) for parts of the tree.

### The order of functions

This should be the order of functions in a widget (note some of them are optional):

* `initState`
* `didChangeDependencies`
* `dispose`
* `build`
* helper functions used in `build`
* helper `build`-functions (`_build...`)

<details>
<summary>Example</summary>

```dart
// (inside a [StatelessWidget] or the [State] of a [StatefulWidget])

Widget build(BuildContext context) {...}
void startSleeping() { /* ... */ }
void eat(Banana banana) { /* ... */ }

Widget _buildHeader(BuildContext context, int someData) { /* ... */ }
void _onHeaderClicked() { /* ... */ }
```

</details>