Suche SEHR gutes Beispiel für guten Code-Style

[Erhard Henkes]

http://www.gotw.ca/
http://www.aristeia.com/
http://www.aristeia.com/Papers/IEEE_Software_JulAug_2004.pdf
etc.

[randa]

Also ich kann mich auch nicht begeistern für den stark auseinandergezogenen Code von zyrian.
Ich denke, du hast es da ein bisschen zu genau genommen mit dieser Art ser Strukturierung, sodass es doch ein wenig schwerer zu lesen ist als du glaubst (du hast dich ja daran schon gewöhnt). Prinzipiell ist eine Strukturierung dieser Art eine gute Idee, nur versuch, die Funktionen so zu gruppieren, dass sie von der Art/Anzahl der Argumente ungefähr zusammenpassen und auf dieser Grundlage die Tabs zu wählen. Wäre etwas leserlicher.
Allerdings ist ein Negativpunkt daran, dass die Funktionen weniger nach gemeinsamen Aufgabenbereich als vielmehr nach optischer Zusammengehörigkeit gruppiert werden, und das ist auch nicht so toll.

Was die bescheurerten LPDIRECT... Dinger betrifft, die Kürze ich grundsätzlich durch typedefs oder defines ab. Is mir zuviel zu Schreiben, und die ganzen Großbuchstaben mag ich auch nicht.

[KPC]

Optimizer schrieb:

public Point(String string) throws BattleshipException

}

Hat der Name BattleshipException eine tiefere Bedeutung? Irgendwie find ich den da komisch

[rüdiger]

als ergänzung möchte ich noch sagen, dass dieser code stil net aus meiner eigenen feder entsprungen ist, sondern aus einem buch übernommen ist.

Das macht den Code nicht richtiger, sondern sagt eher was über die Qualität des Buches aus

achjo als anmerkung:
is mir eigentlich total latte wie andre leute das finden. solang ich mich selber darin zurecht finde, is das ok, basta.

Da es in dem Thread um guten Stil geht, musst du damit rechnen, dass die Leute deinen Stil kritisieren. Wenn du keine Kritik vertragen kannst, dann poste doch einfach kein Code, dann passiert dir das auch nicht.

Und niemand zwingt dich hier zum lernen...

@ethereal
ich finde typedefs um Pointer zu verstecken keine gute Idee. Also lieber gleich

foo *a; anstelle pfoo *a; schreiben.

(vorallem da das L beim P ja eh keine Bedeutung mehr hat und ein gutes Beispiel für die Sinnbefreitheit der UN ist)

[tag]

Die ganzen LPDIRECTxxx gehören IMHO sowieso in einen CComPtr oder etwas vergleichbares verpackt.

[Gast]

KPC schrieb:

Hat der Name BattleshipException eine tiefere Bedeutung? Irgendwie find ich den da komisch

Es handelte sich um ein Schiffe versenken mit cooler Konsolengrafik.

[otze]

Irgendwer schrieb:

Zyrian schrieb:

Es geht nicht darum, dass du selber typedefs schreibst, sondern diese LPXXX dinger nutzt. Das schlechte daran ist, dass man solche Variablen nicht sofort als Zeiger identifizieren kann. Hat das überhaupt Vorteile?

Ich wüsst net, dass es sooo verdammt schlimm ist, dass ich LPs benutze.
Aber ihr könnt mir net erzählen, dass ihr LP-Variablen net als Zeiger erkennt. Das kauf ich euch net ab (oder ka was du meinst, du hast dich net ganz verständlich ausgedrückt).

Also ich kann T* deutlich besser als Pointer ausmachen als LPT. Wenn es wenigstens LP_T wäre dann würde man wenigstens auf den ersten Blick sehen, dass es ein Präfix ist.

nix gegen ein p am anfang um nen pointer anzuzeigen, aber dann muss auch schon klein sein: T* ist für mich genauso aussagekräftig wie pT

[rüdiger]

@otze
ich finde es unnötig, die eigentliche Syntax der Sprache zu umgehen. Was hat p als Prefix für ein Vorteil? Keinen, also ist es nicht nötig, die Syntax der Sprache zu verstecken, weil es nur zur Verwirrung von Programmierern führen kann.

Ansonsten könnte man ja auch gleich mit entsprechenden defines seine eigene Programmiersprache basteln

Warum nicht auch

#define CALL_PROCEDURE(function,parameter) function(parameter)
#define DECLARE_PROCEDURE(function,parameter) void function(parameter)
#define BEGIN {
#define END }
#define INIT int main()

DECLARE_PROCEDURE(foo,int i);

