Wie findet ihr einen solchen Code-Stil?

volkard

Neuling1 schrieb:

Also so i für int und d für double oder p für Pointer

nein.

volkard

Neuling1 schrieb:

Aber ich frage mich ob es nicht übersichtlicher ist alle variablendeklarationen am anfang zu haben als block weil so weiß man ja wo sie zu finden sind immer.

direkt vor der verwendung!

nicht

...
    c=*szPlaintext;
    while (c)
...

und mal schnell oben gucken, sondenr einfach

...
    char c=*szPlaintext;
    while(c)
...

oder wenn man lust hat, noch ein wenig lokaler

...
    while(char c=*szPlaintext)
...

Dravere

Neuling1 schrieb:

..., vorausgesetzt die funktion ist länger, ...

Was sie aber bekanntlich nicht sein sollte
Zudem und da kommen wir zu deiner anderen Frage:

Neuling1 schrieb:

Andere Frage: Benutzt ihr Informationen für eure Variablennamen die euch den Typ verraten? Also so i für int und d für double oder p für Pointer:

Nein, denn der Typ ist meistens nicht wichtig zu wissen. Es ist viel wichtiger, das Konzept vom Typ zu wissen und das sieht man bei der Verwendung.
Zudem kann man das oft gar nicht so genau definieren. Wie machst du sowas bei den Templates? Oder wenn du einen Smartpointer hast, setzt du da ein p davor? Oder ist das dann doch kein Zeiger?

Das einzige was ich mache ist das verpönte m_ vor Klassenvariablen. Aber das ist mehr für mich, weil ich das Gefühl habe, dass es die Übersichtlichkeit erhöht. Aber das ist Geschmacksache.

Grüssli

hartmut1164 schrieb:

Eine Funktion/Methode sollte auch nie laenger sein als eine Bildschirmseite (vielleicht noch zwei).

Mit switch/case Blöcken darfs auch etwas länger sein.

asc

C++Fan 2009 schrieb:

Mit switch/case Blöcken darfs auch etwas länger sein.

Ganz davon abgesehen das man teils mittels OO-Techniken viele switch/case reduzieren oder gänzlich streichen kann, würde ich selbst bei solchen die sich nicht einsparen lassen lieber die Behandlung in Funktionen auslagern.

Auch wenn ich mich selbst nicht 100%ig daran halte, sind Funktions-/Methodenrümpfe die auf eine Bildschirmseite passen deutlich lesbarer, als solche die sehr lang sind - Egal aus welchem Grund. Was das Auge mit einem Blick umfassen kann ist einfach lesbarer. Ist etwa so wie ein Text mit oder ohne einzelnen Abschnitten.

cu André

pumuckl

C++Fan 2009 schrieb:

Mit switch/case Blöcken darfs auch etwas länger sein.

Nur wenn es mehr als halb so viele cases wie Zeilen auf dem Bildschirm gibt.

asc schrieb:

C++Fan 2009 schrieb:

Mit switch/case Blöcken darfs auch etwas länger sein.

Ganz davon abgesehen das man teils mittels OO-Techniken viele switch/case reduzieren oder gänzlich streichen kann, würde ich selbst bei solchen die sich nicht einsparen lassen lieber die Behandlung in Funktionen auslagern.

Wenn man OO benutzt um ein effizientes Sprachmittel wie switch Anweisungen zu umgehen, macht man was falsch.

Shade Of Mine

C++Fan 2009 schrieb:

asc schrieb:

C++Fan 2009 schrieb:

Mit switch/case Blöcken darfs auch etwas länger sein.

Ganz davon abgesehen das man teils mittels OO-Techniken viele switch/case reduzieren oder gänzlich streichen kann, würde ich selbst bei solchen die sich nicht einsparen lassen lieber die Behandlung in Funktionen auslagern.

Wenn man OO benutzt um ein effizientes Sprachmittel wie switch Anweisungen zu umgehen, macht man was falsch.

Nein.

Die meisten switches sind durch dynamisches dispatching ideal zu loesen. Natuerlich gibt es Faelle wo ein switch einfach das beste ist - aber es tut nicht weh vor jedem switch sich darueber gedanken zu machen. Denn idR ist das switch nur eine auspraegung von vergessener dynamik (die nicht zwangslaeufig ueber OO implementiert werden muss).

Shade Of Mine schrieb:

Die meisten switches sind durch dynamisches dispatching ideal zu loesen.

...mit viel mehr sinnlosem Overhead.

Shade Of Mine schrieb:

Denn idR ist das switch nur eine auspraegung von vergessener dynamik.

Kannst Du das genauer darstellen? Was meinst Du mit "vergessener Dynamik"?

volkard

C++Fan 2009 schrieb:

Shade Of Mine schrieb:

Denn idR ist das switch nur eine auspraegung von vergessener dynamik.

Kannst Du das genauer darstellen? Was meinst Du mit "vergessener Dynamik"?

zum beispiel die tastendispatchmonster

switch(key)
{
  case 'X': moveBack(); break;
  case 'A': moveLeft(); break;
  case 'D': moveRight(); break;
...
}

statt

(*keyToAction[key])();

der benutzer wünsch sich doch eh, daß er dynamisch die tasten neuzuweisen kann.

oder

switch(mob.mobType)
{
  case TROLL: runAway(); break;
  case GOBLIN: kill(mob); break;
  case ...
}

aber dafür (zum tun von was bestimmtem abhängig vom typ) gibts virtuelle methoden.

asc

C++Fan 2009 schrieb:

Shade Of Mine schrieb:

Die meisten switches sind durch dynamisches dispatching ideal zu loesen.

...mit viel mehr sinnlosem Overhead.

