Hi. Welchen Programmierstil benutzt ihr und wieso benutzt ihr gerade diesen? Habt ihr Tipps, wie man selbst große Projekte übersichtlich halten kann?
Druckbare Version
Hi. Welchen Programmierstil benutzt ihr und wieso benutzt ihr gerade diesen? Habt ihr Tipps, wie man selbst große Projekte übersichtlich halten kann?
Naja, ich benutze QBasic als Programmiersprache, da greift man gerne (oder weil man keine andere Wahl hat^^) auf Methoden zurück, mit der ich mich eigentlich in meinen eigenen Quellcodes gut zurechtfinden kann:
- Oberste Regel: GOTOs vermeiden
- Alles, was öfter als einmal aufgerufen wird, in eine SUB (Unterprogramm) oder FUNCTION packen
- Dimensionen von Variablen (sowohl für Dateien als auch für Grafiken - und selbst diese noch getrennt) kommen immer an erster Stelle im Quellcode vor, und nicht wild im Quellcode zusammengewürfelt
- Lieber eine IF/THEN/ELSE-Struktur als eine CASE/END CASE-Struktur
- Jede SUB bzw. jede FUNCTION enthält mindestens drei Zeilen Kommentar, das die Funktionsweise erklärt
- Ich mache auch mal eine SUB, die von Programm aus niemals aufgerufen wird, aber in Kommentaren alle Variablen, die vorkommen, erklärt. Man kann dann in diese SUB schauen, falls man mal die Funktionsweise einer Variable vergessen hat
Tjoa, Tipps kann ich nur geben: Alle Variablen und das ganze andere Zeugs sollte man einen sinnvollen Namen geben, nicht jede Variable mit "tmp1% tmp2% tmp3%" etc. benennen^^.
Und dann noch Tipps für's eigentliche Programmieren: Niemals drauflos programmieren, sondern sich schon vorher Gedanken machen: Wie soll welcher Programmteil ablaufen?
Tjoa, ähm... mehr fällt mir nicht ein^^.
Meine Bibel zum thema Syntaxdesign in Delphi ;)
Ist alles super erklärt und wenn man sich daran hält kann fasst nix mehr schief gehen :D
Gibt es sowas auch für C++?Zitat:
Original geschrieben von Freezy
Meine Bibel zum thema Syntaxdesign in Delphi ;)
Ist alles super erklärt und wenn man sich daran hält kann fasst nix mehr schief gehen :D
Ich versuche beim Programmieren mich immer schon an die Coding Conventions der Hersteller zu halten, und möglichst kompatibel zu den Klassenbibliotheken zu entwickeln.
Meine Java-Klassen sind deshalb auch im Package [FONT=courier new]org.silbergrau[/FONT], und in C# eben in [FONT=courier new]Org.Silbergrau[/FONT] :D
Das gilt vor allem bei den Namenskonvetionen und Schreibweisen... in Java ist das eben hauptsächlich der Camel-Stil (ausser dem ersten Buchstaben wird jeder Wortbeginn groß geschrieben: soZumBeispiel..), in C# der Pascal-Stil (DasWärDannSo :)). Konstanten in Großbuchstaben...
Bei C, bzw. C++ gibts ja keine offiziellen Styleguides, deshalb hab ich mich so ziemlich an die Java Konventionen gehalten... was ich überhaupt nicht leiden kann, ist wenn jemand Methodennamen mit underbraces schreibt, also so_zum_beispiel, wirklich eklig.
Was die Formatierung angeht... wie gesagt, die Styleguides, und vor allem
- Tabulatoren maximal 4 minimal 2 Zeichen
- nach jedem größeren Block (if, while, ...) eine leere Zeile
- wenn möglich Statements inline schreiben, bei langen bedingungen nur einen Zeilenschritt reinhauen
Achja, bei VHDL übernimmt das Formatieren ja der electric mode bei Emacs, auch nicht schlecht :D
Ansonsten viell. für interessierte noch ein paar Links:
Java Style Guide
C# Style Guide
ein C++ Style Guide
Mal sehen, welche Regeln befolge ich...?
1.) Variablen sind camelCased, Funktionen sind PascalCased.
Beispiele: eineVariable, EineFunktion()
2.) Variablen, die irgendeinen tieferen Sinn haben und nicht nur für drei Zeilen als temporärer Datenspeicher herhalten, haben als Präfix ihren Datentyp.
Beispiel: int intEineGanzzahl
2a.) Wenn es sich um Arrays handelt wird das kenntlich gemacht: char* achrEineZeichenfolge
2b.) Eine Ausnahme wird gemacht, wenn es sich im Inkrementalwerte für Schleifen handelt; diese werden mit einzelnen Buchstaben von i ansteigend bezeichnet: int i, j, k
2c.) Variablen, die nur drei Zeilen lang gebraucht werden haben nichtssagende Namen.
3.) Mein Einrückstil ist eine Abwandlung des Allman-Stils. Klammern haben immer ihre eigenen Zeilen; es wird pro Ebene mit einem Space eingerückt.
3a.) Tab (\t) wird nach Möglichkeit vermieden. Ich verlasse mich darauf, daß alles so eingerückt ist, wie ich es eingerückt habe und das ist bei \t nicht gewährleistet, da seine Breite systemabhängig ist.Code:int Beispiel()
{
if (true)
{
return (0);
}
}
3b.) Ich hasse 1TBS und entferne ihn, wenn ich Fremdcode verwende.
3c.) Das Gleiche gilt für überflüssige Einrückung (mehr als ein Space pro Ebene).
4.) Längere Kommentare werden mit /* */ gemacht, wobei die erst Zeile des Kommentars mit dem /* auf einer Zeile ist. Das macht den Code unter KWrite mit Collapsing besser navigierbar.
5.) Ich benutze Leerzeichen, um logische Blöcke innerhalb einer Funktion voneinander zu trennen.
5a.) Sehr lange Bedingungsketten werden auf mehrere Zeilen verteilt, wobei versucht wird, in jede Zeile eine logische Gruppe zu legen.
6.) (C++) Erst kommen globale Variablendeklarationen und Funktionesdeklarationen, dann der eigentliche Code.
7.) (C++) Sichergehen, daß das Programm sich nicht beenden kann, ohne einen Rückgabewert zu liefern. Selbst, wenn es z.B. nicht möglich sein sollte, daß das Programm das Ende von main() erreicht wird ein Rückgabewert definiert. Der Rückgabewert für ein Ende unter unmöglichen Voraussetzungen ist 255.
8.) (PHP) Wenn per GET oder POST Parameter übergeben werden include ich grundsätzlich ein kleines Skript, das die Parameter superglobal-unabhängig in ein anderes Array lädt.
Pascal casing mach ich nur in C#-Methoden, rein aus Code-Konformität, ansonsten ist wie gesagt alles camel, ausser Java-Klassennamen (oh, packages sind natürlich alles lower-case)Zitat:
Original geschrieben von Jesus_666
Mal sehen, welche Regeln befolge ich...?
1.) Variablen sind camelCased, Funktionen sind PascalCased.
Beispiele: eineVariable, EineFunktion()
gleich eine beliebte Streitfrage... deklarierst du alle deinen Schleifenzähler zu Beginn, oder deklarierst du sie auch wenn nötig in der Schleife selbst, also z.B.: for(int i...) (was ja unter C nicht möglich ist...)Zitat:
2b.) Eine Ausnahme wird gemacht, wenn es sich im Inkrementalwerte für Schleifen handelt; diese werden mit einzelnen Buchstaben von i ansteigend bezeichnet: int i, j, k
Ach schmarrn... Wie breit ein Tabulator einrücken soll lass ich mir von Kate, Textpad, Emacs oder Eclipse sagen, und hab dann egal welche Quellen ich öffne, immer das gleiche Bild vor Augen (darum gehts dann auch in Konventionen)... wenn ich allerdings Code erweitere, den jemand mit Leerzeichen vollgepumpt hat, muss schlimm umformatiert werden (ganz zu schweigen von Block-Einrückungen, Shift-Tab ist nun doch in allen wichtigen Editoren vorhanden...).Zitat:
3a.) Tab (\t) wird nach Möglichkeit vermieden. Ich verlasse mich darauf, daß alles so eingerückt ist, wie ich es eingerückt habe und das ist bei \t nicht gewährleistet, da seine Breite systemabhängig ist.
Klasse natürlich, wenn man Emacs verwendet, dann braucht man sich um die Einrückungen nicht mehr sorgen... (ich will immer noch einen electric-mode für C!!!)
Ich hab lange Allman programmiert, bis mir der Code dann zu lange geworden ist... in einigen C-Programmen verwende ich es immer noch... bei C++ und Java bin ich allerdings schon lange auf 1TBS umgestiegen, einfach weils IMO ein schöneres Bild gibt...Zitat:
bei C# und Java halt ich mich an die Konventionen (obwohl ich mich mit dem /// xml-doc von C# nicht anfreunden kann :rolleyes: ), da ich kaum C++ kodiere, bleibt mir beim C-Programmieren ja nur /* */ :) )Zitat:
4.) Längere Kommentare werden mit /* */ gemacht, wobei die erst Zeile des Kommentars mit dem /* auf einer Zeile ist. Das macht den Code unter KWrite mit Collapsing besser navigierbar.
Da fällt mir wieder eine alte Streitfrage ein:Zitat:
5.) Ich benutze Leerzeichen, um logische Blöcke innerhalb einer Funktion voneinander zu trennen.
if(yours>mine) { swap(yours,mine); }
oder
if(yours > mine) { swap(yours,mine); }
(bitte nur das fettmarkierte beachten :) )
In der Schleife. Ich weiß, es ist schlechter Stil, wenn man eine Schleife über i laufen läßt und dann in der nächsten Schleife mit for (int j = 0; j < i; j++) weitermacht, aber ich mache das unter PHP die ganze Zeit. Sollte ich mir abgewöhnen.Zitat:
Original geschrieben von MuadDib
gleich eine beliebte Streitfrage... deklarierst du alle deinen Schleifenzähler zu Beginn, oder deklarierst du sie auch wenn nötig in der Schleife selbst, also z.B.: for(int i...) (was ja unter C nicht möglich ist...)
Ich muß ab und zu den selben Code un KWrite und Notepad bearbeiten und habe dann (abgesehen von CRLF) das Problem, daß die beiden offenbar unterschliedliche Ansichten von der Breite von \t haben. Ich könnte zwar KWrite an Notepads Standard anpassen, das würde aber koordiniertes Umbooten erfordern, wozu ich zu faul bin...Zitat:
Ach schmarrn... Wie breit ein Tabulator einrücken soll lass ich mir von Kate, Textpad, Emacs oder Eclipse sagen, und hab dann egal welche Quellen ich öffne, immer das gleiche Bild vor Augen (darum gehts dann auch in Konventionen)... wenn ich allerdings Code erweitere, den jemand mit Leerzeichen vollgepumpt hat, muss schlimm umformatiert werden (ganz zu schweigen von Block-Einrückungen, Shift-Tab ist nun doch in allen wichtigen Editoren vorhanden...).
Klasse natürlich, wenn man Emacs verwendet, dann braucht man sich um die Einrückungen nicht mehr sorgen... (ich will immer noch einen electric-mode für C!!!)
1TBS reibt sich mit der Art, in der ich geklammerte Strukturen geistig verarbeite. { ist für mich etwas anderes als die Deklaration und hat - von Leerfunktionen abgesehen - eigentlich nichts auf der gleichen Zeile zu suchen. Das ist so, als ob ich zwei Befehle in der gleichen Zeile hätte.Zitat:
Ich hab lange Allman programmiert, bis mir der Code dann zu lange geworden ist... in einigen C-Programmen verwende ich es immer noch... bei C++ und Java bin ich allerdings schon lange auf 1TBS umgestiegen, einfach weils IMO ein schöneres Bild gibt...
Ich dazu übergegangen, Leerzeichen zwischen den Variablen zu machen. Ist IMO lesbarer.Zitat:
Da fällt mir wieder eine alte Streitfrage ein:
if(yours>mine) { swap(yours,mine); }
oder
if(yours > mine) { swap(yours,mine); }[/B]
BTW, Formatierungsdiskussionen sind okay, aber keine Flamewars, wie sie teilweise daraus entstehen. Wenn die Sprache verschiedene Formatierungen erlaubt, dann sind sie eben alle legitim.
Abgesehen davon programmieren Echte Programmierer sowieso nur in FORTRAN und Assembler, also soll sich die heutige Coderwelt mal nicht so großtun. *g*