Klassenpräfixe

Vor allem, wenn man Typen immer groß schreibt und Namen von Funktionen und Instanzen immer klein, ist das trotzdem immer noch sehr wichtig, zu wissen, ob es ein Interface oder eine Klasse ist. Für die Benutzung eines Objekts oder einer Klasse ist das unglaublich wichtig.

Achja, Ironie ende.

Walli

Thanatos schrieb:

1.) Als jemand der selbst programmiert nervt mich die Verwendung solcher Präfixe, andererseits hat mir das bei der Durchsicht fremder Quellcodes schon oft geholfen...

Inwiefern?

Thanatos schrieb:

3.) Für wie sachlich oder wissensbasiert hälst du denn nachfolgendes Posting ?
Shade Of Mine schrieb:

godlikebot schrieb:
Aber warum ist das schlechter Stil? Gehts dabei nur darum, dass das 'C' schlecht ist oder sollte man Klassenprefixe generell vermeiden?

C im speziellen ist extrem mies. T dito. Alles andere ist einfach nur normal mies.

Sachlich ja, von Seiten des Verfassers auch wissensbasiert. Der Beitrag bringt allerdings keine Argumente, doch wenn ich mich richtig erinnere hat Shade daraufhin den Link zu einem Topic und einem eigenen Artikel gepostet, in dem das Thema schon abgehandelt wurde.

Shade Of Mine

Thanatos schrieb:

3.) Für wie sachlich oder wissensbasiert hälst du denn nachfolgendes Posting ?
Shade Of Mine schrieb:

godlikebot schrieb:
Aber warum ist das schlechter Stil? Gehts dabei nur darum, dass das 'C' schlecht ist oder sollte man Klassenprefixe generell vermeiden?

C im speziellen ist extrem mies. T dito. Alles andere ist einfach nur normal mies.

Für ziemlich.
Schließlich habe ich direkt einen link gepostet und nachher noch einen zweiten.

wenn du willst kannst du meinen artikel gerne zerpflücken - wir können die einzelnen argumente gerne ausdiskutieren.

aber ich habe erst 2 jahre berufserfahrung - deshalb kann ich da wahrscheinlich nicht mitreden, oder?

HumeSikkins

Thanatos schrieb:

Bekanntestes Schema ist immer noch die ungarische Notation.

