Gibt es einen Fachbegriff für Live Codeüberprüfung?

[new Account()]

...
Selbst, wenn man Beispiele nennt, glaubt ihrs nicht

Hier nochmal die konkrete Beschreibung eines Plugins:
https://plugins.jetbrains.com/plugin/8143-cppcheck

Features:

• Runs cppcheck on the fly while you write code

Hier auch nochmal Von Der Funktionalität, die out of the box ist:
https://www.jetbrains.com/clion/features/code-analysis.html

On-the-fly analysis
CLion constantly monitors your code for potential errors. If it finds anything, it highlights the suspicious piece of code in the editor. If you look in the right-hand editor gutter, you will see yellow and red error strips that, if clicked, navigate you to the detected issues. Another way to navigate from one highlighted issue to another is by pressing F2/Shift+F2. The status indicator at the top of the gutter summarizes the file status.

In addition to finding compilation errors, CLion identifies code inefficiencies and even performs data flow analysis over your code to locate unreachable/unused code, as well as other issues and 'code smells':

[...]

CLion comes with the Clang-Tidy integration. Clang-Tidy checks are shown the same way as CLion’s own built-in code inspections, and quick-fixes are also available via Alt+Enter.

https://clang.llvm.org/extra/clang-tidy/

clang-tidy is a clang-based C++ “linter” tool. Its purpose is to provide an extensible framework for diagnosing and fixing typical programming errors, like style violations, interface misuse, or bugs that can be deduced via static analysis.

Ich frage mich gerade echt, ob ihr programmiert, und falls doch, ob es nicht vielleicht Sinn Machen würde vom Editor zu einer guten IDE zu wechseln.

Ergänzung (24. September 2019)

Ja Resharper. Das kommt noch auf mich zu im Bereich C#.

Definitiv eine Empfehlung wert.
Der Produktivitätsboost ist auch bei C# imho nicht zu verachten.
Wobei Visual studio mittlerweile einige Features bekommen hat, die vorher nur Resharper mitbrachte - zumindest laut Der Build.
Deswegen bin ich nicht ganz auf dem aktuellen Stand.

Ergänzung (24. September 2019)

