So überzeugen Sie das Management davon, dass die Neuformatierung der gesamten Java-Codebasis sicher ist

https://stackoverflow.com/questions/2420174

19-09-2019
|

Frage

Wie kann man dem Management beweisen, dass eine Batch-Neuformatierung aller Java-Dateien in einer großen Codebasis (um den Code in Übereinstimmung mit den Codierungsstandards des Unternehmens zu platzieren) sicher ist und die Funktionalität nicht beeinträchtigt?

Die Antworten müssten sowohl die Laien als auch die Techniker zufriedenstellen.

Bearbeiten:12.03.2010Klarstellung für die Techniker unter Ihnen;reformat = Änderungen nur durch Leerzeichen – kein „Organisieren von Importen“ oder „Neuanordnen von Mitgliedsvariablen, Methoden usw.“

Bearbeiten:12.03.2010 Vielen Dank für die zahlreichen Antworten.Ich bin überrascht, dass so viele Leser für die Antwort von mrjoltcola gestimmt haben, da es sich lediglich um eine Aussage darüber handelt, paranoid zu sein, und in keiner Weise eine Antwort auf meine Frage bietet.Darüber hinaus gibt es sogar einen Kommentar desselben Autors, der die Frage wiederholt.WizzardOfOdds unterstützte diesen Standpunkt (aber Sie haben möglicherweise nicht alle Kommentare gelesen, um ihn zu sehen).-jtsampson

Bearbeiten:12.03.2010 Ich werde bald meine eigene Antwort veröffentlichen, obwohl die Antwort von John Skeet mit dem MD5-Vorschlag genau richtig war (beachten Sie -g:none, um das Debuggen auszuschalten).Allerdings ging es nur um die technischen Aspekte.-jtsampson

2010-03-15 Ich habe unten meine eigene Antwort hinzugefügt.Als Antwort auf die Bedeutung von „sicher“ meinte ich, dass die Funktionalität des Java-Codes nicht beeinträchtigt wird.Eine einfache Untersuchung des Java-Compilers zeigt, dass dies der Fall ist (mit einigen Einschränkungen).Diese Vorbehalte betrafen „nur Leerzeichen“ und wurden von mehreren Postern hervorgehoben.Dies möchten Sie BizOps jedoch nicht erklären.Mein Ziel war es, Antworten vom Typ „Wie rechtfertige ich das zu rechtfertigen?“ zu finden, und ich habe mehrere großartige Antworten erhalten.

Mehrere Leute erwähnten die Quellcodeverwaltung und den damit verbundenen „Spaß“.Ich habe das ausdrücklich nicht erwähnt, da diese Situation (in meinem Kontext) bereits gut verstanden ist.Hüten Sie sich vor dem „Tankstelleneffekt“.Siehe meine Antwort unten.

Lösung

Wenn es sich nur um eine neu formatierende Art handelt, sollte dies die Compiler -Produktion nicht ändern. Nimm einen Hash (MD5 sollte gut genug sein) des Builds vor und nach der Neuformatierung - wenn es für jede Datei gleich ist, bedeutet dies eindeutig, dass es das Verhalten nicht verändert hat. Es besteht keine Notwendigkeit, Tests usw. auszuführen - Wenn die Ausgabe für das Byte gleich ist, ist es schwer zu erkennen, wie die Tests fehlschlagen würden. (Natürlich könnte es helfen, die Tests nur für die Show durchzuführen, aber sie werden nichts beweisen, was die identischen Binärdateien nicht tun.)

Bearbeiten: Wie in Kommentaren hervorgehoben, enthalten die Binärdateien Zeilennummern. Stellen Sie sicher, dass Sie mit kompilieren -g:none Debug -Informationen weglassen. Das sollte dann mit Änderungen der Zeilennummerierung in Ordnung sein - aber wenn Sie sich ändern Namen Das ist eine ernstere Veränderung und eine, die in der Tat eine brichtliche Veränderung sein könnte.

