In den letzten fünf Jahren habe ich ständig versucht, meine Programmierfähigkeiten zu verbessern, und eine davon war das Erlernen und Befolgen der am häufigsten empfohlenen Programmierstile.
Dieser Leitfaden soll Ihnen beim Schreiben konsistenten und eleganten Codes helfen und enthält einige Ratschläge zur Verbesserung der Lesbarkeit und Wartbarkeit des Codes. Es ist von den in der Community am häufigsten akzeptierten Richtlinien inspiriert, weist jedoch einige Änderungen auf, um besser zu meinen Vorlieben zu passen.
Es ist erwähnenswert, dass ich ein Full-Stack-JavaScript-Entwickler bin und alle meine Notizen spezifisch für meinen Tech-Stack (MEVN) sind und möglicherweise nicht auf andere Stacks anwendbar sind.

Allgemeine Regeln

Vermeiden Sie Codeduplizierung

Wenn derselbe Codeblock (oder mit einigen überschaubaren Unterschieden) an mehr als einer Stelle geschrieben werden muss, ist es wesentlich, sie in einer Funktion zusammenzuführen und die Funktion anschließend jederzeit aufzurufen benötigt.

Ziehen Sie eine lose Kopplung in Betracht

Funktionen sollten unabhängig voneinander funktionieren, was bedeutet, dass die Bearbeitung einer Funktion absolut keine Auswirkungen auf die anderen haben sollte, solange die Eingaben und Ausgaben gleich bleiben. Jede Funktion sollte keine Kenntnis der Definitionen der anderen haben und als separate Komponente arbeiten. In dieser Situation kennt es nur seine Parameter, und egal wer die Funktion aufruft, dieselben Eingaben liefern immer dieselben Ergebnisse.

Erklärung

Denken Sie zuallererst daran, die Variablen ständig zu deklarieren.
Verwenden Sie das Schlüsselwort const, wenn eine Variable nicht neu zugewiesen werden soll. Sie können const jedoch weiterhin für Variablen verwenden, die Objekte oder Arrays sind, auch wenn Sie planen, deren verschachtelte Elemente neu zuzuweisen.
Bitte beachten Sie, dass Module erforderlich sind und konstante Variablen immer mit dem Schlüsselwort const definiert werden müssen.
Verwenden Sie das Schlüsselwort let, wenn Sie const nicht verwenden können, und verwenden Sie das Schlüsselwort var nur, wenn Sie ältere Browser unterstützen müssen.

Funktionen

Funktionen sollten auf Folgendes beschränkt sein:

• Vier Variablen
• Vier Parameter
• Dreißig Codezeilen (Kommentare werden ignoriert)
• Vier Zweige (if-else, while, for, or-and, switch-case)

Codezeilen sollten auf 100 Zeichen begrenzt sein, und um die Funktionen zu gruppieren/organisieren, ist es besser, die verwandten Funktionen so nah wie möglich beieinander zu halten.
Bevorzugen Sie die Pfeilfunktionssyntax wann immer möglich gegenüber der herkömmlichen Alternative.

Saiten

Verwenden Sie einfache Anführungszeichen ' (anstelle von doppelten Anführungszeichen ") für die gewöhnlichen Zeichenfolgenliterale, aber für Zeichenfolgen mit eingebetteten Variablen/Ausdrücken, mehrzeiligen Zeichenfolgen und Zeichenfolgen, die einfache Anführungszeichen enthalten, verwenden Sie Vorlagenliterale.

Benennung

Es ist wichtig, bei der Benennung von Variablen auf Konsistenz zu achten. Das heißt, wenn Variablen auf verschiedenen Seiten für dieselben Daten verantwortlich sind, sollten sie denselben Namen haben.

Die Namen von Variablen, Funktionen, Methoden und Parametern sollten selbsterklärend sein, was bedeutet, dass jeder allein durch einen Blick auf die Namen in der Lage sein sollte, die enthaltenen Daten zu erkennen (oder zumindest eine faire Vermutung anzustellen).

Konstante Variablen sollten in Großbuchstaben geschrieben werden, wobei die Wörter durch Unterstriche getrennt sein sollten. Funktionen, Variablen und Methoden sollten der CamelCase-Syntax folgen, während CSS-Klassen und IDs der Kebab-Case-Syntax folgen sollten.

Kommentare

Kommentare sollten immer mit einem Großbuchstaben beginnen und auf 100 Zeichen begrenzt sein. Sie erinnern sich vielleicht, dass die Codezeilen derselben Regel folgen würden. Beachten Sie jedoch, dass Zeilen, die beides enthalten, nur maximal 150 Zeichen lang sein dürfen.
Kommentare, die die Funktionen beschreiben, sollten nicht dort geschrieben werden, wo sie aufgerufen werden, sondern dort, wo sie definiert sind.

Platzieren Sie die Kommentare nach den einzeiligen Codes, es sei denn, die Länge der Zeile überschreitet 150 Zeichen. Platzieren Sie in solchen Fällen und bei mehrzeiligen Codes die Kommentare oben.

