Gibt es eine bessere Strategie, als sich auf den Compiler zu verlassen, um Fehler abzufangen?

Ich programmiere seit einiger Zeit in C und C ++, obwohl ich sagen würde, dass ich weit davon entfernt bin, ein Experte zu sein. Seit einiger Zeit verwende ich verschiedene Strategien, um meinen Code zu entwickeln, z. B. Komponententests, testgetriebenes Design, Codeüberprüfungen usw.

Als ich meine ersten Programme in BASIC schrieb, tippte ich lange Blöcke ein, bevor ich feststellte, dass sie nicht ausgeführt werden würden und ein Albtraum zum Debuggen waren. Also habe ich gelernt, ein bisschen zu schreiben und es dann zu testen.

Heutzutage schreibe ich oft wiederholt ein kleines Stück Code und benutze dann den Compiler, um alle Fehler zu finden. Das ist in Ordnung, wenn es einen Tippfehler aufgreift, aber wenn Sie anfangen, die Parametertypen usw. anzupassen, damit es kompiliert wird, können Sie das Design vermasseln. Es scheint auch, dass sich der Compiler in den Entwurfsprozess einschleicht, wenn er nur zur Überprüfung der Syntax verwendet werden soll.

Hier besteht die Gefahr, dass ich mich zu sehr auf den Compiler verlasse, um meine Programme zu verbessern. Gibt es bessere Strategien als diese?

Ich erinnere mich vage an einen Artikel über ein Unternehmen, das eine Art C-Compiler entwickelt hat, in dem in einer zusätzlichen Header-Datei auch die Prototypen angegeben wurden. Die Idee war, dass Inkonsistenzen in der API-Definition leichter zu erkennen sind, wenn Sie sie zweimal auf unterschiedliche Weise definieren müssen.

Passen Sie die Dinge nicht an, damit sie kompiliert werden. Passen Sie die Dinge an, um richtig zu sein . Wenn es so "entworfen" wurde, dass die Parametertypen nicht übereinstimmen, hat der Designer keine Ahnung, was sie tun.

Wenn Sie sich nicht auf den Compiler verlassen möchten, verbessern Sie Ihre Sprachkenntnisse. Studieren Sie die Struktur von Definitionen und Deklarationen und überprüfen Sie vor dem Kompilieren, was Sie auf Fehler schreiben. Und verwenden Sie Codeüberprüfungen.

Diese Idee mit zusätzlichen Prototypen klingt schlecht. Wenn Sie es einmal falsch entwerfen, was kann verhindern, dass das zweite Design falsch entworfen wird? Und wenn Sie verschiedene Formate / Paradigmen / usw. für dasselbe verwenden, werden Sie wahrscheinlich die Leute verwirren. Ich würde sicherstellen, dass jeder das primäre Format versteht, damit Sie sich darauf konzentrieren können, das Design beim ersten Mal richtig zu machen, anstatt die Designarbeit zu verdoppeln, um Fehler zu erkennen. Wie alles andere sollten Designs überarbeitet werden, aber ich denke nicht, dass es viel Sinn macht, es zunächst zweimal zu tun.

Ehrlich gesagt glaube ich, dass Ihr Ziel IMMER darin bestehen sollte, ein Programm zu schreiben, das beim ersten Mal kompiliert wird. Mir ist klar, dass dies schwierig ist und wahrscheinlich nicht häufig vorkommen wird, aber es sollte immer noch Ihr Ziel sein. Stellen Sie sich die Software als Stück Hardware vor. Stellen Sie sich vor, dass es unrealistisch teuer ist, Ihren Code neu zu kompilieren (wie das Wiederherstellen eines Boards). Ein Complier ist kein Debugger und sollte nicht als solcher behandelt werden.

Der Compiler kann nicht alle Fehler finden, daher macht es keinen Sinn, dies vorzutäuschen. Alles, was es finden kann, sind die Syntaxfehler und Tippfehler. Es ist gut genug, dass ich es diesen Teil des Jobs machen lasse (obwohl heutzutage die Umgebung 99% von denen selbst abfängt, bevor Sie jemals auf Kompilieren klicken), aber ich weiß genau, dass das nicht alle Fehler sind.

Das einzige Mal, dass ich mich auf diese Art von Informationen verlasse, um mir zu sagen, was ich schreiben soll, ist, wenn ich Dinge wie diese bekomme, die mir sagen, dass ein Double nicht automatisch in einen Float umgewandelt werden kann - wenn Sie Daten senden, erwartet Floats (und seitdem) Was ich gerade mache, ist mit der XNA-Bibliothek zu spielen, die genau dies tut) und die Quelle gibt Doppelte zurück (wie es bei der C # -Mathematikbibliothek der Fall ist), dann müssen Sie einfach konvertieren.

Der Compiler ist ein Werkzeug. Wie bei allen Werkzeugen können sie missbraucht werden.

Wenn Sie zum ersten Mal mit einer Sprache beginnen, ist es nichts Falsches, den Compiler blind zum Testen Ihres Programms zu verwenden. So funktioniert Lernen von Natur aus, raten und überprüfen Sie. Dies bedeutet jedoch nicht, dass Sie weiterhin so codieren sollten.

Es liegt in Ihrem besten Interesse, die Sprache gut genug zu verstehen, damit Sie Ihr Programm in Ihrem Kopf zusammenstellen können. Dann müssen Sie weniger darauf warten, dass der Compiler fertig ist.

Ich sage, es ist wahrscheinlich am besten, wenn sich das Programm immer innerhalb weniger Zeilen / Codeblöcke befindet, um kompilierbar zu sein.

Die meisten modernen IDEs haben viele Compilerprobleme, und ich glaube, ich bin auch ziemlich darauf angewiesen.

Vielleicht zurück zu Textdateien und Kommandozeilen-Compilern?