A guide to Dart coding styles

Dart Coding Style Guide

This guide was written by Bob Nystrom in August 2011 (updated in February 2015)

When we build a Dart coding system, it's important to use a consistent coding style. This tutorial is a well-written Dart Style Guide designed to help you understand the unique features of the language and make collaboration between Dart developers easier.

Maybe there's something in this tutorial that you don't agree with. E ven as an author, there are some things I don't agree with. So, I hope readers will agree that consistency is generally far more valuable than personal preferences.

For many things, such as Dart, tutorials are not rigid, and it's important to keep that in mind. A s language develops, we will learn a lot from it, and our coding style will change. T his is where code that doesn't follow the latest style is inevitable, or it's also because there's a sense of axiality in the guide or something that doesn't cover it that causes the reader to write the code to his or her own preferences. These omissions also invite readers to join us in taking on the responsibility that our guide will get better as Dart and his library stabilize.

You can also look at the documentation:

• API Naming Guide
• Guidelines for Doc Comments

How to read this guide

This guide is roughly divided into several sections in order from macro to micro. E ach section contains a series of guidelines. Each guideline includes the following words:

• Do - The guidelines describe practices that should always be followed. You can hardly find a reason not to follow these practices.
• Don't do it - these guidelines are the opposite: what's described in this section is often not a good choice. A fter reading this guide, you will notice that there is a lot of content in this piece. S uch guidelines in other languages help avoid errors over time. The Dart language is a new language, and when we use Dart, we can fix these traps directly without always being careful.
• Best of all -- these are the practices you should follow. B ut in some cases it would be better to do other things. You just need to understand the implications, and when you actually do, you should ignore them.
• Avoid - This is the opposite of the "best": in general you shouldn't do it, but in rare cases it's a good choice.
• Consider - These may be guidelines that you don't want to follow, and for these guidelines, you can consider the specifics, some precedents, and even your personal preferences before deciding whether to follow them.

After reading all of the above, you may feel defeated by the coding style if you don't have some preparation. D on't worry, most of the guidelines in this guide are common sense, and we're all wise people. Our ultimate goal is to write beautiful, highly readable, highly maintained code.