Ich nehme dich an kann Umformat und wieder aufbauen, ohne sich jemand zu kümmern - nur den neu formatierten Kodex in die Quellenkontrolle zu überprüfen, sollte irgendein Anlass zur Sorge geben. Ich nicht denken Java -Klassendateien haben etwas in ihnen, das ein erstellendes Datum usw. gibt. Wenn Ihre "Formatierung" die Reihenfolge der Felder usw. ändert. kann einen signifikanten Effekt haben.

Andere Tipps

In einem Geschäftsumfeld haben Sie zwei Herausforderungen.

Technisch
Politisch

Aus technischer Sicht sind Reformatter eine ausgereifte Technologie. In Kombination mit Hashing/Prüfsummen können Sie dies technisch sicher tun, solange die Sprache nicht weißespace sensibel ist. Sie möchten auch sicherstellen, dass Sie es während einer Ausfallzeit tun, in der keine großen Gabeln darauf warten, zusammengeführt zu werden. Es werden echte Veränderungen unmöglich sein, sich von der Reformatierung zu trennen, so auch getrennt. Das Zusammenführen kann für jeden, der an einer Gabel arbeitet, sehr schwierig sein. Zuletzt würde ich es erst tun, nachdem ich eine vollständige Testfallabdeckung implementiert habe. Aus Vernunft 2 ...

Politisch, wenn Sie nicht wissen, wie man das Management überzeugt, woher weißt du, dass es sicher ist? Genauer gesagt ist es für Sie sicher. Für einen hochrangigen, gut vertrauten Entwickler, der die Kontrolle über die Prozesse in einem Geschäft hat, ist dies ein einfacher Job, aber für einen Entwickler, der in einer großen, politischen, rot geschmückten Organisation arbeitet, müssen Sie sicherstellen Basen.

Das Argument, das ich 2010 vorgenommen habe, war vielleicht etwas zu schlau, aber Parser, Reformatierende, hübsche Drucker sind nur Software; Möglicherweise haben sie Fehler, die von Ihrer Codebasis ausgelöst werden, insbesondere wenn dies C ++ ist. Ohne Unit -Tests überall mit einer großen Codebasis können Sie möglicherweise nicht 100% überprüft, ob das Endergebnis identisch ist.

Als Entwickler bin ich paranoid und die Idee macht mich unruhig, aber solange Sie verwenden:

Quellcodeverwaltung
Richtige Testabdeckung

Dann geht es dir gut.

Denken Sie jedoch darüber nach: Das Management ist sich jetzt bewusst, dass Sie in einem Millionen-Zeilen-Projekt mit einem "Massenwechsel" herumlaufen. Ein bisher unentdeckter Fehler wird nach Ihrem Reformat gemeldet. Sie sind jetzt Hauptverdächtige, um diesen Fehler zu verursachen. Ob es "sicher" ist, hat mehrere Bedeutungen. Es ist möglicherweise nicht sicher für Sie und Ihren Job.

Das klingt banal, aber vor ein paar Jahren erinnere ich mich daran, dass etwas so passiert ist. Wir hatten einen Fehlerbericht an einem Tag nach einem nächtlichen Wartungsfenster, in dem ich nur eine Neukonfiguration gemacht hatte und einen Neustart von einem neu gestartet hatte Iis Server. Für mehrere Tage war die Geschichte, dass ich es vermasselt oder neuen Code eingesetzt habe. Niemand hat es direkt gesagt, aber ich habe den Look von einem VP bekommen, der es sagte. Wir verfolgen es schließlich auf einen Fehler, der bereits im Code war, zuvor gedrückt worden war, zeigte sich jedoch erst in letzter Zeit, bis eine QA -Person einen Testfall geändert hatte, aber ehrlich gesagt erinnern sich einige Leute nicht einmal an diesen Teil. Sie erinnern sich nur daran, am nächsten Tag zu einem neuen Fehler gekommen zu sein.

