Statische Analyse

Die statische Analyse ist eine Art von Tests, mit der Sie Ihre ohne ihn tatsächlich auszuführen oder einen automatisierten Test schreiben zu müssen. Sie haben Diese Art von Tests haben Sie wahrscheinlich bereits gesehen, wenn Sie eine IDE wie VSCode Die von TypeScript durchgeführte Überprüfung ist eine Art statische Analyse. Sie kann unter Fehlern oder Warnungen.

ESLint

ESLint ist ein Tool, das Feedback zu möglichen Problemen Codebasis. Diese Probleme sind zwar typsicher,aber Fehler oder nicht standardmäßiges Verhalten auf sich aufmerksam zu machen. Mit ESLint können Sie eine Reihe von Regeln anwenden, Ihre Codebasis, darunter viele in der festgelegt.

Ein gutes Beispiel für eine ESLint-Regel ist no-unsafe-finally Regel. Dies verhindert, dass Sie Aussagen schreiben, die den Code Ihres Programms verändern. Ablauf innerhalb eines finally-Blocks steuern. Das ist eine gute Regel, ist eine ungewöhnliche Methode zum Schreiben von JavaScript-Code, der mitunter schwer zu verstehen ist. Es ist jedoch auch etwas, das ein guter Codeüberprüfungsprozess erkennen sollte.

  try {
    const result = await complexFetchFromNetwork();
    if (!result.ok) {
      throw new Error("failed to fetch");
    }
  } finally {
    // warning - this will 'overrule' the previous exception!
    return false;
  }

Daher ist ESLint kein Ersatz für einen guten Überprüfungsprozess in dem definiert wird, wie Ihre Codebasis aussehen soll, um jeden unorthodoxen Ansatz zu erfassen, den ein Entwickelnde einzuführen versuchen könnte. in Ihre Codebasis integrieren. Der Leitfaden zur Entwicklung von Google-Richtlinien enthält einen kurzen Abschnitt, in dem es darum geht, die Sicherheit möglichst einfach zu halten.

Mit ESLint können Sie gegen eine Regel verstoßen und Code als „zulässig“ annotieren. Zum Beispiel haben Sie können Sie die vorherige Logik zulassen, indem Sie sie wie folgt annotieren:

  finally {
    // eslint-disable-next-line no-unsafe-finally
    return false;
  }

Wenn Sie ständig gegen eine Regel verstoßen, sollten Sie sie deaktivieren. Diese Tools ermutigen Sie, Code auf eine bestimmte Weise zu schreiben, aber Ihr Team könnte dazu beitragen, anders zu schreiben und sich der Risiken bewusst zu sein, Ansatz.

Schließlich könnte das Aktivieren statischer Analysetools auf einer großen Codebasis viel nicht hilfreichen Rauschen (und Refaktorierungsarbeit) statt Code, der ansonsten funktioniert hat, in Ordnung. So ist es einfacher, frühzeitig im Lebenszyklus eines Projekts zu aktivieren.

ESLint-Plug-ins für Browserunterstützung

Sie können ESLint ein Plug-in hinzufügen, das die Verwendung weniger weit verbreiteter APIs kennzeichnet. unterstützt bzw. nicht von der Liste des Zielbrowsers unterstützt wird. Die eslint-plugin-compat kann Sie warnen, wenn eine API für Ihre Nutzer möglicherweise nicht verfügbar ist, sodass Sie Sie müssen nicht ständig alles selbst im Blick behalten.

Typprüfung für statische Analysen

Beim Erlernen von JavaScript wird neuen Entwicklern in der Regel die Idee vorgestellt, dass die Sprache schlecht geschrieben ist. Das heißt, es ist möglich, als einen Typ verwenden, und dann denselben Speicherort für etwas unterscheiden. Dies ähnelt Python und anderen Skriptsprachen, kompilierten Sprachen wie C/C++ und Rust.

Diese Formulierung könnte für den Einstieg geeignet sein – und sie ist wohl so, und Einfachheit, die JavaScript so beliebt gemacht hat – aber oft ist es ein Point of Failure. oder zumindest für etwas, das verwirrende Fehler nicht passieren kann. Wenn Sie beispielsweise einen number übergeben, wobei ein string oder ein Objekttyp erwartet wurde, kann ein falsch eingegebener Wert und führt schließlich zu einem verwirrenden TypeError.

TypeScript

TypeScript ist die gängigste Lösung für den Mangel an Tippen in JavaScript. Informationen. In diesem Kurs wird sie ausgiebig verwendet. Und obwohl dies kein Kurs TypeScript verwenden, kann ein wichtiger Teil Ihrer Toolbox sein, statische Analyse.

