Bezeichnungen - Euer stil

[finix]

volkard schrieb:

SystemError(DWORD _error){
        error=_error;
    }

habe mich da ans _ gewöhnt und habe auch keine probleme. es kommt auch nur in konstruktoren vor.

Ach so. Ich hab's genau anders herum verstanden, a la

SystemError(DWORD error){
        _error=error;
    }

Ich heb mir nämlich die "schönen" Bezeichner für den Clientcode & die Doku auf
Nur bezüglich "kommt nur in Konstruktoren vor" - was ist mit

void SystemError::setError(DWORD error);

Aber das UN-Argument (:lofl:) gegen UPPERCASE_KONSTANTEN hat schon was für sich.. auf jeden Fall für Templates.

[Jester]

volkard schrieb:

typ-prafixe haben den gravierenden nachteil, daß man sie ändern müßte, wenn man den typ ändert

Das ist leider leider nicht ganz richtig. Das eigentliche Problem dabei ist doch: Man muß sie nicht ändern, wenn man den Typ ändert. Das heißt: bei der nächsten Typänderung werden die Namen nicht mitgeändert ("Das mache ich später").
Würde der Compiler das erzwingen, dann wäre diese Quelle von Wartungsproblemen wenigstens ausgeschlossen.

Es ist also schlimmer: Man müßte eigentlich, wird aber nichtmal gezwungen (bzw. erinnert).

[Brutus]

Finix, was ist so schlimm daran, nach der Funktion ein Leerzeichen zu lassen und dann erst die Klammer zu schreiben? Habe ich bisher immer so gemacht, genauso wie bei if/while/for und so. Oder ist so etwas denn unschön?

[richtig !]

ja !

[Brutus]

naja, was daran jetzt "unschöner" sein soll, versteh ich nicht, ehrlich gesagt

[finix]

Brutus schrieb:

Finix, was ist so schlimm daran, nach der Funktion ein Leerzeichen zu lassen und dann erst die Klammer zu schreiben? Habe ich bisher immer so gemacht, genauso wie bei if/while/for und so. Oder ist so etwas denn unschön?

Falsch: foo (bar)
Richtig: foo(bar)

Falsch: if(foo)
Richtig: if (foo)

Falsch: Finix
Richtig: finix

Bis auf #3 natürlich größtenteils... Glaubensfrage

[Brutus]

am satzanfang schreibt man klein, soso, naja, werd ich mir merken..
ich habe dich wohl missverstanden, es dachte es geht um:

int foobar(asdf) {
  return
}

Also, dass es besser ist, die geschweifte Klammer direkt an die ')' Klammer zu setzen, wie hier:

int foobar(asdf){
  return
}

Obwohl ich sagen muss, dass ich das 2. öfters sehe (Faulheit, Leertaste zu drücken?)

[volkard]

finix schrieb:

Ich heb mir nämlich die "schönen" Bezeichner für den Clientcode & die Doku auf

der client merkt doch garnicht, welche bezeichner ich intern nehmen. nur bei automatisch erstellter doku ist ein unterstrich in der schnittstelle. aber wie gesagt, selten.

Nur bezüglich "kommt nur in Konstruktoren vor" - was ist mit

void SystemError::setError(DWORD error);

der code ist für mich undenkbar.
die ganze klasse sieht so aus:

class SystemError:public Error{
private:
    DWORD error;
public:
    SystemError(DWORD _error){
        error=_error;
    }
    void printAt(Writer& out) const{
        Size const size=256;
        char buffer[size];
        DWORD len=FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM,0,error,0,buffer,size,0);
        if(len==0)
            out<<"SystemError "<<error;
        out<<buffer;
    }
};

und dazu gehören noch

void raiseSystemError(){
    throw SystemError(GetLastError());
}
#define SYSCHECK(condition) if((condition));else raiseSystemError()

und die linux-version.
ich glaube, im aktuellen code habe ich noch gar keine set-funktion. nichtmal mein Vector kann auf benutzerwunsch resizen. würde eh nicht mehr bringen, als wenn sich der benutzer nen neuen größeren Vector besorgt (ich denke noch nicht an realloc).
naja, seit langer zeit ahre ich gant gut mit

void SystemError::setError(DWORD _error);

oder besser gesagt auch mal

void SystemError::setError(DWORD e){
   error=e;
}

und keinem weiteren kommentar. kollisionen kommen, wenn ich mich recht erinnere, nicht nur sehr selten vor, sondern noch dazu in sehr simplen funktionen.

Aber das UN-Argument (:lofl:) gegen UPPERCASE_KONSTANTEN hat schon was für sich.. auf jeden Fall für Templates.

naja. wenn schon, denn schon. was macht man mit PI und SQRT2? wie in java in den namespace math stecken? die leute schreiben eh using namespac math;, wenn man das macht.