Bearbeiten: als Antwort auf Jtsampsons Änderungen. Ihre Frage ging nicht darum, wie es geht. Es war "wie man das Management davon überzeugt, dass es sicher ist". Vielleicht hätten Sie stattdessen fragen sollen: "Ist es sicher? Wenn ja, wie geht es das sicher." Meine Aussage zeigte auf die Ironie Ihrer Frage, da Sie davon ausgegangen sind, dass es sicher war, ohne zu wissen, wie. Ich schätze die technische Seite der Neuformatierung, aber ich weise darauf hin, dass ein Risiko besteht, dass etwas nicht trivial ist, und wenn Sie nicht die richtige Person darauf legen, könnte es sich vermuteten. Wird diese Aufgabe die anderen Aufgaben der Programmierer beeinträchtigen und sie für ein paar Tage ablenken? Wird es mit den nicht gebrauchten Revisionen eines anderen Codierers in Konflikt stehen? Ist die Quelle überhaupt eine Revision? Gibt es ein eingebettetes Skript, das weißempfindlich ist, wie z. Python? Alles kann einen unerwarteten Nebeneffekt haben; Für unsere Umwelt wäre es schwierig, ein Zeitfenster zu bekommen, in dem nicht jemand an einer Niederlassung arbeitet, und die Massenformatierung wird ihre Zusammenführung ziemlich hässlich machen. Daher meine Abneigung zur Massenreformierung von Hand oder automatisiert.

Verwenden Sie einen pragmatischen Ansatz:

Erstellen Sie die Anwendung.
Speichern Sie die Anwendung.
Den Kodex neu format.
Erstellen Sie die Anwendung.
Diff der Binärdateien.

Ich würde vier Wörter verwenden.

Quellcodeverwaltung. Unit -Tests.

Nun, es ist überhaupt nicht sicher und Sie sind unwahrscheinlich, dass Sie sie jemals überzeugen. Als jemand, der viel Entwicklung geschafft hat, würde ich es nie in einer kommerziellen Codebasis betrachten, von der Einnahmen abhängen. Ich sage nicht, dass es keine Vorteile gibt, um so formatiert zu sein, wie Sie möchten, aber die Chancen, dass Ihre Formatierung keine Codeänderungen beinhaltet, ist NIL. Das bedeutet, dass ein großes Risiko für sehr wenig Gewinn besteht. Wenn Sie es tun müssen, tun Sie es stückweise, während Sie den Code fixieren, und tun Sie es nicht in einem großen Treffer. Es mag eine gute Entscheidung für Sie als Programmierer sein, aber es wäre eine schreckliche Entscheidung für sie als Management.

Über welches Management sprechen wir hier? Sind sie technisch versiert genug, um zu verstehen, welche Code-Formatierung ist und wie Java Whitespace behandelt? Denn wenn dies nicht der Fall ist, denke ich nicht, dass sie qualifiziert sind, eine solche technische Entscheidung zu treffen (dh solche Fragen sollten an jemanden delegiert werden, der für den Code verantwortlich ist).

Aber wenn sie sind oder Sie versuchen, Ihren "Architekten" oder jemanden ähnlich zu überzeugen, geht es darum, einem Drittanbieter -Tool zu vertrauen. Schlagen Sie ein Formatierer vor, der einen guten Ruf hat, außer dass Sie nicht viel tun können, da Sie das Formatierer nicht codiert haben.

Lassen Sie mich als Nebenspur eine Anekdote teilen. Unser Architekt entschied sich zu einem Zeitpunkt, alle Dateien neu zu formatieren. Von Tausenden von Java -Dateien wurde noch kein einziger Fehler gefunden (und dies war vor über einem halben Jahr). Dadurch vertraue ich mit Eclipse für Java -Quellcode. Die Vorteile dieser Formatierung waren:

Einige schlecht formatierte Klassen sind jetzt leichter zu lesen.
Überall gleiche Formatierung.

Aber es hatte auch einige negative Seiten:

Ein Codeformatierer ist nicht perfekt. Manchmal liest man manuell formatierter Code besser. Insbesondere das Formatierer kämpft mit wirklich schlechten Code (zu lange Zeilen, zu viele verschachtelte IFs usw.).
Haben Sie andere Codezweige, wie eine alte Version, die gelegentlich gepatcht werden muss? Weil Sie vergessen können, zwischen Zweigen mit unterschiedlichen Codestilen zu verschmelzen (zumindest bei der Verwendung von SVN).
Sie berühren alle Dateien (und manchmal fast jede Zeile) und ruinieren die Geschichte aller Dateien gleichzeitig. Es verletzt Rückverfolgbarkeit.
Es gibt tatsächlich einen kleinen Vorteil, da jeder Entwickler seine eigene Code -Formatierung hat, da Sie diese Formatierung kennenlernen und Sie den Autor eines Code -Stücks sofort identifizieren können

Ich persönlich denke, dass das Negative das Positive überwiegt. Es klingt nach einer großartigen Idee, aber in Wirklichkeit gewinnen Sie nicht so viel, wie Sie denken. Wenn Sie auf einen schrecklich formatierten Code stoßen, formatieren Sie nur diese Klasse oder nur diese Methode und sehen Sie ihn als einen kleinen Schritt in Richtung des großen Ziels.

Passen Ihre Unit -Tests nach der Neuformatierung? Wenn ja, dann haben Sie die Idee an das Management verkauft!

Wenn Sie mit ungetestetem Code herumhauen, haben Sie einen viel schwierigeren Fall zu machen.

Du willst das "Code in Übereinstimmung mit den Codierungsstandards des Unternehmens" sic] und wollen das Management überzeugen?

Trivial: Installation Checkstyle, Machen Sie es zu einem Teil Ihres Prozesses, füttern Sie ihn mit Ihren Codierungsrichtlinien und zeigen Sie ihnen, dass die gesamte Codebasis kläglich Scheitert an Checkstyle.

Dies ist ein gutes Beispiel für die Fehlanpassung des technischen Unternehmens.

Die technischen Leute wollen es tun, weil er den Code schwer zu lesen macht, aber es sei denn, es ist außergewöhnlich Schlecht, der wahre Grund ist, dass es die typisch empfindlichen Sensibilität und die Ästhetik des durchschnittlichen Programmierers beleidigt.

Die Geschäftsleute wollen das Risiko verwalten. Das Risiko kann eingegangen werden, wenn es einen gewissen Nutzen gibt und es keine gibt Geschäft Nutzen Sie hier, es sei denn, Sie argumentieren, dass es billiger, schneller und/oder weniger riskant sein wird, zukünftige Entwicklung mit neuem Quellcode zu führen, was ehrlich gesagt ein schwieriger Verkauf ist.

Fast per Definition hat jede Änderung das Risiko beigefügt. Das Risiko hier ist fern, ist aber auch nicht vorhanden (aus Sicht des Managements) mit fast ohne Vorteil.

Es gibt auch ein weiteres Problem zu berücksichtigen: Diese Art von Veränderung kann mit der Quellenkontrolle Chaos spielen. Es wird schwieriger zu verfolgen, wer das geändert hat, weil die jüngste Änderung in jeder Zeile die neu formatierende sein wird, sodass Sie Revisionen vergleichen müssen, was etwas langwieriger ist als ein einfacher "Schuld" oder "Annotate".

Wenn Sie mehrere aktive Filialen haben, wird eine Neuformat Ihres Kodex mit Ihren Zusammenführungen Chaos verursacht.

In dem Sinne ist sicher, dass reine Formatierungsänderungen keinen Unterschied zu dem machen, was kompiliert wird, und daher keinen Unterschied zum Verhalten des Code zur Laufzeit.

