Привет, если вы на пути изучения Flutter/Dart или вам просто интересно почитать про путь изучения, подписывайтесь на мой канал в telegram, буду рад вас видеть! А сегодня поговорим про руководство по эффективному Dart!

За последние несколько лет мы написали тонну кода для Dart и многое узнали о том, что работает хорошо, а что нет. Мы делимся этим с вами, чтобы вы тоже могли писать согласованный, надежный и быстрый код. Есть две общие темы:

1. Будьте последовательны. Когда дело доходит до таких вещей, как форматирование и оболочка, споры о том, что лучше, субъективны и неразрешимы. Что мы знаем точно, так это то, что быть последовательным объективно полезно.

   Если два фрагмента кода выглядят по-разному, это должно быть связано с тем, что они отличаются каким-то значимым образом. Когда фрагмент кода выделяется и привлекает ваше внимание, это должно быть сделано по полезной причине.

2. Будьте кратки. Dart был разработан так, чтобы быть знакомым, поэтому он наследует многие из тех же инструкций и выражений, что и C, Java, JavaScript и другие языки. Но мы создали Dart, потому что есть много возможностей для улучшения того, что предлагают эти языки. Мы добавили множество функций, от интерполяции строк до формализации инициализации, чтобы помочь вам выразить свои намерения более просто и непринужденно.

   Если есть несколько способов что-то сказать, вам, как правило, следует выбрать наиболее краткий. Это не означает, что вы должны самостоятельно code golf, втискивая целую программу в одну строку. Цель - экономичный, а не плотный код.

Руководство

Мы разделили рекомендации на несколько отдельных страниц для удобства восприятия:

• Руководство по стилю – здесь определяются правила размещения и систематизации кода или, по крайней мере, те части, которые формат dart для вас не обрабатывает. В руководстве по стилю также указано, как форматируются идентификаторы: camelCase, using_underscores и т.д.

• Руководство по документации (скоро) – в нем рассказывается все, что вам нужно знать о том, что содержится внутри комментариев. Как комментарии к документам, так и обычные комментарии к коду.

• Руководство по использованию (скоро) – здесь вы узнаете, как наилучшим образом использовать языковые возможности для реализации поведения. Если это указано в инструкции или выражении, это описано здесь.

• Руководство по дизайну (скоро) – это самое простое руководство, но с самым широким охватом. В нем рассказывается о том, что мы узнали о разработке согласованных, пригодных для использования API-интерфейсов для библиотек. Если это указано в сигнатуре типа или объявлении, это не имеет значения.

P.S. по мере публикаций остальных руководств, будут добавляться ссылки

Как читать руководство

Каждое руководство разбито на несколько разделов. Разделы содержат список рекомендаций. Каждое руководство начинается с одного из этих слов:

• DO описывают ли рекомендации методы, которым всегда следует следовать. Почти никогда не будет веской причины отклоняться от них.

• DON’T рекомендации - это обратное: то, что почти никогда не бывает хорошей идеей. Надеюсь, у нас их не так много, как в других языках, потому что у нас меньше исторического багажа.

• PREFER рекомендации - это практика, которой вы должны следовать. Однако могут возникнуть обстоятельства, при которых имеет смысл поступить иначе. Просто убедитесь, что вы понимаете все последствия игнорирования руководства, когда будете это делать.

• AVOID рекомендации - это двойственное выражения PREFER: то, что вам не следует делать, но в редких случаях для этого могут быть веские причины.

• CONSIDER рекомендации - это практика, которой вы могли бы следовать, а могли бы и не следовать, в зависимости от обстоятельств, прецедентов и ваших собственных предпочтений.

В некоторых рекомендациях описываются исключения, когда правило неприменимо. Перечисленные исключения могут не быть исчерпывающими - возможно, вам все равно придется использовать свое суждение в других случаях.

Это звучит так, как будто полиция собирается выбить вашу дверь, если вы неправильно завязали шнурки. Все не так уж плохо. Большинство приведенных здесь рекомендаций основаны на здравом смысле, а мы все разумные люди. Цель, как всегда, - приятный, читаемый и поддерживаемый код.

Анализатор Dart предоставляет компоновщик, который поможет вам написать хороший, согласованный код, соответствующий этим и другим рекомендациям. Если существует одно или несколько правил компоновки, которые могут помочь вам следовать руководству, то в руководстве содержатся ссылки на эти правила. Ссылки имеют следующий формат:

Правило Линтера: unnecessary_getters_setters

Чтобы узнать, как использовать линтер, смотрите раздел Включение правил линтера и список правил линтера

Глоссарий

Чтобы сделать руководство кратким, мы используем несколько сокращенных терминов для обозначения различных конструкций Dart.

• Library member - это поле верхнего уровня, получатель, установщик или функция. В принципе, все, что находится на верхнем уровне и не является типом.

• Class member - это конструктор, поле, получатель, установщик, функция или оператор, объявленные внутри класса. Члены класса могут быть экземплярами или статическими, абстрактными или конкретными.

• Member - это либо член библиотеки, либо член класса.

• Variable, при общем использовании, относится к переменным верхнего уровня, параметрам и локальным переменным. Она не включает статические поля или поля экземпляра.

• Type - это любое объявление именованного типа: class, typedef или enum.

• Property - это переменная верхнего уровня, getter (внутри класса или на верхнем уровне, экземпляр или статический), setter (то же самое) или field (экземпляр или статический). Примерно любая "field-like” именованная конструкция.