Präfixe, unsignierte Variablen, ungarische Notation - Umsteiger braucht Hilfe



  • Hehe... Genau wie der alte Thread, der hier irgendwo verlinkt wurde 🙂
    Ich lese hier schon wieder ganz dezent raus:
    "UN ist ja auch nur für _große_ Projekte"
    "sinnvolle Variablenbenennung ist nötig, also ist UN gut"

    Es geht den meisten hier aber IMHO nicht darum, dass UN zu wenig Nutzen bringt, um die Extra-Tipparbeit zu rechtfertigen - sondern darum, dass sie sogar *schadet* und damit in jeder Hinsicht unsinnig ist.



  • Nonsense schrieb:

    Kann ich Euch in Eurer netten Flame-Runde mal kurz unterbrechen? 😃
    Kann mir jemand mal ein paar Source-Codes geben, in denen kurz und prägnant eine "vernünftige" Variablen\Klassen\Methoden-Benennung erkennbar ist (Bitte überschaubar)?
    Danke. 😉 🙂

    class Switcher { 
    public: 
    	Switcher() : state(false) { 
    	} 
    	void toggle() { 
    		state = !state; 
    	} 
    	bool isSet() const { 
    		return state; 
    	} 
    private: 
    	bool state; 
    };
    

    EDIT: Kleine Änderung



  • *heul* Gerade zu die Büchse der Pandora.
    Womit habe ich das nur verdient *schnief* ? 😃
    Ich möchte doch nur ein paar kleine Beispiele für gute Schreibweise haben. Bitte, bitte... 🤡
    Danach könnt ihr ja weiter flamen und plonken. :p 😉

    Edit:
    @MaSTaH: Danke. Und wie sieht's mit Variablen aus?



  • EDIT: Kleine Änderung oben. state wurde zu isSet und der Variablenname heißt state



  • MaSTaH schrieb:

    state_ ist eine Variable. Man könnte sich jetzt noch streiten ob man state ein sinnvoller Funktionsname in dem Zusammenhang ist.

    Aber ich denke nicht, dass alle Variablen mit einem "_" enden sollten, oder? Und wie sieht es mit Variablen aus, die aus mehreren Wörtern bestehen?

    Achso: wie machen das eigentlich die Linuxer unter Euch?





  • Hab ich nur gemacht weil ich ne Funktion state hatte. Hab die dann aber sinnvollerweise in isSet umbenannt. Den Unterstrich oder ein m_ als Prefix machen viele auch um zu zeigen, dass es sich um ein class-member handelt. Habs aber editiert.



  • state schrieb:

    http://fara.cs.uni-potsdam.de/~kaufmann/?page=cpp2html

    Stimmt, Humes Style neigt zur Perfektion. Hab mir den komplette Sourcecode irgendwann mal angesehen. Müsste auch irgendwo auf seiner Seite liegen.



  • state schrieb:

    http://fara.cs.uni-potsdam.de/~kaufmann/?page=cpp2html

    @app.cpp:

    TheApp::TheApp()
    	: inStream_(&cin)
    	, outStream_(&cout)
    	, producer_(0)
    	, analyzer_(0)
    	, cpp2HtmlOptions_(0)
    {}
    

    Ist aber irgendwie strange -> Wieso Doppelpunkt und Komma nicht hinter den Variablen?

    TheApp::~TheApp()
    

    Ist ~TheApp der Dekonstructor?



  • Nonsense schrieb:

    Und wie sieht es mit Variablen aus, die aus mehreren Wörtern bestehen?

    bool whatAWonderfulDay; 😉



  • MaSTaH schrieb:

    Nonsense schrieb:

    Und wie sieht es mit Variablen aus, die aus mehreren Wörtern bestehen?

    bool whatAWonderfulDay; 😉

    Die OP-Variante gefällt mir da aber besser. Naja, was soll's? 😃



  • Nonsense schrieb:

    TheApp::TheApp()
    	: inStream_(&cin)
    	, outStream_(&cout)
    	, producer_(0)
    	, analyzer_(0)
    	, cpp2HtmlOptions_(0)
    {}
    

    Ist aber irgendwie strange -> Wieso Doppelpunkt und Komma nicht hinter den Variablen?

    Weil das ne Konstruktorinitialisierungsliste ist. Gehört übrigens auch zum guten Ton, da performanter als Initialisierung im Konstruktorrumpf. Das mit dem Komma ist Geschmackssache wohin das gehört. Mache es persönlich auch lieber hinter die Initialisierung.



  • MaSTaH schrieb:

    Weil das ne Konstruktorinitialisierungsliste ist. Gehört übrigens auch zum guten Ton, da performanter als Initialisierung im Konstruktorrumpf. Das mit dem Komma ist Geschmackssache wohin das gehört. Mache es persönlich auch lieber hinter die Initialisierung.

    Dann wird ja sicher irgendwo eine Liste geben, wo der komplette "gute Ton" beschrieben ist, oder? 😃



  • An die wenigen noch übrigen UN-Vertreter: Macht doch mal vorschläge für die ungarische Notation:

    for (std::vector<Signal>::iterator it=stream.begin(), it!=stream.end(); ++it) {
       ...
    }
    

    Sollte ich statt it lieber std_vector_signal_iterator_it schreiben oder svsiIt oder wie?
    Welches Präfix würdet ihr für mein Audio::Filter_lowpass<float> oder Audio::Filter_bandpass<float> vorschlagen? Was für VST_helper::Parameter_mapper?

    Ich hätte noch millionn von Typen, bei denen ich dann gerne Vorschläge hätte. Ich hab einfach irgendein Projekt geöffnet und irgendwelche Typen genommen, die vorkamen.



  • Oh man, die ungarische Notation ist doch nur für primitive Datentypen bestimmt.



  • bool whatAWonderfulDay;

    ich finde diese Groß/Klein-Schreibung schlimm. Für getSize() o.ä. mag das ja noch klar definiert sein, aber wenn die Leute dann mit WindowHandle oder BlumenTopf anfangen, machts echt keinen Spaß mehr.



  • primitiv schrieb:

    Oh man, die ungarische Notation ist doch nur für primitive Datentypen bestimmt.

    In C++ unterscheidet man semantisch aber nicht zwischen primitiven Datentypen und 'Klassen'.

    Denn

    int64 i64=31;
    i64++;
    i64+=10;
    cout<<i64;
    

    Ich weiss, dass die Ausgabe 42 lautet.
    Ob int64 jetzt nur ein typedef auf __int64, long long, etc. ist oder aber eine Klasse fuer grosse Zahlen ist doch egal, oder?



  • @Shade: Das bestätigt doch nur, daß die UN in C++ keinen Sinn (mehr) macht, oder?



  • Cocaine schrieb:

    @Shade: Das bestätigt doch nur, daß die UN in C++ keinen Sinn (mehr) macht, oder?

    Das war ja auch der Zweck des Posts.



  • Nonsense schrieb:

    Dann wird ja sicher irgendwo eine Liste geben, wo der komplette "gute Ton" beschrieben ist, oder? 😃

    Nein, aber Foren in denen er gepredigt wird 😃 .


Anmelden zum Antworten