[finix]

volkard schrieb:

finix schrieb:

Ich heb mir nämlich die "schönen" Bezeichner für den Clientcode & die Doku auf

der client merkt doch garnicht, welche bezeichner ich intern nehmen. nur bei automatisch erstellter doku ist ein unterstrich in der schnittstelle. aber wie gesagt, selten.

Ja, Clientcode war eine Recht ungeschickte & falsche Formulierung: meinte den für den Client sichtbaren Code, den Header. Und davon ab find ich Doxygen ganz nett.

[rüdiger]

Zum Thema Typkennungen in Bezeichnern.
Der Sinn eines Typ-Präfix soll ja die schnelle Erkennbarkeit des entsprechenden Typs erlauben. Dies ist aber ziemlich schwachsinnig, zum einen besteht ein OO Programm eh aus eigenen Typen (Klassen) und man müsste nun auch für Objekte eine entsprechende Notation einführen, was dafür sorgt, dass die Notation komplett projektabhängig ist. Dies macht den Code schlecht wartbar, da man sich jedesmal mit einer Projekteigenen Notation vertraut machen müsste.

Aber was viel schlimmer ist, dass Typ-Präfixe keinen wirklichen Mehrwert bringen. Eine Variable hat ja ein bestimmten Designzweck, von dem man sich den Typ eigentlich ableiten kann. Wenn ich eine Variable counter habe (btw. ich schreib Variblen (so wie das meiste) komplett klein), dann ist es wohl aus der reinen Logik her klar, dass die Variable einen Integralen Typ haben wird und Operationen ala ++ und -- erlaubt sind. iCounter bringt mir keinen Mehrwert, da es um die Policy geht und nicht um den Typ.

Ein Typ-Präfix bedeutet auch, dass man den Typ explizit kennen muss, wie soll man ansonsten darauf kommen, welche Variable welches Präfix besitzt? Bei counter kann mir der Typ egal sein, solange er die Policy erfüllt. Bei iCounter muss die Variable nicht nur in die Policy passen ich muss konkret wissen, dass die Variable vom Typ int ist, da ich ja sonst nicht weiß, dass die Variable iCounter heißt.

Und da man den Typ selten nachschlagen muss und Variablennamen häufiger benutzt, ist das doch ein Unverhältnis zwischen Nachschlagen des Variablennamens und Naschlagen des Typs.

Selbst die größten Vertretter von Typkennungen (Microsoft) empfehlen diese ja nicht mehr!

[User--]

Das Thema kommt mir sehr gelegen, denn ich musste feststellen, dass fast jeder die camel notation verwendet (ich selbst auch), jedoch habe ich in letzter Zeit auch ein wenig mit der underscore notation, wie sie ja die standard lib verwendet, geliebäugelt und in einem aktuellen (kleineren) Projekt mal eingesetzt und irgendwie sagt mir diese sogar sehr zu.

Aber was mich interressiert ist, wieso sie so gut wie niemand verwendet, obwohl sie der standard zB. hat

[Windows-User]

Underscore benutzen nur Linux-User.

[otze]

@User--

underscores neigen dazu den Code unübersichtlich zu machen. Auch wenn mein Code nicht wirklich eine Schönheit ist, bemerke ich schon eine gewisse unlesbarkeit des codes mit underscores. Liegt wahrscheinlich daran, dass man besser mit reinem text klarkommt als mit Text der mit Sonderzeichen zugemüllt ist.

aber mal ne andre Stilfrage:
Die Stl hat ja für Container einige Konventionen getroffen, zb dass man auf die Iteratoren mittels begin() und end() zugreifen kann. Oder dass der Typ des Iterators im Typedef iterator bzw const_iterator bereitgestellt wird.

Nun ist es aber so, dass die eigenen Code Conventionen dahin gehen zb getBegin() zu schreiben, oder das Iterator Typedef Iterator und ConstIterator zu nennen. Sollte man sich nun der Stl wiedersetzen, und seine Code Konvention durchsetzen, oder sollte man sich der Einheitlichkeit zuliebe anpassen?

[Gast]

finix schrieb:

Falsch: foo (bar)
Richtig: foo(bar)

Falsch: if(foo)
Richtig: if (foo)

Falsch: Finix
Richtig: finix

Wieso? Was hast du an meinem if( foo ) auszusetzen? Irgendwann habe ich mal erkannt, dass die Klammern beim Lesen einfach nur stören, wenn sie am Ausdruck angrenzen, insbesondere, wenn im Ausdruck selber Klammern vorkommen. Ein

if( myCar->isDamaged() )

ist bestimmt nicht schlechter lesbar als

if (myCar->isDamaged())

Man könnte ja auch mal ein

if (something  >  x * (y + getValue()))

