Stilfrage: C als Präfix für Klassen

[Kauz01]

@HumeSikkins

Einige von euch tun so, als ob Präfix == Professionell und alles andere gleich Hobby wäre. Dazu noch so gönnerhaft nach dem Motto: "Ach naja, solange man nur Spielzeugprogrammierung macht, ist das alles egal. Wenn ihr dann aber mal groß seit und professionell in einer so tollen Firma programmiert wie ich, dann werdet ihr einsehen, dass mein Weg der einzig logische ist."

Ich verstehe deine Einschätzung nicht. Ich hatte nicht das Gefühl, als ob sich hier irgendwer als extrem professionell darstellen will. Jeder hat über seine Erfahrungen berichtet. Die meinen sind halt so. Hätte ich einen anderen Programmierstil und würde ich meine Methoden kurz genug programmieren (Gruß an Volkard), dann tendierte die Notwendigkeit von Präfixen und ungarischer Notation gegen Null. Natürlich nur, wenn ich mich auch auf meine Kollegen verlassen kann.

hr vergesst dabei aber ein wenig, dass die Sutters, Meyers', Volkards, Martins, Alexandrescus... dieser Welt ebenfalls professionell programmieren.

Das vergesse ich sicher nicht. Vor dem Wissen Volkards kann ich sicher nicht bestehen. Werde ich auch nie können, da ich mich in meiner Arbeit oft mehr um das kümmern muss, was wir programmieren, als um das wie. Das heißt aber nicht, dass ich keinerlei Erfahrung in der Programmierung habe. Wie gesagt: Diese Erfahrung muss sich nicht mit den Erfahrungen anderer decken. Imho geht es aber etwas zu weit, wenn es schon als überheblich angesehen wird, seine eigene Meinung zu präsentieren.

[HumeSikkins]

Ich hatte nicht das Gefühl, als ob sich hier irgendwer als extrem professionell darstellen will.

Na dann kann einer von uns beiden nicht sonderlich gut lesen. Ich lese das aus nahezu jedem Beitrag von DocJunioR heraus. Aber ich habe auch eine Rechtschreibschwäche. Vielleicht ist die Leseschwäche da nicht weit.

Vor dem Wissen Volkards kann ich sicher nicht bestehen. Werde ich auch nie können, da ich mich in meiner Arbeit oft mehr um das kümmern muss, was wir programmieren, als um das wie. Das heißt aber nicht, dass ich keinerlei Erfahrung in der Programmierung habe. Wie gesagt: Diese Erfahrung muss sich nicht mit den Erfahrungen anderer decken. Imho geht es aber etwas zu weit, wenn es schon als überheblich angesehen wird, seine eigene Meinung zu präsentieren.

Scheinbar kann ich nicht nur nicht lesen sondern auch nicht schreiben. Ich habe nicht denjenigen als überheblich angesehen, der seine Meinung kund tut sondern denjenigen als gönnerhaft, der so Großmutterhaft daher redet.

Und btw. Es geht hier überhaupt nicht um Erfahrung. Erfahrung kann schließlich in vielerlei Hinsicht auch hinderlich sein. Nimm einen erfahrenen C Programmierer und versuche ihm ordentliches C++ beizubringen. Da stört die Erfahrung mehr als das sie nützt.

[klausmuell]

[ Dieser Beitrag wurde am 21.03.2003 um 23:18 Uhr von klausmuell editiert. ]

[groovemaster]

Erster Beitrag und gleich *edit*. Find ich geil.
Naja, muss einfach auch mal meinen Senf dazugeben. Wer schonmal professionell in einer Firma gearbeitet hat der weiss, dass man einfach gewisse Namenskonventionen braucht. Dass diese einem nicht immer gefallen, kann da durchaus vorkommen. Nun hat man die Möglichkeit dies zu ändern oder auch nicht. Jedenfalls kann ich aus eigener Erfahrung sagen, dass dies selten Erfolg hat, da wie schon jemand sagte oft die Devise gilt "never change a winning team". Auch wenn "winning team == uralt Programmierung" bedeutet. Persönlich nutze ich so gut wie gar keine Präfixe. Der Name muss aussagen worum es sich handelt bzw. was ES macht, ich will ja nicht wissen wann und wie ES geboren wurde oder auf welche Schule ES ging. Nur in ganz seltenen Fällen nutze ich noch Präfixe, zB bei Zeiger Variablen, also