"Die ungarische Notation" gibt es in der Realität nicht (die gibt's eigentlich nur auf dem Papier und ist damit hauptsächlich für Schüler oder Studenten interessant). Charles Simonyi hat zwar mal eine sehr detaillierte Namenskonvention aufgestellt, die dann als "ungarische Notation" bekannt wurde, aber in der Praxis gibt es unzählige Derivate. Es gibt unzählige Variationen in der Benennung der Basisbestandteile. Hinzukommend verwenden nicht mal alle alle drei Basisbestandteille (base type, prefixes, qualifiers).

Nach aktuellen Stand werden bei den meisten Firmen Namenskonventionen bevorzugt.

Eine Firma ohne Namneskonventionen ist entweder sehr sehr klein oder unprofessionell, da unnötig unproduktiv.
Die Tatsache, dass man Namenskonventionen verwendet hat aber natürlich keinen direkten Zusammenhang mit der ungarischen Notation. Diese ist ja nur eine mögliche Ausprägung einer Namenskonvention. Es gibt so ca. 1.763 Milliarden andere Namenskonventionen.

Auf die Gewohnheiten die sich im Lauf der Zeit eingeschliffen haben, hat man als Newcomer sowieso keinen Einfluss. Also heisst es, damit zu Leben.

Sehe ich ganz genauso. Eine Konvention an die sich jeder nur nach gutdünken hält ist sinnlos. Allerdins war die Frage nicht "ich arbeite als Newcomer bei IBM. Die verwenden dort Klassenpräfixe. Da ich die hässlich finde, wollte ich jetzt mal den gesamten Code umschreiben und dann die Chefs davon überzeugen Klassenpräfixe zu verbieten. Ist das eine gute Idee?"
Der OP scheint ja erstmal für sich persönlich einen Weg zu suchen. Und wenn ich nicht gezwungen bin mit Präfixen wie C oder I zu arbeiten, gibt es auch überhaupt keinen Grund dafür sich freiwillig damit zu quälen.

Und es gibt wahrhaft schlimmeres als Namenskonventionen mögen sie zuerst auch noch so ungewohnt sein.

Wie heißt es doch so schön: Gute Variablennamen sind das A und O der Programmlesbarkeit. Da sich Namenskonventionen nun mal mit der Benennung von Variablen beschäftigen sind gute Namenskonventionen ein außerordentlich erstrebenswertes Ziel.

Schüler oder Studenten ohne langjährige Berufserfahrung sollten vielleicht nicht ganz so absolut in ihren "Glaubengrundsätzen sein".

Warum nur Schüler oder Studenten? Kann ich jetzt daraus schließen, dass Menschen mit langjähriger Berufserfahrung ruhig absolut sein dürfen. Oder geht es sogar nochweiter: Was für Schüler und Studenten nur maximal "Glaubensgrundsätze" sein können, sind für Berufshelden längst objektiv anzuerkennende Fakten. Wenn du also sagst:

Mich persönlich haben solche Präfix-Konventionen beim Einarbeiten in fremde Quellcodes schon häufig unterstützt

dann muss die Welt dies als fundiertes Argumente hinnehmen wohingegen
ein von einem Schüler/Student vorgetragenes

C im speziellen ist extrem mies. T dito. Alles andere ist einfach nur normal mies

nur ein "Glaubensgrundsatz" mit absolutistischem Anspruch ist, dass dringend in Frage gestellt werden muss.

Merkwürdig das.

Hi HumeSikkins,

inzwischen habe mir auch mal den von Shade of Mine angegebenen Thread angesehen. Hätte ich das zuerst getan hätte ich mir jeden Kommentar verkniffen. Darum ist das hier auch mein Schlusswort.

Zum Schlussabschnitt deinee letzten Kommentars. Ich sehe da sehr wohl einen Unterschied. wenn ich schreibe:

Mir persönlich hat...

Dann geb ich damit, ziemlich deutlich hoffentlich zum Ausdruch, das etwas ganz allein meine persönlich Meinung zu etwas darstellt und ganz gewiss kein Glaubensgrundsatz ist.
demgegenüber find ich nicht sehr sachlich oder argumentatativ zu schreiben.
[url]C im speziellen ist extrem mies. T dito. Alles andere ist einfach nur normal mies[/url]
Ob nun mit oder ohne beigefügtem Link würde ich das als Leser für die Verkündigung einer absoluten Wahrheit halten.

Und wenn ich mit dieser Interpretation auch allein stehen sollte, wird die Welt auch davon nicht untergehen. Servus

HumeSikkins

@Thanatos
Mit der Form der zitierten Aussage von Shade gewinnt man sicher keinen Oscar, da sind wir uns einig. Und auch der Inhalt ist zwar extrem reduziert, bleibt auf der anderen Seite aber letztlich noch korrekt.
Das Ganze zeigt imo ein generelles Problem in Foren: Entweder du diskutierst bestimmte Themen jedes Mal von vorne neu oder du schreibst bei der siebenhundertsten Wiederholung auch mal einen kurzen provokativen Satz der ein Wort wie 'Käse' oder 'Mies' enthält (am Besten mit einem zusätzlichen Link auf eine alte Diskussion). Immer mit der Hoffnung, dass neue Leser sich danach selbst ein wenig schlau machen bzw. an bestimmten Punkten einfach nachfragen.

godlikebot

Spricht eigentlich auch was gegen ein "m_" vor Membervariablen von Klassen?

Man nimmt ein _ als Suffix.

beispiel_;

godlikebot

C++ Guru schrieb:

Man nimmt ein _ als Suffix.

beispiel_;

Und warum nicht "m_" als präfix?
Das klingt so schön nach member

nman

godlikebot schrieb:

Spricht eigentlich auch was gegen ein "m_" vor Membervariablen von Klassen?

Naja, beim Programmieren ist das im Regelfall unangenehmer als ein _ am Ende, von wegen Code Completion und so...

operator void

Andererseits finde ich "bla_->" und "bla_." immer recht hässlich.
Was man hier als Markierung nimmt (oder ob man überhaupt eine nimmt), ist wohl Geschmackssache. Zumindest kann ich mich nicht an eine überwältigende Argumentation für eine Variante erinnern. Ich war mit allem eigentlich gleich zufrieden

KPC

Ich hab mir mMembervariable angewöhnt, das ist übersichtlich und kann man schön schnell tippen.

HumeSikkins

operator void schrieb:

Was man hier als Markierung nimmt (oder ob man überhaupt eine nimmt), ist wohl Geschmackssache.

Wobei das "was" imo deutlich mehr Geschmacksache ist als das "ob". Das "ob" sollte man imo zumindest deutlich intensiver diskutieren.
Was man am Ende dann für eine Markierung nimmt spielt eine untergeordnete Rolle.

Helium

Ne, man macht sa so:

class MyClass {
   struct M {
      Foo foo;
   } m;

   void foo (Foo value)
   {
      m.foo = value;
   }
   ...
};

godlikebot schrieb:

Spricht eigentlich auch was gegen ein "m_" vor Membervariablen von Klassen?

Spricht eigentlich was dafür?? Das sind doch die selben fadenscheinigen Gründe wie für CAuto.

operator void

Wenn man seine Funktionen lieber size() als getSize() nennt, spricht schon mal eine ganze Menge dafür - allerdings wird mich die Verben-Fraktion dafür gleich toasten.
Ansonsten muss man entscheiden, ob man lieber this-> nimmt, wenn man eine Kollision mit einem Parameter hat, oder konsequent ein Präfix/Postfix tippt.

otze

operator void schrieb:

Ansonsten muss man entscheiden, ob man lieber this-> nimmt, wenn man eine Kollision mit einem Parameter hat, oder konsequent ein Präfix/Postfix tippt.

membervariablen werden bei mir immer am anfang klein geschrieben, parameter immer groß(inklusive template parameter),damit erspar ich mir jegliches unschönes this->

Kollision mit Parameter gibt es bei mir eigentlich so gut wie nie. Ich verwende meistens die Initialisierliste und das macht er dann wunderbar.

ClassName(int size)  :
    size(size)        {}

Und bei setter-Methoden heißen die Parameter dann meistens irgendwie newSize oder so.

operator void

otze schrieb:

membervariablen werden bei mir immer am anfang klein geschrieben, parameter immer groß(inklusive template parameter),damit erspar ich mir jegliches unschönes this->

Damit hast du für Parameter und Typen aber die selbe Konvention, für Parameter und Variablen (dje ja im Prinzip das Gleiche sind) nicht mehr. Das verwirrt zumindest dann, wenn man GroßeKlassen undKleinenRest gewöhnt ist. Und man hat wieder das lustige Problem:

void flipMap(Map& Map); // Juhu!

Da kann man dann entweder den Parameter bei Bedarf doch präfixen oder anfangen, sich Synonyme auszudenken. Und gerade Letzteres macht einfach keinen Spaß, auch wenn es auf den ersten Blick lesbar und natürlich aussieht.

otze

void flipMap(Map& Map);

damit hab ich keine probleme