Vorwort:
Der Codierungsstil einer Programmiersprache ist für eine langfristige Wartungssoftware, insbesondere in der Teamarbeit, sehr wichtig. Wenn ein Team einen einheitlichen und standardisierten Codierungsstil verwendet, kann es das Zusammenarbeit und die Arbeitseffizienz des Teams verbessern. Im Zentrum des Programmierstil-Handbuchs befinden sich grundlegende Formatierungsregeln, die bestimmen, wie Code auf hohem Niveau geschrieben wird. Dieser Leitfaden stammt aus dem Buch "Writing Wardable JavaScript", basierend auf den "Java -Sprachcodierungsspezifikationen" und Crockfords JavaScript -Programmierspezifikationen sowie einigen persönlichen Erfahrungen und Vorlieben von Nicbolas. Der Zweck des Schreibens dieses Artikels ist es, Ihren Eindruck zu vertiefen und mehr Menschen den JS -Codierungsstil zu verstehen und ihre Codierungsqualität zu verbessern. Für weitere Informationen lesen Sie bitte "Wartbares JavaScript schreiben".
1. Einzug
Die Ebene jeder Zeile besteht aus 4 Leerzeichen, wodurch die Einklebung unter Verwendung der Registerkarte vermieden wird.
// gute Schreibmethode if (true) {dosomething ();}2. Länge der Zeile
Jede Zeile sollte 80 Zeichen nicht überschreiten. Wenn eine Zeile 80 Zeichen überschreitet, sollte sie nach einem Bediener unterbrochen werden. Die nächste Zeile sollte zwei Stufen von Eindrückung (8 Zeichen) hinzufügen.
// gute Schreibmethode Dosen (Argument1, Argument2, Aegment3, Argument4, Argument5); // Schlechte Schreibmethode: Eingeklagte Dosen (Argument1, Argument2, Aegment3, Argument4, Argument5);
3. Originalwert
Saiten sollten immer doppelte Zitate verwenden und eine Zeile aufbewahren, um zu vermeiden, dass Schrägstriche eine Zeile in der Zeichenfolge starten.
Zahlen sollten Dezimalzahlen verwenden, und wissenschaftliche Algorithmen repräsentieren Ganzzahlen, hexadezimale Ganzzahlen oder Dezimalerdezimalstellen. Mindestens eine Zahl sollte vor und nach der Dezimalzahl beibehalten werden. Vermeiden Sie die Verwendung von Octal -direkten Mengen.
Sonderwert Null sollte außer in den folgenden Fällen vermieden werden.
• Wird verwendet, um eine Variable zu initialisieren, der einem Objekt einen Wert zugewiesen werden kann.
• Wird verwendet, um mit einer initialisierten Variablen zu vergleichen, die ein Objekt sein kann oder nicht.
• Wenn erwartet wird, dass der Parameter einer Funktion ein Objekt ist, wird er als Parameter übergeben.
• Wenn erwartet wird, dass der Rückgabewert der Funktion ein Objekt ist, wird er als Rückgabewert ohnmächtig.
Vermeiden Sie die Verwendung von nicht definierten speziellen Werten. Um festzustellen, ob eine Variable definiert ist, sollte der Typof -Operator verwendet werden.
4. Operatorabstand
Vor und nach dem binären Budget muss ein Raum genutzt werden, um den Ausdruck ordentlich zu halten. Zu den Betreibern gehören Zuordnungsoperatoren und logische Operatoren.
// Gutes Schreiben für (var i = 0; i <count; i ++) {prozess (i);} // schlechtes Schreiben: Lost Space for (var i = 0; i <count; i ++) {prozess (i);}5. Klammerabstand
Bei der Verwendung von Klammern sollte unmittelbar nach der linken Halterung und unmittelbar vor der engen Halterung kein Platz vorhanden sein.
// Gutes Schreiben für (var i = 0; i <count; i ++) {prozess (i);} // schlechtes Schreiben: Es gibt zusätzliche Räume auf beiden Seiten des Parameters für (var i = 0; i <count; i ++) {prozess (i);};};};};6. Direkte Objektmessung
Die direkte Menge des Objekts sollte das folgende Format haben.
• Die starteten linken Zahnspangen sollten auf derselben Linie wie der Ausdruck gehalten werden.
• Der Namenswert jedes Attributs sollte eingerichtet werden, und das erste Attribut sollte nach der linken lockigen Klammer eine neue Zeile sein.
• Der Namenswert jedes Attributs sollte ohne Zitate verwendet werden, gefolgt von einem Dickdarm (vor dem Raum), gefolgt von einem Wert.
• Wenn der Attributwert ein Funktionstyp ist, sollte die Funktionsbehörde eine neue Zeile unter dem Attributnamen starten, und eine leere Zeile sollte vor und danach beibehalten werden.
• Leere Zeilen können vor und nach einer Reihe verwandter Eigenschaften eingefügt werden, um die Lesbarkeit des Codes zu verbessern.
• Die rechte Endklammer sollte ausschließlich eine Linie besetzen.
// Good writing method var object = { key1: value1, key2: value2, func: function() { // doSomeThing }, key3: value3};// Bad writing method: inappropriate indentation var object = { key1: value1, key2: value2 };// Bad writing method: lack of blank lines around the function body var object = { key1: value1, key2: value2, func: function() { // dosomething}, key3: value3};Wenn das Objektliteral als Funktionsparameter verwendet wird, sollten sich die Startsproces auf derselben Zeile wie der Funktionsname befinden. Alle anderen zuvor aufgeführten Regeln gelten ebenfalls.
// gute Schreibmethode dosomething ({key1: value1, key2: value2}); // Schlechte Schreibmethode: Alle Codes doomting ({key1: value1, key2: value2});7. Kommentare
Mit prägnanten und klaren Kommentaren kann anderen helfen, Ihren Code zu verstehen. Kommentare sollten in folgenden Situationen verwendet werden.
• Der Code ist dunkel.
• Codes, die mit dem Fehler verwechselt werden können.
• notwendiger, aber nicht offensichtlicher Browser-spezifischer Code.
• Für Objekte, Methoden oder Eigenschaften ist es erforderlich, Dokumente zu generieren (unter Verwendung geeigneter Dokumentenkommentare).
Einzelzeilenkommentare
Einzelzeilen-Kommentare sollten verwendet werden, um eine Codezeile oder eine Reihe verwandter Codes zu veranschaulichen. Möglicherweise gibt es drei Möglichkeiten, Single-Line-Kommentare zu verwenden.
• Exklusive Kommentare, um die nächste Codezeile zu erklären.
• Kommentare am Ende der Codezeile, um den Code zuvor zu erklären.
• Mehrere Zeilen, um einen Codeblock zu kommentieren.
// Gutes Schreiben if (Bedingung) {// Wenn der Code hier ausgeführt wird, bedeutet dies, dass alle Sicherheitsprüfungen bestanden wurden;} // schlechtes Schreiben: Es gibt keine leere Zeile vor dem Kommentar, wenn (Bedingung) {// Wenn der Code hier ausgeführt wird, bedeutet dies, dass alle Sicherheitsüberprüfungen bestanden wurden. Multi-Line-Kommentare sollten verwendet werden // Dieses Code-Stück wird für ** Urteilsvermögen verwendet // Wenn (Bedingung) {// Wenn der Code hier ausgeführt wird, bedeutet dies, dass alle Sicherheitsprüfungen bestanden wurden;} // Gutes Schreiben: Wenn Sie am Ende der Zeile kommentieren, sollte ein Speicherplatz zwischen dem Ende des Codes und dem Kommentar, wenn (Bedingung) {// //, wenn der Code hier ausgeführt wurde, (). // Führen Sie die ** Funktion aus} // schlechtes Schreiben aus: Es gibt nicht genügend Leerzeichen zwischen dem Code und dem Kommentar, wenn (Bedingung) {// Wenn der Code hier ausgeführt wird, bedeutet dies, dass alle Sicherheitsprüfungen übergeben wurden (); // Führen Sie die ** Funktion aus} // Gutes Schreiben aus: Wenn Sie einen Codeblock aus Kommentar abgeben, sollten Sie sich an einen einzigen Zeilenkommentar wenden, und in diesem Fall sollten keine Mehrzeilen-Kommentare verwendet werden. // if (Bedingung) {// erlaubt (); // execute ** Funktion //}Multi-Line-Kommentare
Multi-Line-Kommentare sollten verwendet werden, wenn der Code mehr Text benötigt, um zu interpretieren. Jeder mehrzeilige Kommentar enthält mindestens drei Zeilen wie folgt:
1. Die erste Zeile enthält nur den Start /* Kommentar. In dieser Zeile sollte es keinen anderen Text geben.
2. Die folgenden Zeilen beginnen mit * und bleiben links ausgerichtet. Diese können in Worten beschrieben werden.
3. Die letzte Zeile beginnt mit */ und bleibt mit der vorherigen Zeile ausgerichtet. Es sollte keinen anderen Text geben.
Die erste Zeile eines multi-line-Kommentars sollte dieselbe Einklingelgrenze beibehalten, wie er den Code beschreibt. Jede nachfolgende Linie sollte die gleiche Einklingelgrad und einen angeschlossenen Raum haben (um die * Zeichen ordnungsgemäß ausgerichtet zu halten). Eine leere Zeile sollte vor jedem Multi-Line-Code reserviert werden.
// gute Schreibmethode, wenn (Bedingung) {/** Wenn der Code hier ausgeführt wird* Dies bedeutet, dass alle Sicherheitserkennungen übergeben wurdenKommentaranweisung
Kommentare können manchmal verwendet werden, um zusätzliche Informationen für einen Code zu deklarieren. Das Format dieser Aussagen beginnt mit einem einzigen Wort und folgt sofort von einem Dickdarm. Die Aussagen, die verwendet werden können, sind wie folgt.
TODO: Der Beschreibung Code ist noch nicht abgeschlossen. Es sollte enthalten, was Sie als nächstes tun möchten.
Hack: Es zeigt, dass die Code -Implementierung eine Abkürzung angenommen hat. Sollte Gründe, warum Hacks verwendet werden. Dies kann auch darauf hinweisen, dass das Problem eine bessere Lösung für das Problem geben kann.
XXX: Erklären Sie, dass der Code problematisch ist und so bald wie möglich behoben werden sollte.
FixMe: Erklären Sie, dass der Code problematisch ist und so bald wie möglich behoben werden sollte. Es ist etwas zweiter zu xxx.
Überprüfung: Anweisungscodes müssen in möglichen Änderungen überprüft werden.
Diese Erklärungen können in einem oder mehreren Kommentaren verwendet werden und sollten dieselben Formatierungsregeln wie der allgemeine Kommentartyp befolgen.
8. Benennung
Variablen und Funktionen sollten bei der Benennung vorsichtig sein. Die Benennung sollte auf numerische alphabetische Zeichen beschränkt sein, und in einigen Fällen können Unterstriche (_) verwendet werden. Es ist am besten, das Dollar -Schild ($) oder den Backslash (/) in keiner Namen zu verwenden.
Die variable Benennung sollte im Kamel -Namensformat mit dem ersten Buchstabengebietsbuch und dem ersten Buchstaben jedes Wortes Großbuchstaben erfolgen. Das erste Wort des Variablennamens sollte ein Substantiv (kein Verb) sein, um Verwirrung mit derselben Funktion zu vermeiden. Verwenden Sie keine Unterstriche in Variablennamen.
// gute Schreibmethode var accountNumber = "test001"; // Schlechte Schreibmethode: Starten Sie mit Großbuchstaben var AccountNumber = "test001"; // Schlechte Schreibmethode: Starten Sie mit Verb var getAccountNumber = "test001"; // Schlechte Schreibmethode: Verwenden Sie Unterscore var account_number = "test001";
Funktionsnamen sollten auch im Kamel -Namensformat vorliegen. Das erste Wort des Funktionsnamens sollte ein Verb (kein Substantiv) sein, um Verwirrung mit derselben Variablen zu vermeiden. Es ist am besten, Unterstriche in Funktionsnamen nicht zu verwenden.
// gute Schreibmethodenfunktion DOSOMETHET () {// Code} // Schlechte Schreibmethode: Funktion dosomething () {// Code} // Schlechte Schreibmethode: Funktion etwas () {// Code} // Schlechte Schreibmethode: Verwenden Sie die Untersteuerungsfunktion do_something () {// Code}Der Konstruktor - eine Funktion, die ein neues Objekt über den neuen Bediener erstellt - sollte auch im Kamelformat benannt werden und der erste Charakter wird aktiviert. Der Konstruktorame sollte mit einem nonverb beginnen, da neu die Funktionsweise der Erstellung einer Instanz eines Objekts darstellt.
// gute Schreibmethodenfunktion MyObject () {// Code} // Schlechte Schreibmethode: Funktion myObject () zu Beginn von Kleinbuchstaben {// Code} // Schlechte Schreibmethode: Verwenden Sie Unterscore -Funktion my_object () {// Code} // Schlechte Schreibmethode: Funktion am Anfang von verb -getMyobject () {// code}}Der Name von Konstanten (Variablen, deren Werte nicht geändert werden) sollte alle Großbuchstaben sein, die durch einen einzelnen Unterstrich zwischen verschiedenen Wörtern getrennt sind.
// gute Schreibmethode var total_count = 10; // Schlechte Schreibmethode: Camel Form var TotalCount = 10; // Schlechte Schreibmethode: gemischte Form var total_count = 10;
Die Attribute von Objekten entsprechen den Variablen. Die Methoden von Objekten sind die gleichen wie die von Funktionen. Wenn die Eigenschaft oder Methode privat ist, sollte ein Unterstrich vor ihr hinzugefügt werden.
// Gute Schreibmethode var Object = {_count: 10,4 _getCount: function () {return this._count; }}9. Variable und Funktionserklärungen
Variable Deklaration
Alle Variablen sollten vor dem Gebrauch im Voraus definiert werden. Variable Definitionen sollten am Anfang der Funktion unter Verwendung einer VAR -Expression eine Variable pro Zeile platziert werden. Mit Ausnahme der ersten Zeile sollten alle Zeilen um eine weitere Ebene eingerückt werden, damit die Variablennamen vertikal ausgerichtet werden können. Variablendefinitionen sollten initialisiert werden und Zuordnungsoperatoren sollten eine konsistente Einkerbung aufrechterhalten. Die initialisierte Variable sollte sein, bevor die Variable initialisiert wird.
// gute Schreibmethode var count = 10, name = "jeri", gefunden = false, leer;
Funktionserklärung
Funktionen sollten vor dem Gebrauch im Voraus definiert werden. Eine Funktion, die keine Methode ist (dh kein Attribut als Objekt), sollte das durch die Funktion definierte Format verwenden (nicht das Funktions- und Funktionskonstruktor -Format). Es sollte keinen Platz zwischen dem Funktionsnamen und den Start -Klammern geben. Ein Raum sollte zwischen den Endklammern und den lockigen Klammern rechts gelassen werden. Die lockigen Zahnspangen auf der rechten Seite sollten in derselben Zeile wie das Schlüsselwort der Funktion bleiben. Es sollte keinen Platz zwischen Start- und Endklammern geben. Nach einem Komma zwischen Parameternamen sollte ein Raum übrig bleiben. Der Funktionskörper sollte auf der ersten Ebene eingerückt bleiben.
// gute Schreibmethodenfunktion ober () {var count = 10, name = "jeri", found = false, leer; Funktion Inner () {// Code} // Code, der inner ()} aufruftAnonyme Funktionen können Objekten als Methoden oder als Parameter anderer Funktionen zugewiesen werden. Es sollte keinen Platz zwischen dem Schlüsselwort für Funktion und der Starthalterung geben.
// Gutes Schreiben von Methodenobjekt.Method = function () {// code}; // Schlechte Schreibmethode: Falsch Space Object.method = function () {// Code};Die sofort genannte Funktion sollte in Gartenhalterungen auf der äußeren Schicht des Funktionsaufrufs eingewickelt werden.
// gute Methode var value = (function () {// Funktion Körperrückgabe {message: "hi"}} ());Strenger Modus
Der strenge Modus sollte nur innerhalb von Funktionen verwendet werden und darf weltweit nicht verwendet werden.
// schlechte Schreibmethode: Verwenden Sie den strengen Modus "Verwenden Sie streng"; Funktion dosomething () {// Code} // gute Schreibmethode Funktion dosomething () {"Strict verwenden"; // Code}10. Betreiber
Abtretung
Wenn eine Variable einen Wert zugewiesen wird und die rechte Seite ein Ausdruck ist, der eine Vergleichserklärung enthält, muss er in Klammern eingewickelt werden.
// Gutes Schreiben var flag = (i <count); // schlechtes Schreiben: fehlende Klammern var flag = i <count;
Gleicher Zeichenoperator
Verwenden Sie === (streng gleich) und!
// Gutes Schreiben var gleich = (a === b); // Gutes Schreiben var gleich = (a == b);
Dreifachbetreiber
Der ternäre Operator sollte nur in bedingten Zuweisungsanweisungen verwendet werden und nicht als Ersatz für wenn Aussagen verwendet werden.
// gute Schreibmethode var value = Bedingung? Wert1: Wert2; // Schlechte Schreibmethode: Keine Zuordnung, wenn der Ausdruck verwendet werden sollte? dosomething (): doomethingelse;
11. Aussage
Einfache Aussage
Jede Zeile enthält höchstens eine Anweisung. Alle einfachen Aussagen sollten mit einem Semikolon enden (;).
// gute Schreibmethode zählen ++; a = b; // schlechte Schreibmethode: Mehrere Ausdrücke sind in einer Zeilenzahl ++ geschrieben; a = b;
Rückgabeerklärung
Rückgabeanweisungen sollten bei der Rückgabe eines Wertes nicht in Klammern verpackt werden, es sei denn, dies kann in einigen Fällen den Rückgabewert erleichtern. Zum Beispiel:
return; return collection.size (); return (Größe> 0? Größe: defaultSize);
Zusammengesetzte Aussagen
Eine zusammengesetzte Aussage ist eine Liste von Aussagen, die in Zahnspangen eingeschlossen sind.
• Die beigefügte Aussage sollte mehr als die zusammengesetzte Aussage eingesetzt werden.
• Die Anfangsspangen sollten sich am Ende der Linie befinden, an der sich die zusammengesetzte Aussage befindet. Die Endsprocen sollten eine Linie einnehmen und genauso wie der Beginn der zusammengesetzten Aussage eingewiesen bleiben.
• Wenn eine Aussage Teil einer Kontrollstruktur ist, z. B. wenn oder für Aussagen, müssen alle Aussagen in Zahnspangen eingeschlossen sein, einschließlich einer einzelnen Anweisung. Diese Konvention erleichtert es uns, Anweisungen hinzuzufügen, ohne sich Sorgen darüber zu machen, dass sie das Hinzufügen von Klammern und das Verursachen von Fehler.
• Die Schlüsselwörter für eine Erklärung, wie er starten sollte, gefolgt von einem Raum, und auf die Startspangen sollten von einem Raum folgen.
wenn Anweisung
Die IF -Anweisung sollte im folgenden Format sein.
if (Bedingung) {Anweisungen} if (Bedingung) {Anweisungen} else {Anweisungen} if (Bedingung) {Anweisungen} else if (Bedingung) {Anweisungen} else {Anweisungen}Es darf niemals lockige Klammern in Ifs -Aussagen weglassen.
// Gutes Schreiben if (Bedingung) {dosomething ();} // schlechtes Schreiben: Unangemessene Räume if (Bedingung) {doSomething ();} // schlechtes Schreiben: Alle Code befindet sich in einer Zeile, wenn (Zustand) {doSomething (); } // schlechtes Schreiben: Alle Code befindet sich in einer Zeile und es gibt keine lockigen Klammern, wenn (Bedingung) etwas doomt ();Für Erklärung
Für Typanweisungen sollte im folgenden Format stattfinden.
für (Initialisierung; Bedingung; Update) {Anweisungen} für (Variable in Object) {Anweisungen}Der Initialisierungsteil der für die Anweisung sollte keine variablen Erklärungen aufweisen.
// gute Methode var i, len; für (i = 0, len = 0; i <len; i ++) {// Code} // Schlechtes Schreiben: Deklare Variable für (var i = 0, len = 0; i <len; i ++) {// Code} // schlechtes Schreiben: Variable für (var prop in Object) {// Code}}}Denken Sie bei Verwendung der For-In-Anweisung daran, HasownProperty () zum Doppelkontrollen zu verwenden, um die Mitglieder des Objekts zu filtern.
Während der Aussage
Die Aussagen der while -Klasse sollten im folgenden Format sein.
while (Bedingung) {Anweisungen}Aussage machen
Aussagen der DO -Klasse sollten im folgenden Format sein.
do {Anweisungen} while (Bedingung);Schaltanweisung
Die Aussagen der Switch -Klasse sollten im folgenden Format enthalten sein.
Switch (Ausdruck) {Fallausdruck: Anweisungen Standard: Anweisungen}Der erste Fall unter dem Switch sollte eingerichtet werden. Jeder Fall außer dem ersten, einschließlich Standard, sollte eine leere Zeile vor diesem Fall behalten.
Jeder Satz von Anweisungen (außer Standard) sollte mit einer Pause, zurückkehren, werfen oder mit einer Reihe von Kommentaren übersprungen werden.
// Gute Schreibmethode Switch (Wert) {Fall 1:/ * fällt durch */ case 2: dosenthing (); brechen; Fall 3: Return True; Standard: Werfen Sie einen neuen Fehler ("ein Fehler");}Wenn eine Switch -Anweisung keinen Standardfall enthält, sollte eine Kommentarzeile ersetzt werden.
// Gute Schreibmethode Switch (Wert) {Fall 1:/ * fällt durch */ case 2: dosenthing (); brechen; Fall 3: Return True; Standard: // no Standard}Versuchen Sie es mit Anweisung
Die Aussagen der Try -Klasse sollten wie folgt formatiert werden.
try {Anweisungen} catch (variable) {Anweisungen} try {Anweisungen} catch (variable) {Anweisungen} Schließlich {Anweisungen}12. Weißen lassen
Das Hinzufügen leerer Codezeilen zwischen dem logischbezogenen Code kann die Lesbarkeit des Codes verbessern.
Zwei leere Linien sind in den folgenden Situationen beschränkt:
• Zwischen verschiedenen Quellcodedateien.
• Zwischen Klassen- und Schnittstellendefinitionen.
Einzelzeilen leere Zeilen sind nur in den folgenden Fällen erhältlich.
• Zwischen Methoden.
• Zwischen der lokalen Variablen in der Methode und der ersten Linienanweisung.
• Vor mehreren oder einzelnen Zeilenkommentaren.
• Die logischen Codeblöcke in der Methode werden verwendet, um die Lesbarkeit des Codes zu verbessern.
In den folgenden Situationen sollten Räume verwendet werden.
• Der Fall, in dem Schlüsselwörter von Klammern folgen, sollte durch Leerzeichen getrennt werden.
• Ein Raum sollte nach einem Komma in der Parameterliste gelassen werden.
• Die Operanden aller binären Operatoren mit Ausnahme von Punkten (.) Sollten durch Leerzeichen getrennt werden. Die Operanden von Monologischen Operatoren sollten nicht durch Leerzeichen wie Unarm minus Zeichen, Inkrement (++), Dekrement (-) getrennt werden.
• Die Ausdrücke der für die für die Aussage durch Räume getrennte Aussagen.
13. Was muss vermieden werden
• Erstellen Sie keine neuen Objekte mit Original -Wrapper -Typen wie String.
• Vermeiden Sie die Verwendung von Eval ().
• Vermeiden Sie die Verwendung mit Aussagen. Diese Aussage ist im strengen Modus nicht mehr vorhanden und kann auch in zukünftigen ECMascript -Standards entfernt werden.
Am Ende geschrieben
Die oben genannten Führer werden während des Entwicklungsprozesses nicht vollständig verfolgt. Wir können nur einige von ihnen zeichnen, um unseren Codierungsstil zu verbessern und unseren Code lesbar und wartbar zu machen. In Bezug auf den Codierungsstil hat jedes Team seine eigenen Eigenschaften. Solange das Team konsistent ist, ist es in Ordnung, sich effizient zu entwickeln. Einige Regeln sind nicht etwas, dem wir ständig gehorchen müssen. Beispielsweise verwenden wir in Bezug auf die Eindringung häufig den Registerkartenschlüssel, um bequemer zu sein, aber wir können nicht garantieren, dass die Tabulatoren 4 Leerzeichen in jeder Umgebung darstellt. Um die Konsistenz in der Eindrücke aufrechtzuerhalten, muss er während des gesamten Prozesses verwendet werden, wenn der TAB -Schlüssel verwendet wird. Und wir müssen auch nicht "" und "" verwenden, und es ist auch möglich zu verwenden ", solange Sie einen konsistenten Stil beibehalten. Es gibt viele ähnliche Stilprobleme, die alle auf der persönlichen Wahl beruhen.
Es gibt keine absoluten Regeln, nur geeignet oder nicht.