p_anzahl_autos

Hier weiss ich sofort, dass es sich nicht direkt um die Anzahl der Autos handelt, sondern lediglich um einen Zeiger darauf. In C nutze ich noch h_ für Handle, da diese eine Art Objekte darstellen mit eigenem Interface. In C++ sind das ja Klassen und damit unnötig. Das wars dann aber auch schon mit den Präfixen.
Absolut genial finde ich solche Sachen:

typedef struct {
  int xyz32_ein;
  int xyz32_paar;
  int xyz32_struktur;
  int xyz32_variablen;
} XYZ32;

No comment!
Das gleiche bei Klassen Membern (m_ *lol*).
Ich will ja hier niemandem zu nahe treten, aber ich hab so das Gefühl, dass manche ihre Quellcodes mit Notepad schreiben. Jede ordentliche IDE bringt doch Features mit, um schnell zu bestimmen welchen Typ eine Variable hat, wo sie definiert ist, wo sie verwendet wird, etc. Da muss ich doch sowas nicht im Variablennamen verschlüsseln. Ich benutze zB MSVC 6.0 mit Visual Assist (supi Tool!), will damit nicht sagen dass es das beste ist wo gibt, bin aber völlig zufrieden damit. Nur ab und zu muss ich feststellen, dass MS einige spezifische Dinge eingebaut hat *verwundernmichdastutehnichtmehr*. So wird hier bei der Erstellung einer neuen Klasse über das Menü das C Präfix berücksichtigt.
Und wenn jetzt einer anfängt zu behaupten er müsse Präfixe verwenden, weil er uU auch mal in einem billigen Editor was nachschauen muss, kann ich nur sagen: VERSORG DIR 'NE ANSTÄNDIGE IDE!
Ich denke es reicht Namen grob mit Hilfe von Gross- und Kleinschreibung zu unterscheiden. So mach ich es zB:
EIN_DEFINE
EINE_REINE_C_STRUKTUR
EineGlobaleVariable
EineFunktion
EineKlasse
eine_lokale_variable
ein_struktur_member
Absolute bzw. globale Sachen also gross oder als Capital, relative bzw. lokale Sachen klein (für Anregungen oder Verbesserungsvorschläge hab ich durchaus ein offenes Ohr).
Letztendlich muss jeder selbst entscheiden, ob und wie er Namenskonventionen benutzt. Nur sollte man sich ab und zu fragen, ob es tatsächlich einen Sinn hat was man. Manchmal ist es besser mit der Zeit zu gehen auch wenn dies vielleicht einige Überwindung kostet.

Nochwas zu dieser i == 0 Geschichte. Semantisch mag beides, also i == 0 und 0 == i korrekt sein, syntaktisch jedoch denke ich sollte man i == 0 immer den Vorzug geben. Nicht umsonst kann ein x86 Prozessor dies

cmp [i], 0

verarbeiten, dies aber nicht

cmp 0, [i]

[Gerard]

Original erstellt von groovemaster2002:
**Nochwas zu dieser i == 0 Geschichte. Semantisch mag beides, also i == 0 und 0 == i korrekt sein, syntaktisch jedoch denke ich sollte man i == 0 immer den Vorzug geben. Nicht umsonst kann ein x86 Prozessor dies

cmp [i], 0

verarbeiten, dies aber nicht

cmp 0, [i]

**

auf c++ ebene ist das aber egal und da rum gehts hier.
Ich glaube ihr seid blos 0 == i weil ihr es als anfänger anders gelernt habt und fast nie ein i = 0 statt i == 0 geschrieben habt.

[groovemaster]

auf c++ ebene ist das aber egal und da rum gehts hier

Wusste gar nicht, dass wir uns im C++ Forum befinden. Mein Browser zeigt jedenfalls "Rund um die Programmierung" an.

Ich glaube ihr seid blos 0 == i weil ihr es als anfänger anders gelernt habt und fast nie ein i = 0 statt i == 0 geschrieben habt.