, das ist kein effizientes Entwickeln mehr wenn ich wegen Komma-Fehlern und diesem krankhaften Escapen via `" und ' und vielleicht dann einmal mit Backslashes einmal ohne Backslashes und einmal dürfens keine Back sondern Frontslashes (/) sein.

hast du schon mal Powershell ISE getestet? Zumindest ein paar Syntaxfehler werden (im Rahmen einer statischen Analyse) angezeigt.

 

[andy_m4]

Ich glaube es schon. :-)

Ich sag nur, das tiefergehende Analysen halt schwierig sind.
Ich kenn' das ja auch, das viele Fehler gefunden werden. Nichtsdestotrotz bleiben immer noch Fehler übrig, wie erst bei einem Compilerdurchlauf sichtbar werden.
Und so ein Full-Compile ist halt in C++ extrem aufwendig. Klar kann man auch dort tricksen mit Background-compilation und der Editor weiß ja auch, wo gerade wasgeändert wird und kann daher theoretisch gewisse Eingrenzungen vornehmen. Nichts desto trotz hat das Ganze eben Grenzen.

Das tut der Leistung dieser Tools und oder ihre Nützlichkeit ja auch kein Abbruch.

 

[ayngush]

Pufferüberläufe fängt das aber nicht mehr ab zum Beispiel. Die gehören zu einer statischen Codeanalyse aber dazu. Wobei es da jedoch keine allgemeingültige Definition gibt. Wenn sie nicht dazugehören, sind sie halt nicht da. Das macht VS C++ aber auch nicht.

Häufig sind die "linter" eh nur Style Guide Prüfungen und ein wenig falsifizierung auf olle Tippfehler (Strichpunkt vergessen usw.) - aber das ist ja auch der Zweck von statischer Codeanalyse. Die Schwächen des Compilers ausgleichen. Der Prüft nämlich nicht (zumindest damals nicht, deswegen wurde "Lint" erfunden), sondern rennt beim erstbesten Fehler einfach, stumpf wie er ist, vor die Wand.

Am Ende meint ihr beide das richtige, redet aber aneinander vorbei. Nicht mehr und nicht weniger meinte ich wiederum

 

[Kokujou]

hast du schon mal Powershell ISE getestet? Zumindest ein paar Syntaxfehler werden (im Rahmen einer statischen Analyse) angezeigt.

Ja damit arbeite ich aktuell aber das ist totaler mist und zeigt nichts an. ich hab jetzt mal VSCode genommen und um die 20 Erweiterungen installiert... im Angular ist es totaler Mist weil er im HTML die neuen Tags nicht ankringelt und... generell kringelt er nichts an. Und das Intellisense ist mit dem neuen Stuff auch total überladen. Jetzt hab ich für jede funktion 200 Einträge von denen die meisten irgendwelche CSS-Klassen sind, was haben die da zu Suchen zur Hölle?!
Müsste ich es nicht von der Arbeit her machen würde ich in meinem Leben niemals Angular benutzen... allein der Aufwand einen einfachen HTTP-Request abzusenden und dann Zertifikat-Fehler wenns auf HTTPS sein muss. hab heute 8 Stunden dran gesessen ohne Ergebnis. Gaaah, warum existiert sowas... kann man nicht einfach ASP .NET schreiben... Sorry manchmal muss ich mich beschweren damits mir besser geht^^

Definitiv eine Empfehlung wert.
Der Produktivitätsboost ist auch bei C# imho nicht zu verachten.
Wobei Visual studio mittlerweile einige Features bekommen hat, die vorher nur Resharper mitbrachte - zumindest laut Der Build.

Das Plugin ist installiert aber aktuell ist die Devise erstmal Angular und Powershell - Timing >.>. der erste Blick: Es macht alles viel komplizierter und nicht viel schöner. und vor allem langsamer. Aber da wir den leider in unserer Pipeline eingebaut haben muss ich mich an diese Codevorgaben halten...

Kann mir mal jemand sagen was so schwer an powershell ist? Wir haben Intellisense. Mit Intellisense kannst du live während der Eingabe sehen welche Befehle zur Verfügung stehen. Also was hindert die daran sowas zu sagen wie "if list -not contains [input] -> rote kringel". Und schon wäre ein deutlicher Boost zu erkennen. Die Fälle in denen sowas beabsichtigt ist kannst du abzählen. So sehr dass du Fehler mit nem Tag deaktivieren kannst im Spezialfall. Allein das würde schonmal unendlich viel helfen. und bei parametern für funktionen ist es dann nur noch einfacher.

Am hilfreichsten wäre Fehlerüberprüfung mit diesem Escaping. \" oder \\ oder vielleicht `" und ' und '' und wers ganz crappy haben will vielleicht \uXXX

oder ob man Variablen mit $() referenzieren muss...

 

[new Account()]

Am Ende meint ihr beide das richtige, redet aber aneinander vorbei. Nicht mehr und nicht weniger meinte ich wiederum

Sehe ich immer noch nicht

 

[Kokujou]

tjaja... also wenn jemand mal ein freies Wochenende hat könnt ihr ja mal sone Extension entwickeln

Jetzt mal ehrlich, warum machen alle immer aus solche Lapalien gleich nen Riesen Aufriss?
Ich meine Wenns Intellisense gibt, also ne liste mit Möglichkeiten für die eingabe dann kann man auch einfach sagen dass wenn das aktuelle Wort nicht darin vorhanden ist es als Fehler gilt. Und Syntaxvorgaben für Powershell sind jetzt auch nicht unbedingt Hexenwerk. Mindestens Klammern kann man kontrollieren. Es wär ja fast einfacher nen eigenen Parser zu schreiben.

Wenn man bedingt wie viele Jahre diese ganzen Programmiersprachen existieren und sowas immer noch nicht anständig gemacht wurde... wie kriegen es normale Menschen zu hin effektiv zu Arbeiten, wenn sie anstatt algorithmische Design-Aufgaben zu lösen erstmal auf jedes Komma überprüfen müssen.

Naja... ich werd mal etwas nachforschen, die begriffe sind ja immerhin jetzt klar, also danke dafür. Jetzt kann ich auch mit den ganzen Extensischs die Lint im Namen oder der Beschreibung haben was anfangen... oder Variationen des Namens.

 

