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
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:
- Was ist eine tsconfig.json-Datei?
- Zentrale Empfehlungen für TypeScript-Basis
- JS mit Fehlerbehebung prüfen
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.