Dazu kann ich nur sagen, dass ich seit über 12 Jahren programmiere, Assembler, C und bin jetzt dabei die Mysterien von C++ zu erforschen. Vor 4 Jahren wurde dann aus Hobby der Beruf. Da denk ich kann man nicht mehr von Anfänger sprechen. Und mit der Begründung, die hier schon jemand gebracht hat, dass eine Warnung bei i = 0 im Getümmel von X Warnungen untergeht, der sollte besser mal versuchen ein Programm so zu schreiben, wo weder Fehler noch Warnungen entstehen (JA, das ist doch tatsächlich möglich ). Schliesslich will ich mich nicht um jede Unzulänglichkeit bezüglich Fehlervorbeugung kümmern müssen, da will ich mich voll und ganz auf meinen Compiler verlassen.

[Gerard]

Original erstellt von groovemaster2002:
Dazu kann ich nur sagen, dass ich seit über 12 Jahren programmiere, Assembler, C und bin jetzt dabei die Mysterien von C++ zu erforschen. Vor 4 Jahren wurde dann aus Hobby der Beruf. Da denk ich kann man nicht mehr von Anfänger sprechen.

das du jetzt anfänger bist will ich damit nicht sagen, ich meine als du es mal warst

Original erstellt von groovemaster2002:
Und mit der Begründung, die hier schon jemand gebracht hat, dass eine Warnung bei i = 0 im Getümmel von X Warnungen untergeht, der sollte besser mal versuchen ein Programm so zu schreiben, wo weder Fehler noch Warnungen entstehen (JA, das ist doch tatsächlich möglich ). Schliesslich will ich mich nicht um jede Unzulänglichkeit bezüglich Fehlervorbeugung kümmern müssen, da will ich mich voll und ganz auf meinen Compiler verlassen.

jup und auch wenn man fremd header und libs benutzt gibt es z.b. beim msvc ein nettes #pragma

#pragma warning( push, 3 )
#include <irgendwas.h>
#pragma warning( push, 4 )

int main()
{
    int i = 0;
    if(i = 0);
}

[Daniel E.]

Original erstellt von groovemaster2002:
Ich denke es reicht Namen grob mit Hilfe von Gross- und Kleinschreibung zu unterscheiden.

Das ist in deutschen Texten so üblich, ja. Ist auch extrem praktisch, weil ich dann Texte schön schnell überfliegen kann (die meisten Menschen lesen dann nur die Wörter die mit einem Großbuchstaben beginnen, weil Deutsch im Gegensatz zum Englischen eine eher 'Substantiv-Basierte' Sprache ist), aber genau das sollte man mit Progammcode nicht(!) machen.
Das 'Problem' liegt bei C++, weil dort einige Programmteile nicht lokal interpretierbar sind: 'a b(c);' ist zB in C eine Funktionsdeklaration, in C++ könnte man auch ein Objekt b vom Typ a in Abhängigkeit von c erzeugen wollen. Um dieses globale Wissen zu kompensieren verwendet man eine Notation, die es in C nie gebraucht hat. In C ist die Notwendigkeit eine Notation irgendeiner Art zu verwenden (damit meine ich jetzt nicht, kein sinnbasiertes Namensschema einzuführen) nicht gegeben.

[groovemaster]

@Dimah
#pragma versuch ich idR zu vermeiden, da nicht alle von jedem Compiler gleich gut unterstützt werden. Habe da zB zwischen MS und Borland schon Unterschiede festgestellt (kann aber auch daran liegen, dass ich nur relativ alte Borland Compiler kenne wie der bei BC5).

@Daniel E.

Um dieses globale Wissen zu kompensieren verwendet man eine Notation, die es in C nie gebraucht hat.

Und wie sieht diese Notation genau aus? Vielleicht könntest du mal ein konkretes Beispiel posten. Da ich mich momentan gerade als C++ Rookie versuche würde mich das schon sehr interessieren.

[Shade Of Mine]