Ein Beispiel: Dieser Code, der erwartet, dass er einen Callback erhält, der einen Name für string und Alter von number:

const callback = (name: string, age: string): void => {
  console.info(name, 'is now', age, 'years old!');
};
onBirthday(callback);

Erzeugt den folgenden Fehler, wenn er über TypeScript ausgeführt wird oder wenn der Mauszeiger darauf bewegt wird in einer IDE:

bad.ts:4:12 - error TS2345: Argument of type '(name: string, age: string) => void' is not assignable to parameter of type '(name: string, age: number) => void'.
  Types of parameters 'age' and 'age' are incompatible.
    Type 'number' is not assignable to type 'string'.

4 onBirthday(callback);
             ~~~~~~~~

Found 1 error in bad.ts:4
<ph type="x-smartling-placeholder">
</ph> Der Code aus der vorherigen Beispiel in einer IDE mit der Fehlermeldung Pop-up-Fenster.
Der VSCode gibt an, dass Sie einen falschen Typ
.

Letztendlich besteht das Ziel von TypeScript darin, Fehler wie diesen zu vermeiden: Das Alter sollte number sein, kein string – schleichend in Ihr Projekt ein. Dieses Mit anderen Arten von Tests kann es schwierig sein, eine Art von Fehler zu erkennen. Außerdem kann das Typsystem Feedback geben, noch bevor ein Test geschrieben wird. Dies erleichtert Ihnen das Schreiben von Code, da Sie frühzeitig Feedback geben. zu Typfehlern bei der Softwareentwicklung und nicht, wenn der Code ausgeführt wird.

Die größte Herausforderung bei der Verwendung von TypeScript ist die korrekte Einrichtung. Jeden Projekt benötigt eine tsconfig.json-Datei, die zwar hauptsächlich vom tsc verwendet wird Befehlszeilentool selbst, wird auch von IDEs wie VSCode und vielen anderen Build-Tools und -Tools, einschließlich Vitest. Diese Datei enthält Hunderte von Optionen und Flags. Nützliche Ressourcen zur Einrichtung finden Sie hier:

Allgemeine Tipps zu TypeScript

Wenn Sie TypeScript über eine tsconfig.json-Datei einrichten und verwenden, im Hinterkopf:

  • Achten Sie darauf, dass Ihre Quelldateien tatsächlich enthalten und überprüft sind. Wenn eine Datei "keine Fehler enthält", liegt das wahrscheinlich daran, dass sie gerade nicht überprüft wird.
  • Die explizite Beschreibung von Typen und Schnittstellen in .d.ts-Dateien, anstatt implizit beschrieben werden, während Sie Funktionen schreiben, kann Ihr einfacher zu testen. Es ist einfacher, Mocks und Fälschungen zu schreiben Versionen von wenn die beteiligten Schnittstellen eindeutig sind. .

TypeScript implizit alle

Eine der leistungsstärksten und lohnendsten Konfigurationsoptionen von TypeScript ist die Flag noImplicitAny. Es ist aber auch oft am schwierigsten, vor allem, wenn Sie bereits eine große Codebasis haben. (Das Flag noImplicitAny ist standardmäßig aktiviert, wenn Sie sich im strict-Modus befinden, andernfalls nicht.

Durch dieses Flag wird die Funktion einen Fehler zurückgeben:

export function fibonacci(n) {
  if (n <= 1) {
    return 0;
  } else if (n === 2) {
    return 1;
  }
  return fibonacci(n - 1) + fibonacci(n - 2);
}

Für Leser ist es jedoch ziemlich klar, dass n eine Zahl sein sollte, TypeScript kann dies nicht zuverlässig bestätigen. Wenn Sie VSCode verwenden, bewegen Sie den Mauszeiger beschreibt die Funktion dies wie folgt:

function fibonacci(n: any): any

Aufrufer dieser Funktion können einen Wert vom Typ any übergeben. (ein Typ, der jeden anderen Typ zulässt), nicht nur number. Wenn Sie die Funktion noImplicitAny können Sie diese Art von Code während der Entwicklung schützen. ohne umfangreiche Geschäftslogiktests für Ihren Code schreiben zu müssen an bestimmten Stellen falsche Datentypen verwenden.

Die einfache Lösung besteht darin, sowohl das Argument n als auch den Rückgabetyp von fibonacci als number zu markieren.

Das Flag noImplicitAny verhindert nicht, dass Sie any explizit in Ihre Codebasis zu verbessern. Sie können trotzdem eine Funktion schreiben, die den Typ any. Es wird lediglich sichergestellt, dass jeder Variablen ein Typ zugewiesen wird.