[fhtagn]

Prüfung auf Pufferüberlauf ist keine statische Analyse. Wie soll das gehen? Wie groß ein Puffer initialisiert wird, ist oft nur zur Laufzeit bekannt. Das Gleiche gilt für die Art und Weise wie auf einen Puffer zugegriffen wird. Für wenige Spezialfälle ist eine statische Analyse eingeschränkt möglich, z.B. eine Standardschleife, die über ein Array mit fester Größe iteriert, aber im allgmeinen ist es unmöglich. Das ist einer der Gründe sein, warum viele Sprachen Bereichsüberprüfungen zur Laufzeit durchführen.

Im Grunde genommen funktionieren Linter und Compiler identisch. Beide parsen aus Quelltext einen AST und verarbeiten diesen. Ein Compiler generiert Befehle der Zielsprache, ein Linter untersucht den AST mit einer Liste erweiterter Regeln. Im AST steht z.B.: Array Größe 13 allokieren, Schleife iteriert Array mit Index-Variable, Startwert 0, Endbedingung <= Arraygröße, Schrittweite 1. Linter sagt: Index <= Arraygröße wird nicht funktionieren. Wenn aber die Laufvariable im Schleifenrumpf dynamisch verändert wird, muss auch der Linter passen.

In vielen Sprachen sind schnelle Linter kein Problem. Ganze Projekte parsen dauert Sekundenbruchteile. Hier und da ist die API zum AST-Parsen schon in der Standard-Bibliothek enthalten, so dass jedermann einen Linter schreiben kann. In C++ aber ist es ein großes Problem. Die Grammatik ist nicht kontext-frei, kann nicht mit festen und kurzem Lookahead geparst werden und auch nicht in einem Durchlauf. Hinzu kommen die textuellen Includes/Makros, die den Code aufblähen und verdoppeln. Insgesamt zu langsam für komplexere statische Analysen während der Eingabe. Bleiben nur rudimentäre Linter, die ohne AST auskommen.

Abhilfe schaffen vielleicht die Language-Server und das Language-Server-Protocol (LSP). Ein C++ Language Server muss den AST bei einer Dateiänderung inkrementell aktualisieren können. Dann ist auch der fix.

 

[new Account()]

Bleiben nur rudimentäre Linter, die ohne AST auskommen.

CppCheck nutzt afaik auch ASTs

 

[Kokujou]

Naja man muss es ja auch nicht übertreiben. Wenn ich ne Falsche Zahl in nem Array eingebe dann krieg ich halt ne OutOfRangeException.

Aber man hat in PS noch vor der Laufzeit eine etlich lange Liste mit existierenden Befehlen. Die ist DA. Wie lange dauert es durch ne sagen wir ruhig 1000 Items lange Liste von Strings zu gehen um zu erkennen ob ein Befehl existiert oder nicht? Millisekunden? Nano? Pico?

Das wäre ein Feature. Auch die PS Syntax Infos sind bekannt. Wie ne schleife aussieht und weiß der Geier. Alles bekannt. Auch dass es sowas wie ! als Negation nicht gibt und man stattdessen -not nehmen muss. Im Prinzip ist Powershell mehr oder weniger .Net basiert. zumindest zu großen Teilen. ich werd nie verstehen warum man es nicht genauso bauen kann wie C#.

 

[ayngush]

Prüfung auf Pufferüberlauf ist keine statische Analyse.

Es gibt eben keine Standarddefinition dafür, WAS bei einer statischen Codeanalyse geprüft wird.
Es ist lediglich definiert, dass es ein Whitebox Testverfahren ist. Und in der Vergangenheit, dass es Dinge prüft, die ein Compiler nicht prüft(e). Und selbstverständlich kann man, da Lint historisch von C her stammt, auch auf Pufferüberläufe hin prüfen. Das geht bei C mit statischer Analyse. Das kann man bei C auch manuell vom Zettel ablesen, wenn man das unbedingt möchte.

 

[new Account()]

Es ist lediglich definiert, dass es ein Whitebox Testverfahren ist.

Nein, es ist lediglich definniert, dass der Code analysiert wird ohne ihn auszuführen.
Also gerade ohne ihn zu testen.