INIT
BEGIN
  CALL_PROCEDURE(foo,1);
END

oberes macht IMHO genauso viel Sinn, wie Pointer zu verstecken oder ähnliche späße.

[Shade Of Mine]

kingruedi schrieb:

oberes macht IMHO genauso viel Sinn, wie Pointer zu verstecken oder ähnliche späße.

Aber Microsoft macht es ja auch so. Und die muessen ja wissen wie man programmiert. Sieht man doch an den ganzen Samples aus der MSDn wie gut sie programmieren koennen.

[SideWinder]

BTW: An den LP-Typedefs kommst du als DirectX-Programmierer nicht vorbei. Und BOOL ist auch besser als bool da ja eventuell in 2 Jahren kein bool mehr dahinter steht (hust, tut es ja jetzt schon nicht...)

MfG SideWinder

[rüdiger]

Shade Of Mine schrieb:

kingruedi schrieb:

oberes macht IMHO genauso viel Sinn, wie Pointer zu verstecken oder ähnliche späße.

Aber Microsoft macht es ja auch so. Und die muessen ja wissen wie man programmiert. Sieht man doch an den ganzen Samples aus der MSDn wie gut sie programmieren koennen.

da gab es dochmal so eine Reportage drüber, dass MS die ganzen Leute direckt von der Uni holt und die ohne RealLife Erfahrung dann Windows coden...

SideWinder schrieb:

BTW: An den LP-Typedefs kommst du als DirectX-Programmierer nicht vorbei. Und BOOL ist auch besser als bool da ja eventuell in 2 Jahren kein bool mehr dahinter steht (hust, tut es ja jetzt schon nicht...)

öhm, sieht es nicht so aus

typedef struct FOO_ {
//...
} FOO,*LPFOO;

wo ist das Problem dann

FOO *bar;

zu schreiben oder noch besser

typedef FOO foo;

foo *bar;

?

Das mit BOOL ist ja ein WinAPI Workarround, da es ja bis C99 in C keinen BOOL Typ gab. Trotzdem sollte man in C++ lieber bool nehmen und in C99 lieber _Bool (bzw. die typedefs aus stdbool.h)

[Irgendwer]

kingruedi schrieb:

typedef FOO foo;

foo *bar;

foo ist zwar gut lesbar aber wenn du noch eine Variable names foo irgendwo in deinem Program hast dann kann das ganz gewaltig Ärger geben, also schreib ich Foo um Nameskonflikten aus dem Weg zu gehen.

[Gast]

Ich glaube dass der Hauptgrund, warum es diese LP-typedefs gibt ist, weil man dort auch sehr häufig Zeiger auf Zeiger hat.

(*bla)->

Ich bin aber auch gerade dabei, mich davon zu lösen.
Jojo, die Winapi und das unmanaged DirectX ist schon immer wieder schön anzugucken.

[SideWinder]

Trotzdem hats DirectX nun geschafft 10 Versionen durchzuhalten mit 100%iger Abwärtskompatibilität und ohne irgendetwas am Design verändern zu müssen. Soll erst mal einer nach machen

MfG SideWinder

[Shade Of Mine]

SideWinder schrieb:

ohne irgendetwas am Design verändern zu müssen

Du hast das Problem erkannt

[Walli]

SideWinder schrieb:

Trotzdem hats DirectX nun geschafft 10 Versionen durchzuhalten mit 100%iger Abwärtskompatibilität und ohne irgendetwas am Design verändern zu müssen.

Tja, wenn man kein Design hat kann man auch nix verändern :p .

[SideWinder]

Kann man so oder so sehen. Dank strikter COM-Einhaltung ist das Design doch sehr langlebig. Ob es damals optimal ausgewählt worden ist kann ich nicht beurteilen - aber auch wenn es nach heutigen Gesichtspunkten nicht der Fall ist, so ist es für einen Programmierer um einiges leichter Aspekte und Features von neueren Versionen zu nützen wenn diese im gleichen Design vorliegen.

MfG SideWinder

[SideWinder]

MaSTaH schrieb:

SideWinder schrieb:

Trotzdem hats DirectX nun geschafft 10 Versionen durchzuhalten mit 100%iger Abwärtskompatibilität und ohne irgendetwas am Design verändern zu müssen.

Tja, wenn man kein Design hat kann man auch nix verändern :p .

Was ist denn das für ein Schwachsinnspost

MfG SideWinder

[Gast]

btw. managed DirectX ist IMHO sehr schön designed worden. Sieht nur hässlich aus, wenn man es mit C++ benutzt. :p

[SideWinder]

Managed DirectX? Ist das das .NET-DirectX?

MfG SideWinder