Style Guides

Search…
🦮
Style Guides
[Ed.] I have placed some @@@ in the text where I need Nathan's input. You can easily search for "@@@" to find them.
General Coding Conventions
The concentions in this section apply to all languages and scripts used in the AppFlowy project. You will find specifications for each language below, if applicable.
Formatting
Instead, formatting should be done using ./x.py fmt. It's a good habit to run ./x.py fmt before every commit, as this reduces conflicts later.
Copyright notice
In the past, files began with a copyright and license notice. Please omit this notice for new files licensed under the standard terms (dual MIT/Apache-2.0).
Line length
Lines should be at most 120 characters. It's even better if you can keep things to 80.
Ignoring the line length limit. Sometimes – in particular for tests – it can be necessary to exempt yourself from this limit. In that case, you can add a comment towards the top of the file like so:
Coding for correctness
Beyond formatting, there are a few other tips that are worth following.
Prefer exhaustive matches
Using _ in a match is convenient, but it means that when new variants are added to the enum, they may not get handled correctly. Ask yourself: if a new variant were added to this enum, what's the chance that it would want to use the _ code, versus having some other treatment? Unless the answer is "low", then prefer an exhaustive match. (The same advice applies to if let and while let, which are effectively tests for a single variant.)
Use "TODO" comments for things you don't want to forget
TODOs are a very useful tool to remind yourself of bits while working on a feature. We recommend that you insert a TODO comment for something that you want to get back to before you submit your PR.
TODOs are to be used locally while working on a feature and must be dealt with and removed before checking in the code.
1
fn do_something() {
2
  if something_else {
3
    unimplemented!(); // TODO write this
4
  } 
5
} 
Copied!
These are very practical and you can see a list of them in the VS Code 'Problems' tab.
Naming conventions
Classes, enums, typedefs, and extensions name should be in UpperCamelCase.
1
class HomeLayout
2
​
3
enum IntegrationEnv {
4
  dev,
5
  pro,
6
}
7
​
8
typedef NaviAction = void Function();
Copied!
Libraries, packages, directories, and source files name should be in snake_case(lowercase_with_underscores).
1
library firebase_dynamic_links;
2
import ‘socket/socket_manager.dart’;
Copied!
Variables, constants, parameters, and named parameters should be in lowerCamelCase.
1
var item;
2
​
3
const testValue = 14.28;
4
​
5
final urlScheme = RegExp(‘^([a-z]+):’);
6
​
7
void sum(int testValue) {…}
Copied!
Variables
@@@ Nathan FooWe have to choose one of these two ideologies. Me, personally, I'm a type who writes the types. It makes the code easier to understand. I know that the newer mentality is to not have them because the compiler can figure it out. But where I disagree is that just because the compiler can figure it out, I don't see why we should make the next programmer have to figure it out. We'll do whatever you want :)
Specify types for class members
Always specify the type of a member when it’s value type is known. Avoid using var when possible.
1
int item = 10;
2
final User user = User();
3
String name = ‘pooja’;
4
const int timeOut = 20;
Copied!
1
sum(int testValue) { // …}
Copied!
Variables
DO follow a consistent rule for var and final on local variables. Most local variables shouldn’t have type annotations and should be declared using just var or final. There are two rules in wide use for when to use one or the other:
Use final for local variables that are not reassigned and var for those that are.
Use var for all local variables, even ones that aren’t reassigned. Never use final for locals. (Using final for fields and top-level variables is still encouraged, of course.)
Either rule is acceptable, but pick one and apply it consistently throughout your code. That way when a reader sees var, they know whether it means that the variable is assigned later in the function.
Use Cascade Notation @@@I think this applies to both Rust and Dart
__Cascade notation allows you to perform a sequence of operations on the same object. It saves your number of steps and needs for a temporary variable.
1
Demo d1 = new Demo();
2
Demo d2 = new Demo();
3
​
4
// Don't - Without Cascade Notation
5
d1.setA(20);
6
d1.setB(30);
7
d1.showVal();
8
​
9
​
10
// Do - With Cascade Notation
11
d2..setA(10)
12
  ..setB(15)
13
  ..showVal();
Copied!
Use expression function bodies @@@ Nathan FooI think this applies to both Rust and Dart
For functions that contain just one expression, you can use an expression function. The => (arrow) notation is used for expression functions.
1
num get x => center.x;
2
​
3
set x(num value) => center = Point(value, center.y);
Copied!
Utilities
Place reusable functions in a class, so it's easy to access them. Also, For Dialog components, if you are using a package to wrap their logic with your own custom widget, so it would be easy to change the package if necessary later.
Remove Unused Resources
Especially when you are ready to push your changes, you’ll need to remove resources that aren't used in the application. These could be image assets, for example. Removing unused resources and compressing images will help us reduce the size of the application.
Maintain hard-coded values, strings, colors in a separate file
Create a separate file to store strings, colors, constants. so it’s easy to access them.
colors.dart
Rust Coding Conventions
Using crates from crates.io
It is allowed to use crates from crates.io, though external dependencies should not be added gratuitously. All such crates must have a suitably permissive license.
Flutter/Dart Coding Conventions
Strings
PREFER using interpolation to compose strings and values.
Generally, we are used to using long chains of + to build a string out of literals and other values. That does work in Dart, but it’s almost always cleaner and shorter to use interpolation:
1
// Do
2
​
3
'Hello, $name! You are ${year - birth} years old.';
Copied!
AVOID using curly braces in interpolation when not needed.
If you’re interpolating a simple identifier not immediately followed by more alphanumeric text, the {} should be omitted.
1
// Don't
2
​
3
'Hello, ' + name + '! You are ' + (year - birth).toString() + ' years old.';
Copied!
Don't use new
Dart 2 makes the new keyword optional. Even in Dart 1, its meaning was never clear because factory constructors mean a new invocation may still not actually return a new object.
The language still permits new in order to make migration less painful, but consider it deprecated and remove it from your code.
1
//Do
2
Widget build(BuildContext context) {
3
  return Row(
4
    children: [
5
      RaisedButton(
6
        child: Text('Increment'),
7
      ),
8
      Text('Click!'),
9
    ],
10
  );
11
}
12
​
13
//Don't
14
Widget build(BuildContext context) {
15
  return new Row(
16
    children: [
17
      new RaisedButton(
18
        child: new Text('Increment'),
19
      ),
20
      new Text('Click!'),
21
    ],
22
  );
23
 }
Copied!
Use if condition instead of conditional expression
Many times we need to render a widget based on some condition in Row and Column. If conditional expression return null in any case then we should use the if condition only.
1
//Don't
2
Widget getText(BuildContext context) {
3
  return Row(
4
    children: [
5
      Text("Hello"),
6
      Platform.isAndroid ? Text("Android") : null,
7
    ]
8
  );
9
}
10
​
11
​
12
//Do
13
Widget getText(BuildContext context) {
14
  return Row(
15
    children:
16
      [
17
        Text("Hello"),
18
        if (Platform.isAndroid) Text("Android")
19
      ]
20
  );
21
}
Copied!
Avoid large widget trees
Split your code into smaller widgets instead. Dividing your code into small reusable widgets not only promotes its reusability but also its readability.
In the example below, EventItem is a separate widget that will load individual events. EventItem is usually stored in a separate file.
1
itemBuilder: (ctx, i) => ChangeNotifierProvider.value(
2
  value: events[i],
3
  child: EventItem(),
4
 ),
Copied!
Const Widgets
Whenever you have widgets that don’t change when the state changes, you should declare them as constants. This will prevent them from being rebuilt, hence improving performance.
This is similar to caching widgets that won’t get rebuilt. Some of the widgets that can be declared as const include Text, Padding, and Icons, to mention a few. If the widgets contain dynamic information, they shouldn’t be declared as constants.
Usage of const
Use Trailing Commas
Since your widget tree can grow quickly, you need a way to format your code in a way that makes it easy to read. Adding trailing commas and using your IDE’s formatting shortcuts leads to more readablility.
Usage of traiing commas
Render Grids and Lists Lazily
Use the lazy methods, with callbacks, when building large grids or lists. That way only the visible portion of the screen is built at startup time.
Some ways to lazy load data
- FutureBuilder
- lazy_load_scrollview package
Flutter Analyze
It’s important to check the code with the analyzer. Run flutter analyze in your terminal to check your code. This tool is a wrapper around the dartanalyzer tool. It performs static analysis of your code.
1
flutter analyze
Copied!
Note that the Continious Integration tasks will run flutter ananlyze on your PRs and will refuse tasks with warnings or errors.
Flutter Pub Version Checker (Android Studio Plugin)
@@@ Is there a VS Code version o this? More importantly, what's our procedure? Do only you upgrage the versions?
Plugin for checking the latest Pub packages versions. It will automatically run inspection in your pubspec.yaml file to check all dependencies and compare versions with the latest versions from the Pub package repository. The highlighted ones need an update.
pubspec.yaml
Custom Error Screen: handle “RED SCREEN OF DEATH”
Use ErrorWidget that renders an exception’s message. This widget is used when a build method fails, to help determine where the problem lies. Exceptions are also logged to the console, which you can read using flutter logs. The console will also include additional information such as the stack trace for the exception.
It is possible to override this widget. Refer to this article for more information.
1
import 'package:flutter/material.dart';
2
void main() {
3
  ErrorWidget.builder = (FlutterErrorDetails details) {
4
    bool inDebug = false;
5
    assert(() { inDebug = true; return true; }());
6
    // In debug mode, use the normal error widget which shows
7
    // the error message:
8
    if (inDebug)
9
      return ErrorWidget(details.exception);
10
    // In release builds, show a yellow-on-blue message instead:
11
    return Container(
12
      alignment: Alignment.center,
13
      child: Text(
14
        'Error!',
15
        style: TextStyle(color: Colors.yellow),
16
        textDirection: TextDirection.ltr,
17
      ),
18
    );
19
  };
20
  // Here we would normally runApp() the root widget, but to demonstrate
21
  // the error handling we artificially fail:
22
  return runApp(Builder(
23
    builder: (BuildContext context) {
24
      throw 'oh no, an error';
25
    },
26
  ));
27
}
Copied!
__