Zum Einen ist der Overhead meines Erachtens nicht so wesentlich wie du es hier darstellst. Zudem gewinnt man an Flexibilität und Wartbarkeit. Es mag sein das in deinen Anwendung jeder Prozessortakt zählt, aber in meinen Anwendungsbereich ist Geschwindigkeit zwar nicht unwichtig, aber auch nicht das Hauptaugenmerk wenn man mit etwas Overhead ein Programm dafür leicht erweitern und pflegen kann.

Ganz davon abgesehen habe ich schon das ein oder andere Mal erlebt wie der "Overhead" im Endeffekt zu einer höheren Leistung führt. Oder zumindest der Flaschenhals an einer ganz anderen Stelle liegt.

cu André

pumuckl

C++Fan 2009 schrieb:

Shade Of Mine schrieb:

Die meisten switches sind durch dynamisches dispatching ideal zu loesen.

...mit viel mehr sinnlosem Overhead.

Das sind nur ein paar Takte. Und da man solche switches ja nach möglichkeit nur selten durchläuft tut das nicht wirklich weh.

hustbaer

Arrays von Funktionszeigern bzw. Arrays von Zeigern auf Objekte mit virtuellen Memberfunktionen können manchmal sogar schneller sein als switch-Orgien.

Hier einer Variante im Vergleich mit der anderen grundsätzlich "Overhead" zuzuschreiben, halte ich nichtmehr für gewagt, sondern für schlichtweg falsch.

geschweifte Klammern in separaten Zeilen stören die Lesbarkeit, denn diese aus rein syntaktischen Gründen notwendigen Klammern tragen zum Verständnis des Codes nichts bei, also brauchen sie auch keine eigene Zeile. Semikolons spendiert man ja auch keine eigenen Zeilen.

Dravere

u_ser-l schrieb:

..., denn diese aus rein syntaktischen Gründen notwendigen Klammern tragen zum Verständnis des Codes nichts bei, ...

Ehm, doch. Sie sagen dem Leser ganz klar, dass hier ein neuer Block startet und wo er wieder endet. Das erkennen von solchen Blöcken ist extrem wichtig für das Verständnis. Was gehört wozu.

Und wie machst du eigentlich eine schliessende Klammer, wenn nicht auf einer eigenen Zeile?

Aber naja, wie so oft, sowas ist einfach subjektiv

Grüssli

u_ser-l schrieb:

geschweifte Klammern in separaten Zeilen stören die Lesbarkeit, denn diese aus rein syntaktischen Gründen notwendigen Klammern tragen zum Verständnis des Codes nichts bei, also brauchen sie auch keine eigene Zeile. Semikolons spendiert man ja auch keine eigenen Zeilen.

Burschi, du hast auch garnicht kapiert.
Du kannst nicht für jeden Menschen sprechen.

Es ist eine Frage des Charakters, der Gewohnheit. Die Welt ist kompliziert.

Für mich gehört '{' und '}' in eine eigene Zeile, da es einen Block besser hervorhebt.

Hier stört mich, dass dem Funktionsrumpf direkt der Code folgt. Es ist eine gewisse Unübersichtlichkeit da (Ist jetzt wohl nicht das beste Beispiel).

int main() {
    cout << 1 << endl;
}

Hier sieht man den Block genauer. Es ist schöner, perfekter, einheitlicher. Jaja, ich sag doch, es hängt mit dem Charakter zusammen.

int main()
{
    cout << 1 << endl;
}

Also hört auf verdummt zu verallgemeinen, es nervt.

_matze

u_ser-l schrieb:

geschweifte Klammern in separaten Zeilen stören die Lesbarkeit, denn diese aus rein syntaktischen Gründen notwendigen Klammern tragen zum Verständnis des Codes nichts bei, also brauchen sie auch keine eigene Zeile. Semikolons spendiert man ja auch keine eigenen Zeilen.

Seh ich auch so (abgesehen von der schließenden Klammer natürlich). Das jeweilige Schlüsselwort markiert den Blockanfang für mich genausogut wie die Klammer. Ist alles eine Sache des subjektiven Empfindens (und wahrscheinlich der Gewöhnung). Ich kann diesen in die Länge gezogenen Quelltext mit öffnender Klammer in einer Extra-Zeile, den viele hier favorisieren, einfach schlechter lesen...

Dravere schrieb:

Ehm, doch. Sie sagen dem Leser ganz klar, dass hier ein neuer Block startet und wo er wieder endet. Das erkennen von solchen Blöcken ist extrem wichtig für das Verständnis. Was gehört wozu.

Ja, schon - aber wo der Block beginnt und endet zeigt in (fast) jedem mir bekannten Programm die Einrückung an - die geschweifte Klammer ist für die optische Blöcke-Erkennung eher redundantes "syntaktisches Rauschen" (in python bspw. schreibt man sie gar nicht erst, Einrücken reicht). Aber jedem, wie's ihm gefällt.

Xebov

Dravere schrieb:

Sie sagen dem Leser ganz klar, dass hier ein neuer Block startet und wo er wieder endet. Das erkennen von solchen Blöcken ist extrem wichtig für das Verständnis.

Der Meinung bin ich auch, ich setze manchmal sogar sehr gern ne Klammer bei einzeligen ifs um die Übersichtlichkeit zu steigern.

_matze

Xebov schrieb:

ich setze manchmal sogar sehr gern ne Klammer bei einzeligen ifs um die Übersichtlichkeit zu steigern.

Manchmal? Das mach ich immer (nur eben nicht mit öffnender Klammer in einer eigenen Zeile ). Ich mag diese Ein-Zeilen-Dinger gar nicht...