Demnach betrifft statische Analyse alles, was an Informationen im Code drin steckt.

Und selbstverständlich kann man, da Lint historisch von C her stammt, auch auf Pufferüberläufe hin prüfen.

Was hat da Historie damit zu tun?
Ob man Pufferüberläufe prüfen kann, hängt eher damit zusammen ob man vom Code aus theoretisch erkennen kann, ob ein Pufferüberlauf stattfindet.
Das ist nicht immer möglich.

ich werd nie verstehen warum man es nicht genauso bauen kann wie C#.

wäre doch mal was für dein nächstes Projekt

 

[ayngush]

Nein, es ist lediglich definniert, dass der Code analysiert wird ohne ihn auszuführen.

Das ist ein Whitebox Testverfahren... Man schaut sich den Quellcode an und prüft "Dinge": White-Box-Test

 

[Kokujou]

wäre doch mal was für dein nächstes Projekt

ich fürchte ich bin mit kommerziellen Projekten ausgelastet und solange meine Bosse sowas nicht in Auftrag geben kannich mir das wohl verreiben.

aber wer weiß wennich mal in die Verlegenheit komme ein Visualstudio Plugin zu entwickeln mussich nur Get-Module aufrufen die Liste zur Laufzeit iterieren und alles ankringeln was da nicht drinne steht. Das nennt sich Marktlücke. Will nicht wissen wie viel Geld man verdienen könnte wenn schon sowas wie Resharper, dass die Laufzeit von Visualstudio halbiert ohne irgendwas dafür zu tun und es auch nicht schafft Reformatting ohne Bestätigungsfenster auszuführen wie es VS mit Strg + K + D macht... gut lassen wir das ^^

PS: Die Liste könnte man übrigens auch ganz bequem beim Start des Editors in den RAM laden und schon hätte man nen Geschwindigkeitsvorteil von xx%

 

[new Account()]

Das ist ein Whitebox Testverfahren...

eine Analyse ist nicht unbedingt Testen:
Analyse: wo lande ich mit einer bestimmten Eingabe
Test: führt meine Eingabe zu der korrekten Reaktion (bspw. mit Eingabe x muss Aktion y ausgeführt werden)
Varianten: Unit Tests, Integration Tests; sh. https://en.wikipedia.org/wiki/White-box_testing

Hier vielleicht eine besser Erklärung zu Testen vs Analyse: https://www.quora.com/What-is-the-difference-between-testing-and-analysis
Hier direkt auf stackexchange : https://softwareengineering.stackex...utomatic-static-analysis-vs-white-box-testing

 

[ayngush]

Es gibt statische (Code wird nicht ausgeführt) analytische (Code wird auf bekannte Fehler hin geprüft) Testmethoden, zu der aus der Abteilung der White-Box-Tests (Quellcode ist bekannt) das Review und die statische Codeanalyse gehören.

https://de.wikipedia.org/wiki/Statische_Code-Analyse
https://de.wikipedia.org/wiki/Statisches_Software-Testverfahren
https://de.wikipedia.org/wiki/White-Box-Test
https://de.wikipedia.org/wiki/Softwaretest#Analytische_Maßnahmen

Testen bedeutet nicht gleich ausführen.
Wenn ich mir den Quelltext ausdrucke und nochmal zusammen mit meinem Kollegen durchgehe, ob das nach unseren Wissen "syntaktisch und logisch korrekt ist", ist das per Definition ein Testfall und die Testmethode lautet "Gruppen Review"...

 

[new Account()]

Streng genommen kann man anscheinend statische Analyse tatsächlich als Unterkategorie von Whitebox-Tests auf Code betrachten (wie im Artikel aufgeführt): es werden viele Tests ausgeführt um den Code zu analysieren.
Also ja dein White-Box-Testing Begriff ist nicht falsch (auch wenn du außer acht lässt, dass statische Analyse untergeordnet ist).

Dennoch gibt es einen gewissen semantischen Unterschied zwischen Test und Analyse, der auch auffällt, wenn man die Analyse und Test-Artikel auf einem höheren Level durchliest.
Beim Testen hat man, wie du schon gesagt hast, hat man gezielte Testfälle. Ein Testfall kann erfüllt sein oder nicht.
Beim Analysieren geht man generell (ggf. mit einer technisch bedingten Auswahl von Aspekten) durch den Code und begutachtet diesen. Eine Analyse zeigt vorher nicht bekannte/spezifizierte Eigenschaften an.
(Entsprechend in meinen Links erklärt)