Original erstellt von groovemaster2002:
**@Dimah
#pragma versuch ich idR zu vermeiden, da nicht alle von jedem Compiler gleich gut unterstützt werden. Habe da zB zwischen MS und Borland schon Unterschiede festgestellt (kann aber auch daran liegen, dass ich nur relativ alte Borland Compiler kenne wie der bei BC5).
**

#pragma wird vom compiler ignoriert wenn er den befehl nicht versteht
dh man packt das #pragma vielleicht in ein paar guards und die sache ist gegessen -> und man erreicht das sinnlose warnungen wegfallen und man trotzdem mit der höchsten warnstufe kompilieren kann (weil die 'sinnlosen' warnungen nur bei deinem code warnen).

gerade bei C/C++ ist das wichtig, da man die fehler zur compileTime erkennen muss.

[klausmuell]

Original erstellt von Dimah:
**jup und auch wenn man fremd header und libs benutzt gibt es z.b. beim msvc ein nettes #pragma
#pragma warning( push, 3 )
#include <irgendwas.h>
#pragma warning( push, 4 )
**

aber die header des msvc selbser werfen lauter warnungen.
dazu kann man deinen trick erweitern mit #pragma includealias(<iostream.h>,<msvc_bugfix/iostream.h> ) und in der <msvc_bugfix/iostream.h> steht dein code mit
#pragma warning( push, 3 )
#include <iostream>
#pragma warning( pop )

[Kauz01]

@HumeSikkins

Erfahrung kann schließlich in vielerlei Hinsicht auch hinderlich sein. Nimm einen erfahrenen C Programmierer und versuche ihm ordentliches C++ beizubringen. Da stört die Erfahrung mehr als das sie nützt.

Der Satz lässt mich schon den ganzen Tag nicht mehr los. Jetzt muss ich das doch noch kommentieren.
Die Erfahrung ist nicht hinderlich. Das Problem ist, dass man oft zu bequem ist, sich in eine neue Sichtweise einzuarbeiten. Zu faul neu zu lernen. Wenn ein erfahrener C-Programmierer an C++ rangeht und sich auf die Sachen raussucht, die er schon kennt, einfach weil es bequemer scheint, dann findet er seinen Weg nie. Es ist nicht seine Erfahrung, die ihn behindert. Teile seiner Erfahrung können ihm auch in C++ nützlich sein. Behindert wird er, wenn er seine Erfahrung unkritisch auf das neue überträgt, wenn er sich nur auf Gemeinsamkeiten stürzt.
Jetzt mal wieder zurück zum eigentlichen Thema des Threads. Präfixe. Meine Erfahrung aus Projekten mit und ohne Präfixen ist, dass sie mir geholfen haben die Sourcen mit denen ich arbeiten musste leichter und schneller zu verstehen. Im allgemeinen behindert es mich nicht, wenn ich Präfixe benutze. Warum sollte ich sie nicht mehr verwenden?
Sollte aber der (unwahrscheinliche) Fall auftreten, dass ich die Länge von Variablennamen stark beschränken müsste, muss ich eine Entscheidung treffen. Ist es wichtiger einen aussagekräftigen Bezeichner zu haben oder ist es sehr wichtig über Präfixe den Typ zu erkennen. Bei dieser Entscheidung kann mir meine Erfahrung helfen. Wenn ich nie die Erfahrung gemacht habe, dass mir Präfixe was bringen können, werde ich die Vorteile die ich damit haben kann nie erfahren. Sollte ich aber, weil ich positive Erfahrungen mit Präfixen gemacht habe, darauf bestehen, dass diese verwendet werden, und gar nciht darüber nachdenken, dass ich auch Vorteile haben kann, wenn ich sie weglasse, dann bin ich unflexibel und borniert. Es ist nicht die Erfahrung die mich behindert, sondern die Faulheit und die Unfähigkeit über meinen Tellerrand zu gucken.

[DocJunioR]

Hmmm.. beeindruckend, Kauz