Bei den if-Anweisungen sollten die Kommentare nach den bedingten Anweisungen platziert werden.

if (conditionIsTrue) { // Put your comment here
    doSomeThing();
} else { // Put your comment here
    doSomethingElse();
}

Denken Sie daran, doppelte Schrägstriche // für einzeilige Kommentare und /* */ für mehrzeilige Kommentare zu verwenden. Wenn Sie mehrzeilige Kommentare zu einzeiligem Code oder bedingten Anweisungen hinzufügen, platzieren Sie diese innerhalb von /* */, sodass /* vor dem Code geschrieben wird, der Kommentar in der folgenden Zeile beginnt und */ in eine neue Zeile geschrieben wird Linie.

if (conditionIsTrue) { /*
        Put your comment here
        Put your comment here
    */
    doSomeThing();
}

functionName(parameter), /*
    Put your comment here
    Put your comment here
*/

Funktionsbeschreibende Kommentare

Platzieren Sie die Kommentare über den von /** */ umschlossenen Funktionen.

• Beschreiben Sie Parameter mithilfe der Variablennamenbeschreibung von @param {type}.
• Wenn der Parameter mehr als den Typ einer Variablen akzeptieren könnte, verwenden Sie @param {type1 | Typ2} ​​Variablenname Beschreibung.
• Wenn der Parameter optional ist und fehlen könnte, verwenden Sie @param {type} [variableName] Beschreibung.
• Wenn der Parameter einen Standardwert hat (er muss optional sein, um tatsächlich einen Standardwert zu haben), verwenden Sie die Beschreibung @param {type} [variableName="value"].
• Beschreiben Sie die Funktionsausgabe mit der Beschreibung @returns {type}.

/**
 * Describing the function here
 * @param {type} normalVariable A normal variable
 * @param {type1 | type2} multiTypeVariable A variable with multiple expected types
 * @param {type} [variableWithDefaultValue="value"] An optional variable that has a default value in case of being absent when calling the function 
 * @param {type} [optionalVariable] An optional variable
 * @returns {type} description
*/
const functionName = (normalVariable, multiTypeVariable, variableWithDefaultValue, optionalVariable) => {
    doSomeThing();
}

Bezüglich Serverfunktionen mit req- und res-Parametern besteht keine Notwendigkeit, Anforderungsparameter zu beschreiben. Beschreiben Sie die Antwort nur mit @returns description.

/**
 * Describing the function here
 * @returns description
 */
functionName = (req, res) => {
    doSomeThing();
}

Im Allgemeinen besteht keine Notwendigkeit, die Parameter „req“, „res“, „next“, „to“ und „from“ zu beschreiben.

Verwenden Sie in HTML-Dateien , um verschiedene Teile des Codes zu trennen; Daher konnte der Benutzer jedes Teil leicht identifizieren.

Falls Sie Kommentare in die Mitte einer Codezeile schreiben, verwenden Sie /* */.

const calc_result = (firstNumber * secondNumber)/* Explain the reason for the multiplication */   thirdNumber;

Vertiefung

Nachgestellte Leerzeichen sind verboten.
Denken Sie daran, Ausdrücke, Operatoren und Symbole immer mit Leerzeichen zu umgeben und auch nach Kommas und geschweiften Klammern, wenn diese nicht die letzten Zeichen der Zeile sind.
Leerzeilen sind nur am Ende der Datei (alle Dateien sollten in einer leeren Zeile enden), nach dem letzten importierten Modul, zwischen Template-, Skript- und Style-Tags und zwischen CSS-Regelsätzen zulässig (und erforderlich).
Denken Sie daran, die Tabulatortaste zum Einrücken und die Leertaste zum Ausrichten zu verwenden.

Befehl

• Ordnen Sie die Variablen der Mongoose-Schemata und den Vue Reactive State der Komponenten in alphabetischer Reihenfolge, aber für den Rest der Zeit ordnen Sie die Zeilen von der kürzesten zur längsten.
• Ordnen Sie die Routenmethoden in der Reihenfolge „Put“, „Get“, „Post“ und „Delete“ an, während jede einzelne in alphabetischer Reihenfolge ist und alle Routen basierend auf ihren URLs gruppiert werden sollten.

Zusammenfassung

Obwohl dies natürlich nicht die besten Ratschläge aller Zeiten sind, glaube ich, dass sie einen soliden Ausgangspunkt für jeden bieten, der daran interessiert ist, die Prinzipien sauberen Codes zu erlernen.
Darüber hinaus mag die strikte Einhaltung dieser Regeln zunächst schwierig erscheinen, mit der Übung wird sie jedoch viel einfacher.

Es ist wichtig, die Notwendigkeit zu betonen, sich bei der Arbeit an einer langfristigen Codebasis an die Richtlinien des aktuellen Projekts zu halten, auch wenn diese unzureichend sind. Wenn Sie es ernst meinen mit der Überarbeitung der Projektrichtlinien, ziehen Sie die vorteilhaftesten Änderungen in Betracht und lassen Sie sie nach und nach in das Projekt einfließen.

Cover-Bildnachweis: Foto von Luis Gomes von Pexels