haben. Jetzt kann mir keiner mehr erzählen, dass das nicht ugly ist.
Du magst auch deine Gründe haben, aber von "richtig" und "falsch" zu sprechen halte ich für gewagt.

[Gast]

net schrieb:

ich finde das am besten: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

Die sind für mich gestorben. Die wollen mir mein if anders vorschreiben als ich es mag. Außerdem kann ich

Note: if statements always use braces {}. Avoid the following error-prone form:

if (condition) //AVOID! THIS OMITS THE BRACES {}!
    statement;

definitiv nicht zustimmen. Unnötige Klammern sind hässlich und unübersichtlich. Zwar ist es wahrscheinlich nicht so schlimm, wenn man die öffnende noch auf der selben Zeile beginnt. Aber andererseits habe ich noch nie einen Fehler wegen einem if ohne { } gemacht.

Die Namensgebung laut Java-Konvention finde ich allerdings wieder gut. Die beinhaltet dann auch so Sachen, die volkard schon angesprochen hat, z.B. dass Methoden Verben sein sollten.

[volkard]

otze schrieb:

Nun ist es aber so, dass die eigenen Code Conventionen dahin gehen zb getBegin() zu schreiben, oder das Iterator Typedef Iterator und ConstIterator zu nennen. Sollte man sich nun der Stl wiedersetzen, und seine Code Konvention durchsetzen, oder sollte man sich der Einheitlichkeit zuliebe anpassen?

wenn du die stl auch benutzen willst, anpassen.
ich wende mich von ihr ganz ab und darf machen, was ich will.

[finix]

Optimizer schrieb:

finix schrieb:

Falsch: foo (bar)
Richtig: foo(bar)

Falsch: if(foo)
Richtig: if (foo)

Falsch: Finix
Richtig: finix

Wieso? Was hast du an meinem if( foo ) auszusetzen? Irgendwann habe ich mal erkannt, dass die Klammern beim Lesen einfach nur stören, wenn sie am Ausdruck angrenzen, insbesondere, wenn im Ausdruck selber Klammern vorkommen. Ein

if( myCar->isDamaged() )

ist bestimmt nicht schlechter lesbar als

if (myCar->isDamaged())

Man könnte ja auch mal ein

if (something  >  x * (y + getValue()))

haben. Jetzt kann mir keiner mehr erzählen, dass das nicht ugly ist.
Du magst auch deine Gründe haben, aber von "richtig" und "falsch" zu sprechen halte ich für gewagt.

Jetzt hast du 2 Dinge unzulässig verquickt. Mir ging es allein um das Leerzeichen zwischen if und (, nicht um ( und expression.

Bezüglich "richtig" und "falsch": ich habe in beiden Posts von 'Glaubensfragen' geschrieben, oder?
(Obwohl in der Tat ersteres - in meinen Augen - in der Tat & offensichtlich schlechter zu lesen ist.)

[Redhead]

User-- schrieb:

Das Thema kommt mir sehr gelegen, denn ich musste feststellen, dass fast jeder die camel notation verwendet (ich selbst auch), jedoch habe ich in letzter Zeit auch ein wenig mit der underscore notation, wie sie ja die standard lib verwendet, geliebäugelt und in einem aktuellen (kleineren) Projekt mal eingesetzt und irgendwie sagt mir diese sogar sehr zu.

Aber was mich interressiert ist, wieso sie so gut wie niemand verwendet, obwohl sie der standard zB. hat

ISO/IEC 9899:1999 schrieb:

7.1.3 Reserved identifiers
1 Each header declares or defines all identifiers listed in its associated subclause, and
optionally declares or defines identifiers listed in its associated future library directions
subclause and identifiers which are always reserved either for any use or for use as file
scope identifiers.
— All identifiers that begin with an underscore and either an uppercase letter or another
underscore are always reserved for any use.

[Brutus]

Es ging um so etwas:

void my_sex_machine();
// statt
void mySexMachine();

und nicht um sowas:

__sex_machine bla;

[Verwundert]

ISO/IEC 9899:1999 schrieb:

7.1.3 Reserved identifiers
1 Each header declares or defines all identifiers listed in its associated subclause, and
optionally declares or defines identifiers listed in its associated future library directions
subclause and identifiers which are always reserved either for any use or for use as file
scope identifiers.
— All identifiers that begin with an underscore and either an uppercase letter or another
underscore are always reserved for any use.

Ist das nicht a) die falsche Pappe? Dies ist doch hier C++, und nucht C, und da gilt ja wohl ISO/IEC 14882-1998 respektive 2003, und da ist sind Bezeichner mit einem Unterstrich gefolgt von kleinem Buchstaben nicht reserved (wenn auch nicht empfohlen) und b) da auf stl werwiesen wurde, geht es hier wohl eher um Unterstriche innerhalb von Identifiern und nicht zu Beginn, also weiss ich gerade garnicht womit das was zu tun haben soll?