Eure Programmierkonventionen ?

[:)]

Original erstellt von Gregor:
[quote]Original erstellt von <;)>:
[qb]dann muss man aber schon ziemlich viel getrunken haben ...

Nö! Man muss nur ne IDE/Editor mit ner anderen Tab-Breite nutzen. Schon sieht der Code so aus.[/QB][/QUOTE]
standard ist 4 leerzeichen, sonnst würde es zu schnell über den bildschirm rand gehen. da kann der ordentliche programmierer aber nichts dafür

[Gregor]

Original erstellt von <:)>:
**
standard ist 4 leerzeichen, sonnst würde es zu schnell über den bildschirm rand gehen. da kann der ordentliche programmierer aber nichts dafür**

4 Leerzeichen? Bei Tabs hast du keine Leerzeichen. Du hast nur ne Breite, die normalerweise 8 ist.

[:)]

ich meine eine breite die 4 leerzeichen entspricht und die ist, wenn ich mich nicht irre, standard mäßig 4.

[Gast]

standard mäßig 4.

[Gregor]

mäßig 4

...hört sich wie ne Schulnote an!

Diese Breite ist nicht Standardisiert. Jede IDE hat da andere Voreinstellungen. Bei Dev-C++ ist es glaube ich eine Breite von 2. Der Windows-Editor macht Tabs so breit, wie 8 Leerzeichen. Ich habe bei der IDE, die ich nutze, eingestellt, dass er ein Tab durch 3 Leerzeichen ersetzen soll. Würde ich mit Tabs arbeiten, dann hätten sie ne Breite von 3.

[ Dieser Beitrag wurde am 28.11.2002 um 22:32 Uhr von Gregor editiert. ]

[davie]

Dann arbeite halt mit Tabs und mit Leerzeichen...

[ordenlicher ide]

ordentliche ide bieten die funktion "tabs in leerzeichen umwandeln"

[rüdiger]

also ich benutzer immer eindeutige Funktions oder Variablennamen, zumindest meistens (außer i und j, das benutz ich immer als iterator). Von der ungarischen Notation halte ich überhauptnichts, genauso wie vom großschreiben von Bezeichnern ich schreibe die eigentlich immer klein. m_ als Präfix für Member Variablen nutze ich auch seltener, falls sich mal eine lokale Variable/Argument mit dem Namen eines Members überschneided, kann man dieser meistens leicht _ anhängen oder zur Not per this-><bez> oder <classe>::<bez> drauf zugreifen.

Und ich versuche keine C Casts zu benutzen, sondern C++ Casts.

Als Dateiendung nehmen ich *.cc und *.hh, ich benutze 2 Leerzeichen (also lasse die Tabs durch 2 Leerzeichen ersetzen :))

[DrGreenthumb]

Du schreibst Bezeichner nicht groß?
Dann kann man ja garnicht sowas machen:

Window window;

Zuert fand ich tabs auch immer besser. Bis ich rausgefunden hab das man vim auch beibringen kann das er 3 Leerzeichen wie Tabs behandelt. Seitdem hab ich weniger Arbeit mit meinem Quellcode

[Marc++us]

Original erstellt von kingruedi:
kann man dieser meistens leicht _ anhängen oder

Das ist ja auch sowas... ich weiß nicht wie die großen Geister auf diese Idee kamen. Was lese ich als erstes bei einem Bezeichner? Das erste Zeichen. Und wo hängen die Jungs die Markierung dran? Am Ende.

Verstehe ich nicht, leuchtet mir nicht ein. Am Anfang macht in meinen Augen Sinn, aber das am Ende? Von jeher war es üblich mit Prefixes in Bezeichner zu arbeiten, wenn man irgendeine Symbolik in die Namen einführen wollte. Höchste Priorität oder Namenszugehörigkeit stand immer im Prefix. Und nun wird plötzlich ein Postfix im Namen eingeführt.

[Gerard]

das _ am ende erkennt man doch bevor man den ersten buchstaben gelessen hat,

[Marc++us]

Ehrlich? Beim Buch lese ich ja auch den Schluß zuerst... aber bei den Bezeichnern...

[Daniel E.]

Original erstellt von Marc++us:
**Was lese ich als erstes bei einem Bezeichner? Das erste Zeichen. Und wo hängen die Jungs die Markierung dran? Am Ende.
**

