Our Coding Standard for Dart/Flutter

To make things more uniform across all our repositories containing Dart/Flutter code we will abide by a coding standard

A nice thing about Dart is that it comes with a auto formatter and code analysis tool

dartfmt and dartanalyze

In your IDE be sure that auto-format on save is enabled, so that dartfmt will be automatically run any time you save a file. We will also adhere to the recommended 80 character line limit that is enforced by dartfmt. We might increase this limit in our IDEs if we agree on a longer limit.

Analysis

In VS Code there is a tab at the bottom called PROBLEMS. If you click on it, it will show a list of all problems in your files. The problems are not necessarily logical problems, just a list of guidelines to make your code more readable, and adhere to the standard.

Analysis 'lints' the files checking for any issues, and displays them in the problems tab. You can also see this issues with a little blue squiggle under them in the editor. Hovering over them in the editor will show the issue that it found. Some errors can be corrected automatically. Just click ctrl-. to see the fix, and apply it if you see it. However, some problems must be corrected manually. Please do that. After making the edits the issue should go away.

Creating a new project

When creating a new project, be sure to copy the analysis_options.yaml over from one of the existing projects to set up the code standard lints.

Make sure to add the project to the melos.yaml in saywer_ws

Updating the lints

If dart updates their linter to add new rules we will need to choose whether they are rules we would like to enable or not. My recommendation is to enable more rather than fewer.

To see the full current list of lint_rules see this reference

Add any new rules to the analysis_options.yaml in sawyer_ws, and then run ./update_analysis.sh.