Ich denke, dass Du recht hast.
Ich hab mir die Präfixe (so mal nebenbei gesagt) erst vor circa einem Jahr angewöhnt, nachdem ich bemerkt habe, dass ich durch alte Programme nicht mehr durchsehen konnte. Dass ich jetzt hier als altmodisch, unflexibel und auch noch überheblich angesehen werde - nun, damit muss ich wohl leben. Naja, wer mich kennt, kennt mich besser
<Selbsbeschreibung>
Ich habe meine Meinung, verteidige sie aber versuche nicht, sie jemandem aufzuzwingen. Ich mache mein eigenes Ding, ob es anderen sinnvoll erscheint, oder nicht. Ändern kann ich sie übrigens auch, aber nur, wenn ich stichhaltige Beweise habe, dass meine Meinung falsch ist, und die gibt es gerade in Stilfragen nicht
</Selbstbeschreibung>
Wenn ihr eure Erfahrungen macht, dann müssen es nicht meine sein. Ich hab übrigens nie gesagt "Volkard, benutze Präfixe!". Wäre blödsinn. Ich bin sie gewohnt und setze sie für mich sinnvoll ein. Volkard meint für sich, dass sie unsinnig sind. Sie würden ihn womöglich irritieren. Gut, das ist auch sein gutes recht. Ich will auch garnicht, dass alle meinen Stil schreiben. Erstens ist ein Programmierstil wie ein Fingerabdruck und zweitens weiß ich, dass ich nicht unbedingt der sauberste Programmierer bin (ich benutze sogar globale Variablen ).

Ich hab übrigens mehrmals versucht, diese Diskussion zu einem vernünftigen Ende zu bringen. Immerhin bin ich inzwischen "überheblich" geworden, weil ich dagegen gehalten habe, als andere Leute meinten, Präfixe wären "generell überflüssig" oder "schwachsinn". Ich sagte, dass das unter Umständen ziemlich sinnvoll sein kann, was aber auch wieder nur der Fall ist, wenn man damit umgehen kann und will. (ohne jemandem zu nahe treten zu wollen, aber ist der überheblich, der zu Kompromissen bereit ist?)

Die Frage, war "Sind Präfixe für Klassen sinnvoll?" Aus meiner Sicht immernoch ja! Wenn ihr mich dafür an den Marterpfahl hängen wollt, bitte. Nur solltet ihr mal drüber nachdenken, ob das nicht eher eine Beschäftigung für ein privates Treffen wäre, anstatt hier im Forum, wo jemand von Deinen Nubes, Volkard, eine (meines Erachtens durchaus berechtigte) Frage stellt und als Antwort Abschweifungen, Beleidigungen, Unfreundlichkeiten und vor lauter Verwirrung überhaupt keine sinnvolle Aussage bekommt.
Das ist nicht gerade das, was ich von einem Forum erwarte. Klar, eine Meinung sollte jeder haben, aber auch andere akzeptieren.

Was ich vergessen habe. Hat schonmal einer eine IDE ála VC++ auf einem Großrechner gesehen? Ich nicht!
Insofern bin ich nicht überholt. Der Trend geht nämlich allmählig wieder dazu über, dass man Mainframes benutzt. Mal abgesehen davon bin ich ein Freund von Papier. ich kann auf einem Monitor nicht lesen. Ich blättere vor, zurück, schreibe mir Notizen an den Rand, mache Eselsohren in wichtige Seiten - habt ihr schonmal versucht, einen Monitor zu knicken?? Klar hat sogar der Bloodshed inzwischen einen Klassenbrowser, aber wusstet ihr, dass Papier eine längere bescheinigte Haltbarkeit hat, als eine Festplatte oder CD? (Erzählt mir nix, ich hab grade ein Projekt am Laufen, in dem es um Langzeitsicherung von Daten geht ;))
<ironie>Zu dumm nur, dass ein Klassenbrowser nicht ausdruckbar ist.</ironie>

Es schließt mit freundlichem Gruß
DjR

[Bashar]

Original erstellt von DocJunioR:
wusstet ihr, dass Papier eine längere bescheinigte Haltbarkeit hat, als eine Festplatte oder CD?

Klar. Aber Papier geht kaputt, wenn man damit arbeitet, und hält sich, wenn es in einem Buchregal verstaubt. Elektronisch gespeicherte Daten halten sich um so besser, je mehr man mit ihnen arbeitet, und gehen verloren, wenn man sie lange nicht anfaßt.