Es ist sich daran zu erinnern, dass die Umformatierung von Code von Großmassen zu "Spaß" im späteren Umgang mit der Quellenkontrolle führen kann. Wenn mehrere Kollegen den Code überprüfen lassen und ein Teammitglied kommt und es neu formatiert, sind alle diese Exemplare veraltet. Schlimmer noch, wenn sie ihre Arbeitskopien aktualisieren, werden alle Arten von Konflikten erscheinen, da diese Formatierungsänderungen große Teile des Codes beeinflussen und dies ein Albtraum sein kann.

Das neu formatierende Kodex ist das gleiche wie das Umbau eines Dokuments in Wort; Es ändert das Layout und damit die Lesbarkeit, aber nicht den Inhalt.

Wenn alle Dateien gleich formatiert sind, wird der Code mehr lesbar, was die Wartung etwas einfacher und damit billiger macht. Auch Code -Bewertungen können schneller und effektiver sein.

Angesichts eines guten Formatierungsstils können Fehler leichter gefunden werden, da sie sich nicht verstecken können. Überlegen Sie sich, ob Aussagen ohne lockige Zahnspangen und 2 Aussagen in diesen imaginären Zahnspangen.

Seien Sie schlau und überprüfen Sie den Code in und markieren Sie ihn vor dem Umformieren. Sie haben also einen Staat, in den Sie zurückkehren können (und den Menschen sagen, wie einfach das wäre), formatieren Sie und einchecken und markieren Sie sie erneut, ohne andere Änderungen.

Beantworten Sie diese Fragen für das Management, und Sie werden eine lange Weise davon überzeugen haben, dass es sich um eine sichere Veränderung handelt?

Warum ist eine gute Formatierung von Bedeutung?
Welche Änderungen werden vorgenommen? (Wenn Sie dies nicht beantworten können, wissen Sie nicht genug über die Neuformatierung, um zu wissen, dass es sicher ist.)
Werden unsere Unit -Testsuiten beweisen, dass die Änderungen keine negativen Auswirkungen haben? (Hinweis Die Antwort muss ja sein)
Wird der vorhandene Code im Quell -Repository markiert, sodass wir eine schnelle Rollback -Option haben? (Hinweis Die Antwort ist besser ja)

Das über deckt es ab.

Eigentlich wäre ich wahrscheinlich auf ihrer Seite. Reformat -Einheiten, während Sie sie für Korrekturen oder Verbesserungen öffnen, wenn sie vor der Rückkehr in die Produktion gründlich getestet werden. Sie hätten beim ersten Mal korrekt formatiert werden sollen, aber wenn sie in Produktion sind, erscheint es unnötig und rücksichtslos, sie nur aus Gründen des Stils neu formatieren.

Konsistenz ist gut, aber "eine dumme Konsistenz ist das Hobgoblin der kleinen Köpfe".

Ich ziehe meinen Manager -Hut an ...

Um es als ein großes Projekt zu tun, würde ich es nicht zulassen, egal wie hoch das Argument. Ich wäre jedoch offen für längere Schätzungen zu Änderungen, da Sie vorhandene Dateien so ändern, dass diese Formatierungsänderungen einbezogen werden. Ich würde jedoch verlangen, dass Sie die Formatierungsänderungen vornehmen.

Vielen Dank für all Ihre Antworten.

Mein letztes Argument, das Management zu überzeugen; Teile aller Ihrer Antworten enthalten. Danke für die Hilfe.

Technisch:

