Name von Membervariabeln



  • So kurz wie möglich, so lang wie nötig!



  • m_ member
    p_ parameter
    g_ globale
    s_ statics

    warum - in der Praixs gibt es viel saubereren, neuen, schlechten und fiesen Code
    also braucht man Strategien um jeden Code über die Zeit verbessern zu können (oder ihn auf diesen Zustand vorzubereiten), dazu gehört z.B. auch das schrumpfen von Funktionen usw. - Software wächst immer organisch - egal wie idealistisch man selbst oder die Entwickler um einen herum sind (Zeitdruck, Unerfahrenheit, Menge an Projekten usw. ergeben das irgendwann automatisch - aber bitte nicht mit Faulheit/fehlendem Interesse verwechseln das ist immer scheisse)

    die wenigsten dieser allgm. Tips gelten für Ich-mache-immer-alles-alleine und sonstige Anfänger-Kodierer - und die haben meistens auch keine Ahnung warum Sie irgendwelche dieser Tips anwenden oder nicht - es fehlt die Erfahrung



  • Gast3 schrieb:

    m_ member //unnötig
    p_ parameter //unnötig
    g_ globale //kommt eh nicht vor
    s_ statics //beides

    Gast3 schrieb:

    warum - in der Praixs gibt es viel saubereren, neuen, schlechten und fiesen Code also braucht man Strategien um jeden Code über die Zeit verbessern zu können

    Ich übersetze: "Ich schreibe viel schlechten Code und bin völlig ratlos. Deshalb suche ich Zuflucht in mystischen Ritualen."

    Gast3 schrieb:

    die wenigsten dieser allgm. Tips gelten für Ich-mache-immer-alles-alleine und sonstige Anfänger-Kodierer - und die haben meistens auch keine Ahnung warum Sie irgendwelche dieser Tips anwenden oder nicht - es fehlt die Erfahrung

    Wichtiger Bestandteil: Alle, die nicht zu meiner Sekte gehören, sind lächerlich dumm und kommen ganz sicher in die Hölle.

    Hängt natürlich davon ab, was man proggert und wo und mit was. Mit einer c++-ähnlichen Sprache, die Properties kann, ist m_ fein, damit die Properties die feinen Namen kriegen können. Bei viel GUI-Code kann man m_ oder p_ wählen (beide zusammen ist nicht nötig), um bei den vielen gettern/settern keine Kollissionen mehr zu haben. s_ kann ich mir nicht vorstellen. "g_game" wurde zu "theGame".



  • Also ich lass mir Sachen wie Parameter oder Member Variablen einfach von der IDE als solche highlighten. Parameter grau (bzw. orange wenn sie nicht benutzt werden) und Member Variablen dunkelrot, statics unterstrichen und virtual kursiv.

    Finde ich 1000 mal übersichtlicher und intuitiver als mit Präfixen zu arbeiten. Vor allem wenn man irgendwelche Klassen mit mathematischen Gleichungen hat, bei denen das Präfix dann genauso lang wäre wie der Bezeichner selbst.

    Blöd ists natürlich bei Mehrdeutigkeiten, aber da finde ich einen Unterstrich am Ende des Bezeichners noch als kleinstes Übel.



  • happystudent schrieb:

    Also ich lass mir Sachen wie Parameter oder Member Variablen einfach von der IDE als solche highlighten. Parameter grau (bzw. orange wenn sie nicht benutzt werden) und Member Variablen dunkelrot, statics unterstrichen und virtual kursiv.

    Welche IDE (und Add-Ons) nutzt du?



  • Zur Zeit Qt-Creator in der Uni (keine Ahnung ob da Add-Ons dabei sind^^).

    Ansonsten privat benutz ich Visual Studio 2013 (ohne Add-Ons), da kann man sich das auch alles seperat highlighten lassen bis auf virtuelle Methoden. Aber das Highlighting für virtual braucht man auch nicht wirklich mMn. Wichtig für mich ist gesondertes highlighting für Member, Parameter und statische Sachen. Und das funktioniert wunderbar in VS.



  • @volkard

    ich verdiene mein Geld primär und schon über 10 Jahre mit Refaktoring/Überarbeitung von größeren C/C++ Projekten - also ~400kLOC und ein paar Jahre und Entwickler auf dem Buckel - da sieht man einfach alles was falsch, böse und schlecht ist und Mannmonate an Überarbeitung bedürfen, die Strategien die man sich dabei angewöhnt sind eher pragmatischer Natur - funktionieren aber auch sehr gut bei der Grüne-Wiese Entwicklung

    (m|p|s|)_ ist

    1. sehr einfach zu parsen/generieren wenn man mal selbst Code-Veränderungstools braucht, nicht immer sind alle guten Tools verfüg- oder anwendbar

    2. man kann das in jedem neuen Team relativ schneller erklären und so die Verbesserbarkeit des Kodes beschleunigen - Entwicklungen werden ja nicht gestoppt nur weil man etwas schöner macht

    Erfahrene Entwickler adaptieren alles was hilft - unerfahrene argumentieren sehr viel, oder sagen sachen wie "das finde ich nicht schön"...



  • Gast3 schrieb:

    @volkard
    ich verdiene mein Geld primär und schon über 10 Jahre mit Refaktoring/Überarbeitung von größeren C/C++ Projekten

    Oh, ein Jungspund. Na, erwarte keine Widerrede mehr von mir, das hab ich oft genug gehabt.

    Gast3 schrieb:

    Erfahrene Entwickler adaptieren alles was hilft - unerfahrene argumentieren sehr viel, oder sagen sachen wie "das finde ich nicht schön"...

    Haste UN loslassen können? Klar adaptierst Du alles, auch Wünschelruten, ich sage doch nichts anderes.



  • hustbaer schrieb:

    Erstmal ist "max. 7 Zeilen" unpraktikabel. Ich weiss auch nicht wo du die Zahl her hast.

    Von Java. Gibt so ein Java Buch über "schönen" Code, und da fands der Autor ganz toll, dass er mal ein Projekt gesehen hat, wo jede Funktion nur 3-4 Zeilen hatte.
    Finde ich völlig sinnlos. Natürlich sollte man nicht übertreiben und hunderte Zeilen in eine Funktion stecken. Aber wenn man eine Funktion in zig Hilfsfunktionen aufteilt, sieht man nicht was passiert und muss nur ständig zwischen Hilftsfunktionen hin und herspringen, ganz davon zu schweigen, dass man viele Parameter rumreichen muss.

    happystudent schrieb:

    Also ich lass mir Sachen wie Parameter oder Member Variablen einfach von der IDE als solche highlighten.

    Das hilft schon mal, aber ich verlass mich nicht gern auf IDE Hilfsmittel. Wir können unseren Code online durchsuchen, da will ich auch sehen, was da verwendet wird. Und ich mach Code Dateien auch gern mal mit Notepad++ auf. Unter Linux hab ich früher sowieso nur vim benutzt, weil mich keine IDE überzeugt hatte.
    Und ich bezweifle sehr stark, dass eine IDE bei umfangreichem, komplexem C++ Code die verschiedenen Variablentypen auseinanderhalten kann. Die Intellisense und Visual Assist steigen bei mir ständig aus.



  • Mechanics schrieb:

    Das hilft schon mal, aber ich verlass mich nicht gern auf IDE Hilfsmittel. Wir können unseren Code online durchsuchen, da will ich auch sehen, was da verwendet wird. Und ich mach Code Dateien auch gern mal mit Notepad++ auf. Unter Linux hab ich früher sowieso nur vim benutzt, weil mich keine IDE überzeugt hatte.

    Naja, also ohne IDE kann (ich zumindest) nicht wirklich effizient arbeiten, man verliert ohne Auto-completion doch einfach sehr viel Zeit mit nachschauen (was ohne ein Jump-to-declaration auch noch ewig dauert). Ich überflieg auch mal online Code, aber wenn ich wirklich damit arbeiten will dann zieh ich mir den eh und bearbeite ihn in einer vernünftigen IDE...

    Mechanics schrieb:

    Und ich bezweifle sehr stark, dass eine IDE bei umfangreichem, komplexem C++ Code die verschiedenen Variablentypen auseinanderhalten kann. Die Intellisense und Visual Assist steigen bei mir ständig aus.

    Also das mit den Variablentypen habe ich bis jetzt noch nicht als Problem erlebt... Es stimmt schon dass bei großen Projekten das Intellisense anfängt zu laggen (was auch ziemlich nerven kann), aber korrekt gehighlighted wurde bis jetzt eigentlich schon immer alles bei mir.



  • Also mein Qt-Creator hält die Variabeln schön farblich auseinander, kein Grund da mit Zusätzen zu arbeiten. Ich denke mal jede andere moderne IDE wird dies auch so tun.



  • IDEFinder schrieb:

    Also mein Qt-Creator hält die Variabeln schön farblich auseinander, kein Grund da mit Zusätzen zu arbeiten. Ich denke mal jede andere moderne IDE wird dies auch so tun.

    Das ist ein gutes Argument, und so ziemlich das einzige was ich gelten lasse 🙂
    Die IDE mit der wir arbeiten tut das nicht, von daher verwenden wir Prefixe.


Anmelden zum Antworten