Warum unterstützen IDEs keine dynamische Formatierung?

Question

Warum erlauben IDEs in Anbetracht all der heiligen Kriege um verschiedene Codeformatierungsstile und der strengen Formatierungsanforderungen vieler Unternehmen keine dynamische Neuformatierung von Code?
Damit meine ich, dass die IDE den Code jedes Mal so formatieren soll, wie der Benutzer es wünscht, und den Code ohne jegliche Formatierung speichern soll. (Nun, vielleicht Zeilenumbrüche, so dass Unterschiede immer noch einfach sind)
Der Benutzer müsste sich keine Gedanken über die Einhaltung eines Codierungsstandards machen, die Leute würden sich nicht darüber aufregen, dass sie in einem Code arbeiten, der nicht so formatiert ist, wie sie es mögen, und Formatierungsänderungen würden nicht in den Repository Diffs auftauchen.
Es muss einen Mechanismus geben, mit dem man es ausschalten kann, damit es nicht alten, vorformatierten Code durcheinanderbringt, aber was hält es sonst davon ab, eine Standardfunktion zu werden?

Edit: Ich weiß, dass einige IDEs eine Formatierungsfunktion haben, aber das verursacht fast so viele Probleme, wie es löst - Versionskontrolldifferenzen werden fast nutzlos, da die tatsächlichen Änderungen in einem Meer von unbedeutenden Formatierungsänderungen verloren gehen, und unterschiedliche Tabulatorzeichenbreiten bringen die Dinge immer noch aus dem Gleichgewicht. Außerdem ermöglicht es den Programmierern nicht, mit dem Code in ihrem bevorzugten Format zu arbeiten.

Answer 1

Ich glaube, mit Eclipse kann man den Code formatieren, wie man will.

EDIT: Ja, der Java Code Formatter formatiert auf der Grundlage von Regeln, die Sie im Projekt festlegen.

Answer 2

Denn die meisten Leute wollen den Code so sehen, wie er übertragen werden soll. Solange nicht alle Werkzeuge, die Sie zum Betrachten Ihres Codes verwenden (Diff-Programme, grep, webbasierte Quellcode-Repository-Viewer usw.) verstehen, wie man den Code dynamisch auf die gleiche Weise formatiert, werden Sie durch unterschiedliche Formatierungen verwirrt sein, wenn Sie ihn in Ihrer IDE und in den anderen Werkzeugen betrachten.

Ich stimme zu, dass es schön wäre, wenn wir mehr Werkzeuge für die Strukturprogrammierung hätten, anstatt Werkzeuge für Text mit fester Breite, aber das würde bedeuten, dass man alles in seiner Werkzeugkette aktualisieren müsste, um es wirklich praktikabel zu machen.

Answer 3

Ich habe auch schon darüber nachgedacht, dass dies eine gute Idee wäre, allerdings als Funktion der Quellcode-Kontrollsoftware und nicht als Funktion der IDE.

Der Code könnte als Liste von Token gespeichert und beim Kopieren auf den Entwicklungscomputer rekonstruiert werden. Dies entspricht dem Punkt von aleemb, da kein Leerraum gespeichert wird. Um alle Fälle abdecken zu können, wären allerdings ausgefeiltere Formatierungsregeln erforderlich.

Damit sind auch die Bedenken von Martin Harris ausgeräumt: Der Code auf Ihrem Rechner würde keine Sonderzeichen enthalten, sondern nur Leerzeichen zwischen den Token.

Answer 4

Ich denke, dass die Dateien, die sich auf dem aktuellen Rechner befinden, in den meisten Fällen in einem gängigen Textformat vorliegen sollten. Es ist mehr als nützlich, jede Quellcodedatei, an der ich arbeite, in Notepad oder einem anderen praktischen Texteditor öffnen zu können. Aus diesem Grund möchte ich nicht, dass meine lokalen Kopien irgendwelche Sonderzeichen enthalten, die die IDE als "Dies ist ein Einzug, bitte verwenden Sie hier einen Tabulator oder ein Leerzeichen, wie Sie es für richtig halten" interpretiert. Meiner Meinung nach ist der beste Punkt, um diese Art von Formatierung vorzunehmen, das Versionskontrollsystem: Sie checken eine Datei so formatiert ein, wie Sie wollen, ich checke sie so formatiert aus, wie ich will.

Vor einiger Zeit fragte ich diese Frage über Versionskontrollprogramme, die den Code nicht verstehen, und die Antwort von ascalonx, die mich auf Quellensicherung in der Datenbank . Es ist eine Schande, dass diese Idee nicht mehr Zugkraft zu haben scheint, da sie sowohl unsere Probleme lösen als auch viel mehr . Ich bin ein .NET-Entwickler, also bin ich im Moment sehr außen vor, aber anscheinend kommen Eclipse und IntelliJ in der Java-Welt diesem Ideal immer näher (ich weiß nicht, wie nah, da ich beides noch nie benutzt habe)

Answer 5

Ich denke, die größte Hürde wäre die Rekonstruktion der Quellcode-Kommentare, da sie keine formale Semantik haben - ich spreche nicht von JavaDocs oder ähnlichem, sondern eher von den Kommentaren, die inline mit den Quellen platziert werden. Ohne semantische Regeln für Quellcodekommentare fällt das ganze Konzept auseinander.

Sicherlich können Sie die AST-Version kontrollieren, aber wie werden Sie die Kommentare auf die AST-Knoten abbilden?

Ein naiver Ansatz wäre, Kommentare mit Anweisungen in der Sprache zu verknüpfen, aber was ist, wenn ich einen Kommentar habe, der für "die nächsten 3 Zeilen" gilt, und dann jemand eine der Zeilen an eine andere Stelle verschiebt. Wohin geht der Kommentar?