Freiheit stirbt mit Sicherheit
Dart Effective Dart
Dart Effektiver Dat
Bevorstehende Änderungen am Verlauf
Der Übersetzungsverlauf steht bald nur noch zur Verfügung,wenn du angemeldet bist. Er wird dann zentral ueber Meine Aktivitäten verwaltet. Der bisherige Verlauf wird durch
dieses Upgrade gelöscht. Speichere also Uebersetzungen, auf die du später noch zugreifen möchtest.
In den letzten Jahren
haben wir eine Menge Dart-Code geschrieben
und viel darüber gelernt, was gut funktioniert und was nicht. Wir teilen dies mit Ihnen,
damit Sie auch konsistenten, robusten und schnellen Code schreiben können.
Es gibt zwei übergeordnete Themen: Seien Sie konsequent. Wenn es um Dinge wie Formatierung und Gehäuse geht,
sind Argumente, die besser sind, subjektiv und unmöglich zu lösen. Was wir wissen ist, dass es objektiv
hilfreich ist, konsequent zu sein. Wenn zwei Codeteile unterschiedlich aussehen, sollte dies daran liegen,
dass sie sich auf sinnvolle Weise unterscheiden. Wenn ein bisschen Code auffällt und auffällt, sollte dies aus einem
nützlichen Grund geschehen. Fasse dich kurz. Dart wurde so konzipiert, dass es vertraut ist,
und erbt daher viele der gleichen Anweisungen und Ausdrücke wie C, Java, JavaScript und andere Sprachen.
Aber wir haben Dart entwickelt, weil es viel Raum gibt, das Angebot dieser Sprachen zu verbessern.
Wir haben eine Reihe von Funktionen hinzugefügt, von der Zeichenfolgeninterpolation bis zur Initialisierung von Formalen,
damit Sie Ihre Absicht einfacher und einfacher ausdrücken können. Wenn es mehrere Möglichkeiten gibt, etwas zu sagen, sollten Sie im Allgemeinen die prägnanteste auswählen.
Dies bedeutet nicht, dass Sie Golf so programmieren sollten, dass ein ganzes Programm in einer einzigen Zeile
zusammengefasst wird. Das Ziel ist Code, der wirtschaftlich und nicht dicht ist. Der Dart-Analysator verfügt über einen Linter, mit dem Sie guten, konsistenten Code schreiben können.
Wenn eine Linter-Regel vorhanden ist, mit deren Hilfe Sie einer Richtlinie folgen können,
wird die Richtlinie mit dieser Regel verknüpft. Hier ein Beispiel:
Linter-Regel: Prefer_Collection_Literals
Hilfe zum Aktivieren von Linter-Regeln finden Sie in der Dokumentation
zum Anpassen der statischen Analyse. Die Führer Wir haben die Richtlinien zur leichteren Verdauung in einige separate Seiten aufgeteilt:
Style Guide - Hier werden die Regeln für das Layout und die Organisation von Code definiert
oder zumindest die Teile, die dartfmt für Sie nicht verarbeitet. Der Styleguide gibt auch an,
wie Bezeichner formatiert werden: camelCase, using_underscores usw.
Dokumentationshandbuch - Hier erfahren Sie alles, was Sie über Kommentare wissen müssen. Sowohl Dokumentkommentare als auch normale Codekommentare. Verwendungshandbuch - Hier erfahren Sie, wie Sie Sprachfunktionen optimal nutzen, um Verhalten zu implementieren. Wenn es sich um eine Aussage oder einen Ausdruck handelt, wird hier darauf eingegangen. Design Guide - Dies ist der weichste Leitfaden, aber der mit dem größten Umfang. Es behandelt, was wir über das Entwerfen konsistenter, verwendbarer APIs für Bibliotheken gelernt haben. Wenn es sich um eine Typensignatur oder -deklaration handelt, wird dies überprüft. Links zu allen Richtlinien finden Sie in der Zusammenfassung. Wie man die Anleitungen liest Jede Anleitung ist in einige Abschnitte unterteilt. Abschnitte enthalten eine Liste von Richtlinien. Jede Richtlinie beginnt mit einem dieser Wörter: DO-Richtlinien beschreiben Praktiken, die immer befolgt werden sollten. Es wird fast nie einen triftigen Grund geben, von ihnen abzuweichen. NICHT Richtlinien sind das Gegenteil: Dinge, die fast nie eine gute Idee sind. Hoffentlich haben wir nicht so viele davon wie andere Sprachen, weil wir weniger historisches Gepäck haben. PREFER-Richtlinien sind Praktiken, die Sie befolgen sollten. Es kann jedoch Umstände geben, unter denen es sinnvoll ist, etwas anderes zu tun. Stellen Sie einfach sicher, dass Sie die vollständigen Auswirkungen des Ignorierens der Richtlinie verstehen, wenn Sie dies tun. Vermeiden Sie Richtlinien, die Sie bevorzugen sollten: Dinge, die Sie nicht tun sollten, für die es jedoch in seltenen Fällen gute Gründe geben kann. BEACHTEN Sie Richtlinien, die Sie je nach Umständen, Präzedenzfällen und Ihren eigenen Vorlieben möglicherweise befolgen möchten oder nicht. Einige Richtlinien beschreiben eine Ausnahme, bei der die Regel nicht gilt. Wenn sie aufgelistet sind, sind die Ausnahmen möglicherweise nicht erschöpfend. Möglicherweise müssen Sie Ihr Urteil in anderen Fällen noch anwenden. Das hört sich so an, als würde die Polizei Ihre Tür einschlagen, wenn Sie Ihre Schnürsenkel nicht richtig gebunden haben. Die Dinge sind nicht so schlimm. Die meisten Richtlinien hier sind vernünftig und wir sind alle vernünftige Leute. Das Ziel ist wie immer netter, lesbarer und wartbarer Code. Glossar Um die Richtlinien kurz zu halten, verwenden wir einige Kurzbegriffe, um auf verschiedene Dart-Konstrukte zu verweisen. Ein Bibliotheksmitglied ist ein Feld, ein Getter, ein Setter oder eine Funktion der obersten Ebene. Grundsätzlich alles auf der obersten Ebene, was kein Typ ist. Ein Klassenmitglied ist ein Konstruktor, ein Feld, ein Getter, ein Setter, eine Funktion oder ein Operator, die innerhalb einer Klasse deklariert sind. Klassenmitglieder können instanziell oder statisch, abstrakt oder konkret sein. Ein Mitglied ist entweder ein Bibliotheksmitglied oder ein Klassenmitglied. Eine Variable bezieht sich, wenn sie allgemein verwendet wird, auf Variablen, Parameter und lokale Variablen der obersten Ebene. Es enthält keine statischen oder Instanzfelder. Ein Typ ist eine beliebige benannte Typdeklaration: eine Klasse, ein Typedef oder eine Aufzählung. Eine Eigenschaft ist eine Variable der obersten Ebene, Getter (innerhalb einer Klasse oder auf der obersten Ebene, Instanz oder statisch), Setter (gleich) oder Feld (Instanz oder statisch). Etwa jedes "feldartig" benannte Konstrukt. Zusammenfassung aller Regeln