Man macht es hinten dran, _damit_ man den Text so lesen kann, wie man gerne geschrieben hätte, nämlich ohne Kennzeichung. Man _soll_ es also 'überlesen'. Konstruktionen wie Class::member oder this->member machen mehr Arbeit als member_.
IMHO.

DrGreenthumb: Wieso denn?

// C++
struct foo {};
void bar () { foo foo; }

Ist legal.

Gregor: Jap, ich hab' mich wiederholt, hab das allerdings mit noch 2 Minuten vor deinem Post bearbeitet :).

[DrGreenthumb]

// C++
struct foo {};
void bar () { foo foo; }

Ist legal.

Ich bin erschüttert...

Ok, das geht tatsächlich. Aber ich schreib meine Klassen trotzdem lieber groß

[Meinungsfrage]

@Marc++us: Was meinst du eigentlich zu der Tab und Leerzeichengeschichte? Was benutzt du?

[Gerard]

Original erstellt von Marc++us:
Ehrlich? Beim Buch lese ich ja auch den Schluß zuerst... aber bei den Bezeichnern...

kuckt man sich nicht automatisch erst das gesamt bild des wortes an?

[Marc++us]

Original erstellt von <Meinungsfrage>:
@Marc++us: Was meinst du eigentlich zu der Tab und Leerzeichengeschichte? Was benutzt du?

3 Blanks statt Tab. Mein Vorteil ist, daß ich das verbindlich für alle in der Firma festlegen kann.

Aber das ist eigentlich ein Nicht-Thema, das mit Programmierkonventionen gar nichts zu tun hat. Eine Lizenz z.B. für den frei konfigurierbaren SourceStyler kostet 300$ und formatiert jeden Quelltext (einschließlich der {}-Debatte) so um wie gewünscht. Formatierungen sind eigentlich kein wesentlicher Inhalt für eine Programmierkonvention.

Solche Themen wie Namensgebung halte ich für wichtiger.

[Shade Of Mine]

zu { und }
In der C Bibel steht: egal ob
foo() {
oder
foo()
{

Hauptache immer gleich.

[Blue-Tiger]

also ich verwende für die Klammern den "Allman style", sprich

void bla()
{
}

"K&R style" (also bla(){ ) find ich zu unübersichtlich.......

sonstige Konventionen:

Variablen-, Funktions- und alle anderen möglichen Namen werden aus dem Englischen Abgeleitet, nicht aus dem Deutschen.

Kommentare auch in Englisch (brech ich ab und an für kleinere Projekte - mein engl. ist nicht ganz so doll), und VIELE Kommentare (manche sagen ich kommentiere zu viel), meistens vor jedem längeren Block ein Kommentar, was dieser Block überhaupt macht (quasi eine Überschrift).

Variablennamen beginnen mit einer 1-Buchstaben-Abkürzung ihres Datentypes, z. b. "iIrgendwas" für einen Integer..... Außnahme sind Variablen für for-Schleifen, die meistens beliebige Kleinbuchstaben aus dem Alphabet sind.

gleiches gilt für Konstanten, die anstonsten Groß geschrieben werden

Funktionen ("Fitzelarbeiten" wie getBla()und sonstiger Kleinram natürlich nicht) erhalten nach dem Funktionskopf eine Beschreibung ihrer selbst, inkl. Parameter und Rückgabewert. (will auch beginnen, Nebeneffekte zu kommentieren)

überleg

ach ja, für kleinere Projekte: ich benutze Prototypen, die erste eigentliche Funktion im Quelltext ist immer main, alles andere (z. B. main steht ganz am Ende, auf Prototypen wird komplett verzichtet) ist mehr als nur unübersichtlich, IMHO

[rüdiger]

Also ich kommentiere auch immer in Englisch. Ich kommentiere aber sehr wenig, da ich denke, dass zu viele Kommentare eher überflüssig sind und man lieber den Code eindeutiger schreiben sollte, die meisten Kommentare verweisen bei mir auf das was noch zu tun ist (fangen mit einem [TODO] an) oder mit Warnungen, wo es später hacken könnte (fangen mit [warning] an), dann kann man einfach mit eingem grep die entsprechenden Zeilen auslesen.

@Marc++us
aber führende _ sind dem Compiler vorbehalten, da bleibt mir nur ein _ am ende, aber da ich das nur für Parameter mal benutze, finde ich es nicht alzu schlimm.

indent ist auch ein Programm zum umformatieren von Source Code, aber Open Source.