Das Reformat besteht aus Weißwindungsänderungen (keine Import -Neuordnung, kein Mitglied/keine Methode)
Reformat wird verwendet [Werkzeug und Prozess angeben
Reformat erfolgt auf [Zeitspanne innerhalb des Codierungszyklus, um die Zusammenführungsauswirkungen zu minimieren

Sowohl vor als auch nach einem Reformat:

Alle Unit -Tests werden durchgeführt
Alle Integrationstests werden bestehen
Alle Funktionstests werden durchgeführt
Alle Seifen-UI-Tests werden bestehen
Der Byte-Code ist derselbe (ein MD5 der .class-Dateien nach Javac (-g: keine))

Geschäft:

Zweck: Einhaltung der Unternehmensstandards, die vorschreibt, dass unsere Quelldateien die logische Struktur unseres Codes genau darstellen.

Änderung neu format vs. Code Änderung (Word -Dokumentbeispiel wie oben)
Reformat wird [allgemeiner Prozess] verwenden
Reformat erfolgt auf [Zeitspanne innerhalb des Geschäftszyklus, um die Auswirkungen zu minimieren

Testlauf:

Bestätigte "Format -Stapel" führte zu weniger Zusammenführungskonflikten als "Format wie Sie codieren". .
Bestätigte, dass der ausführbare Code (4K+ .Class -Dateien) gleich bleibt. (MD5 -Test)
Bestätigte Funktionalität ist nicht betroffen (automatisierte Tests/Rauchtests)
Bestätigte Formatiereinstellungen enthalten nur Änderungen des Weißraums.

Notiz: In meinem Fall wurde ein Pilottest über 6 Monate von einer Teilmenge der Entwickler ein automatisiertes Tool zum "Format wie Sie codieren" durchgeführt (wie einige der oben genannten Antworten vorgeschrieben). Während einige feststellten, dass die Reformatierung mehr Zusammenführungskonflikte verursachte, war dies tatsächlich nicht der Fall.

Diese Wahrnehmung lag auf dem zeitlichen Zufall des Reformates. Betrachten Sie zum Beispiel die Person, die nichts über Autos weiß. Eines Tages scheitern ihre Bremsen. Was schreibt sie die Ursache zu? Das Gas natürlich. Es war das Letzte, was sie in das Auto steckten (den "Tankstelleneffekt"). Bremsen und ein Kraftstoffsystem sind jedoch ein unterschiedliches System, ebenso wie Formatierung und Codeänderungen. Wir fanden heraus, dass unsachgemäße Überprüfungen im Kontext unseres Build-Prozesses schuld waren.

Zuletzt hatte ich gehofft, dass jemand einen guten Zusammenhang mit einer Studie darstellt, die Produktivitätsgewinne im Zusammenhang mit gemeinsamem Code zeigt, da es schwierig ist, den ROI für das Unternehmen zu zeigen. Obwohl in meinem Fall, da es sich um einen Unternehmensstandard handelte, hatte ich "Compliance" auf meiner Seite. Ich musste nur zeigen, dass es zeitaufwändiger war, "Format" zu "Format" im Vergleich zu "Batch -Format" war,

Wenn Sie verwenden Finsternis Als Entwicklungsplattform können Sie den gesamten Code lokal in den Arbeitsbereich laden. Dem Management zeigen, dass es keine Probleme gibt, indem sie ihnen die Registerkarte "Probleme" zeigen.

Klicken Sie dann mit der rechten Maustaste und formatieren Sie jedes der Projekte nacheinander - erneut zeigen, dass keine Probleme eingeführt werden.

Sie können dies auf Ihrer örtlichen Workstation ohne Schaden an Ihrem Repository tun.

Ehrlich gesagt, wenn Ihr Management so nicht technisch ist, dass sie Angst vor dem Formatieren von Quellcode haben, zeigt, dass auf der Registerkarte "Probleme nach einem Format" ausreichend sein sollte, um zu zeigen, dass der Code noch in Ordnung ist.

Ganz zu schweigen davon, dass Sie vermutlich die alte Version in der Quellensteuerung markiert haben, oder?

Eine Denkschule könnte sein, es zu tun, ohne zu fragen, und dann "sehen!"

Wenn Sie alles zerstören, werden Sie natürlich gefeuert. Sie treffen Ihre Entscheidungen ...

Alternativ können Sie sie immer wieder zurückrollen.

Wenn Ihr Code nahezu genug 100% Codeabdeckung hat, kann das Risiko ein wenig gesenkt werden.

Selbst wenn das Management zustimmte, dass die Codebasis sicher ist, hätte ich denke, dass sie die Bezahlung eines Mitarbeiters rechtfertigen mussten, um Stunden mit dem neuesten Code zu verbringen, nur um einen Standard zu halten, den (ich vermutete) lange in die Entwicklung eingeführt wurde Lebenszyklus.

Wir verwenden Jalopy hier bei meinem aktuellen Job. Es ist ein ziemlich solides Produkt und erzeugt wirklich ordentliche Ausgabe. Der hochrangigste Entwickler hier formatierte die gesamte Code-Basis, als er sie von CVS nach SVN migrierte, und er musste einige Tests durchführen, um sicherzustellen, dass es von Anfang bis Ende von Anfang bis Ende funktioniert, und jetzt haben wir Hooks, um sicherzustellen, dass das Überprüfungen geprüft wird. im Code ist ordnungsgemäß formatiert.

Davon abgesehen glaube ich nicht, dass Sie jemanden davon überzeugen können, dass ein Tool narren (oder schuldig) Beweise ist, weil es kein solches Werkzeug gibt. Wenn Sie der Meinung sind, dass der Nutzen die Zeit und das (sehr kleine) Risiko wert ist, versuchen Sie, Ihr Management den größten Vorteil zu überzeugen, den Sie dabei sehen. Für mich wird der größte Vorteil kommen, wenn:

Alle Entwickler haben die gleichen Formatierungseinstellungen;
Die Formatierung des Quellcodes wird beim Check-in durch einen Haken in Ihrem SCM überprüft.

Wenn Sie das oben genannte ausführen, sehen Sie, wenn Ihr Code bereits formatiert ist, bei Vergleichen von Überarbeitungen in Ihrem SCM die tatsächlichen Änderungen in der Logik des Programms und nicht nur Änderungen formatieren.

Wenn Sie eine gute Abdeckung des Unit -Tests haben, reichen die Testergebnisse vor und danach aus.

Nur ein spezifischer Heads -Up: Wenn Ihre Unternehmensrichtlinie eine alphabetische Sortierung des Mitglieds enthält, beachten Sie, dass die Reihenfolge der statischen Felder von Bedeutung ist. Wenn Sie also eine Vor-Save- oder Reinigungsregel angeben, die dies erfolgt, können Sie Ihren Code brechen.

Technisch gesehen entfernt Lexer während der ersten Phase der Kompilierung alle Kommentare und Leerzeichen aus der Quelle.Dies geschieht lange bevor der Compiler die Semantik des Codes erkennt.Leerzeichen oder Kommentare können daher nichts an der Programmlogik ändern.Im Gegenteil, welchen Nutzen hätte die Sprache und wer würde sie gerne verwenden, wenn das Hinzufügen einiger Leerzeichen oder Zeilenumbrüche ihre Semantik verändern würde?

Auf geschäftlicher Seite werden Sie dafür wahrscheinlich einige spezielle Tools verwenden.Ich bin sicher, dass sie auf ihren Websites damit werben, dass sie großartig funktionieren.

Schlussbemerkung:Wenn Sie Ihr Management davon überzeugen müssen, sollten Sie vielleicht nach einem Weg suchen, mit klügeren Leuten zusammenzuarbeiten?

Ich würde das Management fragen, was ihre derzeitige Grundlage für die Annahme des Codes ist, und zeigen, dass dasselbe Tool (Tests, Dokumentation, kleine Stimmen ...) genau so gut für den neu formatierten Code funktioniert. Ich möchte, dass ihre Antwort "Tests" sein ...

Ich weiß, dass die vorherigen Antworten in Ordnung sind, aber hier ist ein anderer möglich: mach a CRC auf der kompilierten Version vor und nach einem Reformat. Da das Kompilieren die Räume, Registerkarten, Linefeeds usw. ignorieren würde, sollte die kompilierte Version mit dem Original identisch sein, und dies würde den semi-technischen Managern beweisen, dass alles in Ordnung ist.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow