Suche SEHR gutes Beispiel für guten Code-Style

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)

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.

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

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

Shade Of Mine

SideWinder schrieb:

Managed DirectX? Ist das das .NET-DirectX?

ja

rüdiger

Irgendwer schrieb:

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.

Und wenn jemand die Variable nun Foo nennt? Ob foo oder Foo muss man immer nach den Projekt internen Stil Richtlinien entscheiden. Wobei alles groß mit sicherheit die schlimmste Lösung ist

SideWinder schrieb:

Soll erst mal einer nach machen

Also ich sehe da keinen Grund der Bewunderung. Da gibt es zum einen APIs, die länger existieren und nicht geändert wurden und da gibt es APIs die schöner designt sind...

Walli

SideWinder schrieb:

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

Das sollte darauf anspielen, dass ich das Design für nicht gelungen halte und ausserdem keine besondere Leistung darin sehe. Du bist dir aber der Bedeutung der folgenden Smileys bewusst ( :p )?

Erhard Henkes

Ich denke, dass Begriffe wie "Design" oder "Schönheit" nicht zielführend sind. Entscheidend sind Aspekte wie Korrektheit, Geschwindigkeit, Erweiterbarkeit, Lesbarkeit und Instandhaltung. Daher Alter vor Schönheit!

otze

Korrektheit, Geschwindigkeit, Erweiterbarkeit, Lesbarkeit und Instandhaltung

du beschreibst grad die eigenschaften, die schöner code haben soll