[DocJunioR]

1:0 für dich, Bashar
Ich arbeite aber mit Papier. wenn ich damit fertig bin, gibt's eh ne neue druckversion

[ Dieser Beitrag wurde am 24.03.2003 um 17:07 Uhr von DocJunioR editiert. ]

[HumeSikkins]

@DocJunioR
also langsam ist es einfach nur noch dreißt. Ich habe jetzt mal alle fünf Seiten nach dem Wort "überheblich" durchsucht. Ergebnis: Nur *du* und *Kauz01*
haben dieses Wort benutzt. Dabei hat sonst *niemand* irgendwas von "überheblich" geschrieben.

Dass ich jetzt hier als altmodisch, unflexibel und auch noch überheblich angesehen werde - nun, damit muss ich wohl leben

Wäre nett, wenn du wenigstens die Beiträge lesen und verstehen würdest, bevor du rumjammerst.

So, von mir aus kannst du jetzt mit deiner Selbstbeweihräucherung weitermachen.

[volkard]

Original erstellt von DocJunioR:
Insofern bin ich nicht überholt. Der Trend geht nämlich allmählig wieder dazu über, dass man Mainframes benutzt.

Bitte Quelle angeben.

Mal abgesehen davon bin ich ein Freund von Papier. ich kann auf einem Monitor nicht lesen.

Also überholt.

Ich blättere vor, zurück, schreibe mir Notizen an den Rand, mache Eselsohren in wichtige Seiten - habt ihr schonmal versucht, einen Monitor zu knicken??

Andere Werkzeuge, andere Techniken.
a) Mehrer Dateien offen haben, und umschalten.
b) Editor merkt sich pro Datei letze Corsorposition.
c) Copy&Paste verwenden statt Papierschnipsel auszuschneiden und woanders hinzukleben.
d) Lesezeichen benutzen.
e) Volltextsuche benutzen.
Also überholt.

Klar hat sogar der Bloodshed inzwischen einen Klassenbrowser, aber wusstet ihr, dass Papier eine längere bescheinigte Haltbarkeit hat, als eine Festplatte oder CD?

Ja, und? Tontafeln haben noch ne längere.
Die sind sogar noch überholter und für Dich automatisch besser als Papier.

[HumeSikkins]

Die Erfahrung ist nicht hinderlich. Das Problem ist, dass man oft zu bequem ist, sich in eine neue Sichtweise einzuarbeiten.

Da bin ich anderer Meinung. Mit der Zeit prägen sich bestimmte Denkstrukturen/Herangehensweisen aus. Wer sein Leben lang Probleme strukturiert gelöst hat, wird immer Schwierigkeiten haben wirklich gut objektorientiert zu denken.
Ich denke nicht, dass all die unzähligen Programmierer die Probleme mit einem Paradigmen-Wechsel haben, nur zu faul, bequem oder unkritisch sind.
Es gibt einfach keine 100%tige flexibilität.

[Bashar]

Original erstellt von HumeSikkins:
[quote]
Ich denke nicht, dass all die unzähligen Programmierer die Probleme mit einem Paradigmen-Wechsel haben, nur zu faul, bequem oder unkritisch sind.

Es könnte auch daran liegen, dass erfahrene Programmierer nicht alles glauben, was über Objektorientierung gelogen wird.

[HumeSikkins]

Es könnte auch daran liegen, dass erfahrene Programmierer nicht alles glauben, was über Objektorientierung gelogen wird.

OO war nur als Beispiel gedacht. Und ich wollte auch nicht sagen, dass OO generell besser ist als andere Techniken. Fakt ist aber, dass es viele C-Experten gibt, die den Wechsel zur OOP niemals wirklich schaffen. Andersherum hört man auch von vielen OOP-Experten, dass sie nicht mehr dazu in der Lage wirklich gute strukturierete Lösungen zu basteln. Einfach, weil ihr Hirn mittlerweile automatisch in anderen Kategorien denkt.

Es geht mir also überhaupt nicht um eine Wertung der konkreten Techniken. Nur darum, dass meiner Meinung nach Erfahrung auch hinderlich sein kann.