Wenn ich mir den Quelltext ausdrucke und nochmal zusammen mit meinem Kollegen durchgehe, ob das nach unseren Wissen "syntaktisch und logisch korrekt ist", ist das per Definition ein Testfall und die Testmethode lautet "Gruppen Review"...

Ein Testfall hat eine spezielle Eigenschaft, z.B. "keine Syntaxfehler":

Ein Testfall (engl. Test case) beschreibt einen elementaren, funktionalen Softwaretest, der der Überprüfung einer z. B. in einer Spezifikation zugesicherten Eigenschaft eines Testobjektes dient

Wenn du einfach nur wild durch den Code gehst und schaust, ob generell Probleme vorhanden sind (aka Code review), entspricht das eher einer Analyse.

Welche Definition von Testfall verwendest du?


Was anderes wäre, wenn du jetzt mit "Wissen" funktionale Anforderungen meinst, die ihr Fall für Fall komplett durchgeht.

 

[fhtagn]

[...] Und selbstverständlich kann man, da Lint historisch von C her stammt, auch auf Pufferüberläufe hin prüfen. Das geht bei C mit statischer Analyse. Das kann man bei C auch manuell vom Zettel ablesen, wenn man das unbedingt möchte.

Wie gesagt, es ist möglich, statisch auf bekannte Konstellationen/Muster für Pufferüberläufe hin zu prüfen. Es ist aber nicht möglich, Code generell auf Pufferüberläufe hin zu prüfen. Nicht statisch und auch nicht dynamisch mit Code-Ausführung.

Dein Link aus Wikipedia:
Edsger W. Dijkstra schrieb hierzu: „Program testing can be used to show the presence of bugs, but never show their absence!“

Zurück zum Thema: "Fachbegriff für Live Codeüberprüfungen" und "was sind die Unterschiede zwischen Linter und Compiler"

 

[SheepShaver]

Das ist ein Whitebox Testverfahren... Man schaut sich den Quellcode an und prüft "Dinge": White-Box-Test

Das ist so nicht ganz richtig. Whitebox-Testing sagt lediglich aus, dass der Test im Gegensatz zum Blackbox-Testing Implementierungsdetails testet. Und ueblicherweise wird der Code dazu ausgefuehrt.
Whitebox-Testing macht man normalerweise mit Unit-Tests oder auch bei Integrationstests oder Regressionstests. Mit statischer Codeanalyse hat es sicherlich NICHTS zu tun.

Zum Thema Linter:
Jeder Editor erlaubt das Ausfuehren eines Linters beim Abspeichern. Was ein Linter genau macht, haengt vom Linter ab. Allen gemeinsam ist, dass sie Sourcecode analysieren und NICHT ausfuehren.

 

[ayngush]

Welche Definition von Testfall verwendest du?

Die aus dem Qualitätsmanagement... Gibt es mehrere?

Es ist doch ein Testfall, wenn ich definiere, dass der Code z.B. keine bekannten Syntaxfehler und keine bekannten Pufferüberläufe haben darf und ich als Testmethode dafür die Methode Code Review verwende...

Zumindest mache ich als Projektmanager dann ein "Haken" dahinter, falls ich irgendwann mal wieder anfange Testfälle zu definieren. Qualitätsmanagement spielt ja heutzutage offensichtlich keine Rolle mehr (Erfahrung aus dem Alltag... nur noch Code + Fix und das wird dann als "agil" verkauft - die einzig qualitätssichernde Maßnahme ist nur noch "compiliert doch" - ist aber nen anderes Thema)

 

[parats]

@Kokujou Bei Microsoft heisst das Feature IntelliSense. Für Skriptsprachen würde ich nicht Visual Studio sondern Visual Studio Code verwenden. Da gibts sehr viele Plugins und Extensions die dir verwchiedenste Funktionen für verschiedenste Sprachen bieten. Aucb Live-Codeüberprüfung.

Ist IntelliSense nicht nur die reine Vervollständigung?