Zitat von
mbamler:
Zitat von
Mackhack:
Zitat von
mbamler:
und Leute, die penetrant auf dem Thema Styleguide rumreiten verstecken damit meistens nur ihre Unsicherheiten, was die eigentliche Entwicklung angeht.
Das ist ja wohl der duemmste Quatsch den ich je gehoert habe? Was machst denn bei einem Programm mit 500 Fenstern? Merken dass FormX.Button13 ein Cancel Button war oder wie?
Warum sollte Styleguide-Korrektes Arbeiten (und es sei dahingestellt ob du den offiziellen Borland-Styleg. oder einen eigenen nimmst) eine Unsicherheit verstecken. Du kennst doch die Leute ueberhaupt nicht die nach einem Styleguide arbeiten. Hier waere ich also vorsichtig mit solchen Behauptungen.
Wenn du noch "dümmeres" Zeug lesen willst, dann lies dir einfach deine Beiträge durch ...
Man merk sofort, dass du von Softwareentwicklung nun wirklich KEINE Ahnung hast.
Styleguide-Fetischisten sind kleinkarrierte Erbsenzähler, die sich um Unwichtigkeiten kümmern anstatt sich mit dem wesentlichen der Entwicklung zu kümmern
Ich gebe
xaromz recht, diese eine Diskussion auf diesem Niveau sollten wir hier nicht führen.
Trotzdem möchte ich noch mal kurz auf den Sinn solcher Styleguides hindeuten,
da wohl
mbamler noch nie in einem professionellen Umfeld programmiert hat.
In vielen Firmen wird in Teams an Projekten gearbeitet. Das bedeutet, es sind mehr als eine Person, die mit dem Quelltext arbeiten müssen. Oft ist auch die Fluktuation der Mitarbeiter in den Firmen recht hoch. Das bedeutet, dass die Programmierer von Quelltextpassagen oder ganzen Projekten teilweise nicht mehr in der Firma und somit auch nicht mehr ansprechbar sind. Jeder Programmierer hat seinen eigenen Programmierstil. Wenn an einem Projekt mehrere Programmier schreiben und jeder sein Ding durchzieht, wird der Code schnell unübersichtlich und die Wartung wird aufwendiger. Manchmal wird ein Projekt dann auch unwartbar. (z.B. deutsche, englische, indische und französiche Veriablennamen in der selben Anwendung. Wer soll das dann noch verstehen?)
Die Styleguides geben den Programmierer Richtlinien, wie der Code auszusehen hat. Dabei ist es weniger wichtig, für welches StyleGuide man sich entscheidet.
Wichtig ist dass alle im Team den gleichen StyleGuide verwenden. Und zwar durchgehend.
Wir haben hier ein Team von ca. 40 Delphi Entwicklern. Wenn jeder das machen würde, was er wollte, wie kann dann das Team funktionieren. Es sind einige Grundregeln notwendig, damit sich auch die anderen Teammitglieder relativ schnell im Quelltext zurechtfinden.
Man muss es ja nicht übertreiben, aber ein paar Regeln sind manchmal sehr hilfreich.
Das Einhalten von StyleGuides wird in Klassenbibliotheken oder Frameworks noch wichtiger.
Stell Dir mal vor Borland hätte keine StyleGuide für die
VCL gehabt, dann wären solch selbstverständliche Dinge wie die Namen der Properties nicht realisiert.
z.B. die Property Caption beinhaltet immer einen Text, der angezeigt wird.
Delphi-Quellcode:
frmMain.Caption := 'Hauptformular';
lblTest.Caption := 'Test';
myComponent.Caption := 'Test';
ohne den StyleGuide bei der Entwicklung der
VCL wäre vielleicht so was herausgekommen:
Delphi-Quellcode:
frmMain.Title := 'Hauptformular';
lblTest.DisplayText := 'Test';
myComponent.Ueberschrift := 'Test'; // als deutscher Programmierer sind meine Property Namen natürlich auch deutsch.
In diesem Beispiel sieht man auch schön, dass es z.B. auch wichtig ist, sich auf eine Sprache zur Bezeichnung der Variablen zu einigen.
Ich würde nicht verstehen, was ein Inder in indisch benamte Variablen speichert.
Wenn alle Teammitglieder deutsch sind, ist es durchaus Ok Variablen in deutsch zu benamen. Aber dann bitte alle. Sobald das Team international wird, sollte man sich auf Englisch einigen. Da man nie weiß, ob das Team später international wird, werden von vielen Teams gleich alle Benamungen in Englisch gehalten. Das macht die Sache auch einheitlicher, da die
VCL ja auch komplett in Englisch ist.
Auch der Hobbyprogrammierer kann von den Vorteilen profitieren.
Wenn er nach längerer Zeit noch mal an einem seiner Projekte etwas ändern muss, findet er sich in der Regel in einem sauber strukturiertem Quelltext besser zurecht.
Wenn dann auch noch Kommentare verwendet werden, ist es fast perfekt.
Man sollte es aber auch nicht übertreiben.
Ich war mal in einem Team die hatten bis zu 12 Zeichen lange Präfixe vor jedem Objekt / Variable. Das finde ich übertrieben.
z.B.
vparfiCount // Var PARameter einer Funktion vom typ Integer namens COUNT