ZFX
ZFX Neu
Home
Community
Neueste Posts
Chat
FAQ
IOTW
Tutorials
Bücher
zfxCON
ZFXCE
Mathlib
ASSIMP
NES
Wir über uns
Impressum
Regeln
Suchen
Mitgliederliste
Membername:
Passwort:
Besucher:
4396332
Jetzt (Chat):
22 (0)
Mitglieder:
5239
Themen:
24223
Nachrichten:
234554
Neuestes Mitglied:
-insane-

ZFX
Coding-Foren
Sourcecode-Probleme
Tipps und Hinweise für sauberen Code
GepinntSeite: < 1 2 3 4 >
AutorThema
Kimmi Offline
ZFX'ler


Registriert seit:
10.10.2002

Schleswig-Holstein
93425079
Re: Tipps und Hinweise für sauberen CodeNach oben.
Ich habe die Indizes mit Absicht vorher definiert. Es gibt im VC.NET 2002 oder im VC6.0 einen For-Scope-Bug, der dafür Sorge trägt, dass eine so definierte Variable ausserhalb des for-Scopes immer noch definiert ist.

Und da kommen wir zu einem ganz wichtigen Punkt:
Schreibe deinen Code portabel!!!
Es kann sein, dass jemand noch nicht den neuesten Compiler bei sich zu Hause stehen hat, dementsprechend informiere dich über bekannte Bugs und versuche sie zu vermeiden.

Nicht immer ist der neueste Standard in allen Compilern. Dieser For-Scope-Bug ist im eigentlichen Sinne kein Bug, da die MS-Leute sich angeblich auf einen älteren Standard gestützt haben.

MfG Kimmi
20.02.2004, 08:43:36 Uhr
Kurzer Weblog
Patrick Offline
ZFX'ler


Registriert seit:
25.02.2002

Deutschland
143040199
Re: Tipps und Hinweise für sauberen CodeNach oben.
Hi,

zum Thema portablen code hab ich mal was gefunden im Netz:

Regel Nummer 1:
Halte dich an den Standard!

Das bedeutet dass du zB unter Windows dich lieber mit localtime rumspielen sollst, anstatt ganz einfach GetSystemTime zu verwenden... das ist der erste schritt um portierbaren Code zu schreiben! Keine nicht-Standard-Header inkludieren!


Regel Nummer 2:
Wisse was der Standard sagt!

Oft bestimmt der Standard wichtige Details nicht genau! Bsp:
Code:
int add(int a, int b)
{ return a+b; }
...
add(add(--i,j),add(++j,i--));
...

das Ergebnis ist nicht definiert, da der Compiler entscheiden darf ob er zuerst add(++j) oder add(--i+i) aufruft...
wenn man weiß das so was nicht standardisiert ist dann schreibt man von vornherein:
Code:
int t1=add(--i,j);
int t2=add(++j,i--);
ergebnis = add(t1,t2);


Neben der Aufruf Reihenfolge ist der modulo Operator (%) auch noch eine Gefahrenquelle! der Standard schreibt vor dass bei
Code:
erg=a/b;
rest=a%b;

folgendes gilt:

Code:
erg * b + rest == a


Wenn a jetzt negativ ist dann ist nicht festgelegt ob der Rest positiv ist oder negativ!

Solche trivialen Probleme stellen sich meistens dann wenn man ein Projekt auf oder von einer Plattform/Compiler portiert die/den man nicht kennt!

Das heißt jetzt nicht dass man den Standard auswendig lernen soll, sondern schlicht und einfach: "wenn das Programm nicht wie erwartet läuft - dann sollte man solche Fehlerquellen nachschlagen"


Regel Nummer 3:
OS abhängige Funktionen verstecken

Bsp: cls(); Diese Funktion soll uns den Bildschirm löschen... wir haben dazu zB bei Borland die Funktion clrscr() -> nun rufen wir in unserem Programm cls() auf! cls ist in einer Quelldatei ausgelagert in der _nur_ Funktionen sind die OS abhängige Sachen machen! die Funktion cls() macht nichts anderes als clrscr() aufzurufen...

Der Sinn? Angenommen wir portieren das Programm jetzt nach Linux! jetzt gibt es kein clrscr() mehr... aber wir können einfach die Implementation von cls() ändern, und den restlichen Quelltext unverändert lassen...


Regel Nummer 4:
schalte 'language extensions' aus

Falls dein Compiler diesen switch kennt, unbedingt abdrehen! Denn diese language extensions erlauben dem Compiler dir Sachen zu erlauben die auf allen anderen Compilern illegal sind! zB Überladung in C oder neue Schlüsselwörter.


Regel Nummer 5:
verstecke Compiler spezifische Sachen

zB der VC++ kennt die Aufrufkonventionen __stdcall, __cdecl,... im Grunde sollte man diese nicht nutzen! Auf gar keinen Fall nutzen!! aber angenommen wir brauchen __stdcall aus unerklärlichen gründen -> dann benutzen wir ein #define um es zu 'verstecken':

Code:
#ifndef _MSC_VER
#define __stdcall
#endif

Dieses leere define erlaubt jetzt __stdcall auch zB mit dem gcc zu nutzen - er ignoriert es schlicht und einfach! auf diese art und weise ist es natürlich auch möglich sich ein eigenes __stdcall zu 'schreiben'
Code:
#ifdef xxx
#define STDCALL xxx
#elsif xxx
#define STDCALL xxx
#else
#define STDCALL
#endif



Regel Nummer 6:
So wenige externe Bibliotheken verwenden wie möglich

Und wenn man eine verwendet dann eine Plattformunabhängige! Das Problem einer Bibliothek zB für Mathematik, Grafik,... ist dass diese auch portiert werden muss. Wenn man es selber portieren muss dann kostet dass nicht nur sinnlos viel Zeit, sondern ist auch recht schwer da man den Code uU nicht versteht. Deshalb sollte man bevor man eine Bibliothek verwendet darauf achten ob man diese auch auf einem anderen system/Compiler/... verwenden kann...



Structs
niemals ganze Strukturen (structs) in eine Datei schreiben und lesen... denn die innere Architektur eine struct darf sich der Compiler aussuchen... (alignment) die Elemente der struct sollte man einzeln einlesen und ausgeben...


Little/Big Endian:
eines der tückischsten Probleme:
L/B Endian besagt ob das höherwertige Byte vorne oder hinten steht... da sich das aber nur auf zahlen bezieht, kann man dieses Problem damit umgehen dass man nur chars speichert...


Typengröße:
das kann sehr gefährlich werden:
Aber es sollte bekannt sein. deshalb: zuerst erkundigen wie groß die Datentypen auf der Zielplattform/Compiler sind. (Notfalls selber mit dem sizeof Operator bestimmen) sollten die Datentypen auf dem Zielsystem größer sein dann ist das kein Problem, sollten sie kleiner sein, dann wird's blöd!
Der Trick: definieren von eigenen Datentypen - damit kann man dann auch gleich das signed/unsigned Problem umgehen (der Standard schreibt nämlich nicht vor ob zB char signed oder unsigned ist...)

Code:
#define UINT32 unsigned long int
#define SCHAR signed char
#define SINT8 signed int


der Standard besagt dass sizeof(char)==1 sein muss... aber weiters gilt nur
Code:
sizeof(short)<=sizeof(int)<=sizeof(long)


somit sollte man großzügig mit dem Speicher sein, auch wenn es heute fast nur noch 32Bit Systeme gibt...
20.02.2004, 11:21:49 Uhr
GermanGameDev
Kimmi Offline
ZFX'ler


Registriert seit:
10.10.2002

Schleswig-Holstein
93425079
Re: Tipps und Hinweise für sauberen CodeNach oben.
Die Zusammenfassung von Patrick gehört IMHO in den FAQ.

MfG Kimmi
20.02.2004, 11:28:47 Uhr
Kurzer Weblog
ChrisM Offline
ZFX'ler


Registriert seit:
16.03.2002

Rheinland Pfalz
65348179
Re: Tipps und Hinweise für sauberen CodeNach oben.
Hi,

damit ZFX gegen Copyrightrechte verstößt? Mir zumindest kommt der Text sehr bekannt vor (steht ja auch darüber, dass er von einer anderen Seite ist)...

ChrisM
20.02.2004, 16:04:37 Uhr
ChrisMs Baustelle
Kimmi Offline
ZFX'ler


Registriert seit:
10.10.2002

Schleswig-Holstein
93425079
Re: Tipps und Hinweise für sauberen CodeNach oben.
Wie wäre es dann mit einem Link in den FAQ zum entsprechenden Text. Ist sicherlich auch nicht gerade das Thema, welches ZFX abdecken möchte. Trotz dessen ist es für einige Personen sicherlich interessanter.

MfG Kimmi
20.02.2004, 16:49:03 Uhr
Kurzer Weblog
scalar Offline
ZFX'ler


Registriert seit:
11.08.2002

USA
Re: Tipps und Hinweise für sauberen CodeNach oben.
Zitat von Patrick:
Code:
#define UINT32 unsigned long int
#define SCHAR signed char
#define SINT8 signed int


Tss.

Code:
typedef unsigned long int UINT32;
typedef signed char SCHAR;
typedef signed int SINT8;
20.02.2004, 18:03:06 Uhr
Patrick Offline
ZFX'ler


Registriert seit:
25.02.2002

Deutschland
143040199
Re: Tipps und Hinweise für sauberen CodeNach oben.
hi,
ich hatte den text von www.germandevnet.de doch die seite ist ja nun schon seit ca 2 monaten down
20.02.2004, 19:46:56 Uhr
GermanGameDev
iNzAnE Offline
ZFX'ler


Registriert seit:
30.07.2002

Deutschland
106246705 iNzAnE5684@hotmail.com iNzAnE5684
Re: Tipps und Hinweise für sauberen CodeNach oben.
Zitat von Patrick:

der Standard besagt dass sizeof(char)==1 sein muss... aber weiters gilt nur
Code:
sizeof(short)<=sizeof(int)<=sizeof(long)


nicht ganz. Der Standard garantiert weiterhin das ein char mindestens 8 Bit, ein short mindestens 16Bit und ein long mindestens 32Bit groß ist(§4.6).

Bei Fließkommazahlen ist das ein größeres Problem.
21.02.2004, 00:24:19 Uhr
Ordinary Story
scalar Offline
ZFX'ler


Registriert seit:
11.08.2002

USA
Re: Tipps und Hinweise für sauberen CodeNach oben.
Das ist §4.6 in "Die C++ Programmiersprache", nicht im Standard. Dies ist einer der Punkte, an dem sich der Standard und Stroustrup widersprechen. Soweit ich weiss garantiert der Standard das naemlich nicht (es sei denn, das wurde in einem Technical Comment kuerzlich geaendert).
21.02.2004, 02:14:25 Uhr
CptStone Offline
ZFX'ler


Registriert seit:
26.01.2003

Hamburg
Re: Tipps und Hinweise für sauberen CodeNach oben.
Ich hätte da zu obigem FAQ noch eine KETZER-Regel beizutragen:

Regel No. 7: Mach Dir nichts vor!

Wenn Du portablen, universell verwendbaren und sicheren Code schreiben möchtest, überprüfe das Resultat. Möglichst bald. Sonst wirst Du wahrscheinlich erleben, daß Du ... Dir etwas vorgemacht hast. Das ist dann doof.


Regel No. 7b: Mach Dir nicht in Hemd!

Der Kunde möchte "irgendwann" eine Portierung machen lassen, zu unbestimmtem Zeitpunkt? Dann vergiß alle vorigen Regeln und rechne separat für die Portierung ab.


(Kommentare erwünscht)
21.02.2004, 03:15:58 Uhr
Homepage
iNzAnE Offline
ZFX'ler


Registriert seit:
30.07.2002

Deutschland
106246705 iNzAnE5684@hotmail.com iNzAnE5684
Re: Tipps und Hinweise für sauberen CodeNach oben.
@scalar:
OK ... ich dachte das wäre das gleiche
21.02.2004, 11:01:41 Uhr
Ordinary Story
scalar Offline
ZFX'ler


Registriert seit:
11.08.2002

USA
Re: Tipps und Hinweise für sauberen CodeNach oben.
"Die C++ Programmiersprache" und das ISO-C++-Standardwerk sind zwei verschiedene Schriftstuecke. Letzteres kannst Du Dir grob hier angucken. Es ist die letzte kostenlose Version, die veroeffentlicht wurde, bevor der Standard ratifiziert wurde.

In den meisten Faellen schreiben beide natuerlich an unterschiedlichen Stellen das gleiche. Die Groesse von int-Variablen ist aber, wenn ich mich korrekt erinnere, eine der Ausnahmen. Zumindest konnte ich die von Dir angesprochene Garantie im Standard nicht finden. Es ist aber gut moeglich, dass ich mich irre, der Standard ist nicht gerade leicht zu lesen.
21.02.2004, 12:07:29 Uhr
Mastermind Offline
Knowledge-Admin


Registriert seit:
18.10.2002

Nordrhein-Westfalen
Re: Tipps und Hinweise für sauberen CodeNach oben.
Copyright war auch ein Problem, dass mir sofort einfiel.

Das FaQ soll gute Beiträge von ZFX Nutzern aktivieren und keine Fremden.

Ein Link, wenn es noch einen Gäbe wäre in der Link Sektion siche gut aufgehoben, wenn sie fertig ist.

und google nach how to write portable code dürfte wohl auch jeder können.

Auch denke ich das auf dem Niveau, dass hier größtenteils vorrherrscht eher die Ketzerregeln zutreffen.

Schließlich bleibt dieser Thread ja auch gepinnt und leicht einsehbar.
21.02.2004, 13:32:19 Uhr
Work in Progress
Kimmi Offline
ZFX'ler


Registriert seit:
10.10.2002

Schleswig-Holstein
93425079
Re: Tipps und Hinweise für sauberen CodeNach oben.
Habe das mit dem kopierrten Text schlichtweg überlesen und ziehe meine Anforderung zurück.

@CptStone
Regel 7 ergibt sich selbstredend von selbst, dazu sage ich mal nichts.
Regel 7b ist etwas, die bereits anfänglich im Design verankert werden muss. Hinterher mal eben Win32-spez. Code zu portieren, ist gleichzusetzen mit Höllenpest. Sowas will ich nicht machen müssen.

MfG Kimmi

Edit: Rechtsschreibung gefixt

1 Mal gendert, zuletzt am 22.02.2004, 04:09:39 Uhr von Kimmi.
21.02.2004, 21:34:35 Uhr
Kurzer Weblog
CptStone Offline
ZFX'ler


Registriert seit:
26.01.2003

Hamburg
Re: Tipps und Hinweise für sauberen CodeNach oben.
@Kimmi: Das ehrt Dich natürlich. Ich hatte aber schon das zweifelhafte Vergnügen mit Leuten von geringerer Weitsicht arbeiten zu dürfen. Das ist für mich ein Beleg dafür, daß sich diese Regel doch nicht so ganz von selbst versteht. Also die Regel versteht sich selbst vielleicht noch aber .. verstehst Du?

Oh mann, ich muß mal die Sinnlos-Postings einschränken.
22.02.2004, 00:31:20 Uhr
Homepage
Seraph Offline
Administrator


Registriert seit:
18.04.2002

England
Re: Tipps und Hinweise für sauberen CodeNach oben.
Zitat von Patrick:
Regel Nummer 4:
schalte 'language extensions' aus

Falls dein Compiler diesen switch kennt, unbedingt abdrehen! Denn diese language extensions erlauben dem Compiler dir Sachen zu erlauben die auf allen anderen Compilern illegal sind! zB Überladung in C oder neue Schlüsselwörter.

Hast Du diese Regel mal gestestet?
26.02.2004, 02:24:31 Uhr
ZFX - 3D Entertainment
Helmut Offline
ZFX'ler


Registriert seit:
11.07.2002

Deutschland
280083044 helmut4242
Re: Tipps und Hinweise für sauberen CodeNach oben.
Hi
Zitat von Kimmi:
Ich habe die Indizes mit Absicht vorher definiert. Es gibt im VC.NET 2002 oder im VC6.0 einen For-Scope-Bug, der dafür Sorge trägt, dass eine so definierte Variable ausserhalb des for-Scopes immer noch definiert ist.


Hab letztens was ganz praktisches gesehen:
Code:
#if defined (_MSC_VER)
#define for if(false) {} else for
#endif

Hab's noch nicht getestet, klingt aber ganz gut

Ciau
Helmut
24.06.2004, 15:09:10 Uhr
Bomber-Revolution
johnny mnemonix Offline
ZFX'ler


Registriert seit:
22.07.2004

Baden-Württemberg
Re: Tipps und Hinweise für sauberen CodeNach oben.
Hi.
bin grad hier reingestolperst *autsch*
was mir ganz spontan einfällt.

Saubere Source tipps:
1. ungarische notation verwenden, oder sich an eigene halten
2. statt int wg. 16/32-bit lieber eindeutig short & long verwenden
3. "Knackig" kommentieren, persönlich finde ich nichts schlimmer als eingetexteter code, der eigentlich ohne auskommen würde.

4. einheitlich schreiben, also nicht:
Code:
unsigned long dwNum = 4294967395;
unsigned long dw_num = 65535;
myClass.set_vars( dwNum, dw_num );
myClass.CalcSomethingWith();

5. funktionen die mit bestimmten klassen arbeiten aber methoden bedingt einschränken würden mit einenm kürzel vorsetzen. ( änlich wie die directx utility library)

Optimierungs tipps:
1. fliesskommazahlen lieber multiplizieren(schneller) statt dividieren:
Code:
a /= 5.0f;
a *= 0.2f


2. ungleich vg.-operator dem kleiner-als vorziehen. ausnahmen bei flieskomma, zeitabfragen u.ä
Code:
for(int i = 0; i != MAX; ++i)
    Array[i];


gruss
29.07.2004, 00:03:15 Uhr
mogelvogel
Tracert Offline
ZFX'ler


Registriert seit:
08.04.2002

Deutschland
Re: Tipps und Hinweise für sauberen CodeNach oben.
... womit ich zu noch etwas komme, was hier (glaube ich) so noch nicht genannt wurde:

Auf keinen Fall Fließkommazahlen (float, double etc.) auf == oder != testen! Meistens sind sie aufgrund der Implementierung und Abspeicherung nämlich nicht GENAU gleich einem bestimmten Wert, auch wenn es nach außen zunächst so aussieht, oder es wird noch als != angesehen obwohl es eigentlich schon gleich sein sollte.

Benutzt lieber einen bestimmten "Genauigkeitsbereich" (z.B.+-0.000001 statt 0) und testet mit diesem auf < und/oder >.

Wusste ich gar nicht bis ich angefangen habe Informatik zu studieren. ^^

[Edit] Das macht den Code nicht wirklich sauberer im Sinne von "lesbarer", aber defintiv sauberer im Sinne von "fehlerunanfälliger", was meiner Meinung nach wichtiger ist.

1 Mal gendert, zuletzt am 01.10.2004, 19:20:14 Uhr von Tracert.
01.10.2004, 19:17:15 Uhr
Tracert Offline
ZFX'ler


Registriert seit:
08.04.2002

Deutschland
Re: Tipps und Hinweise für sauberen CodeNach oben.
Und noch eines zum Thema guter Stil / guter Code:

Ich höre immer wieder "plattformunabhängig", als wäre das die Lösung aller Probleme. MEINE Meinung ist allerdings, dass es eigentlich KEIN guter Stil ist, alles plattformunabhängig machen zu wollen, denn es grenzt eher wieder an das Thema "eierlegende Vollmilchsau".

Ich denke man sollte sich von vornherein überlegen, für welche Plattform man eine Software entwickelt, und zwar davon beeinflusst, WAS es für eine Software ist. 3D-Spiele z.B. sind halt Spiele und benötigen im Allgemeinen die neusten Techniken. Linux eignet sich schon von Seiten der Hardwareunterstützung (Treiber...) kaum zum Spielen (leider), andere Betriebssysteme erst recht nicht, ein Spiel plattformunabhängig machen zu wollen ist in meinen Augen also hinfällig. Windows ist DIE Spieleplattform im Moment und so schnell wird sich daran wohl nichts ändern.

Wenn man tatsächlich ein Programm schreiben will, das überall laufen soll: Wählt eine Programmiersprache, die dafür ausgelegt ist. Java zum Beispiel ist wirklich gar nicht so schlecht, wie es manchmal gemacht wird. Und von C++ auf Java umzusteigen ist (eigene Erfahrung!) lachhaft einfach, wenn man denn wirklich programmieren KANN. Man kann sich viel Arbeit und Ärger sparen, wenn man vorhandene Techniken richtig nutzt.

Wenn man sowieso OpenGL lieber mag und somit die Spiele praktischerweise auch gleich für Linux schreiben will: Macht zwei unabhängige Projekte, entwickelt plattformunabhängige Teile im einen und kopiert sie in das andere wenn sie fertig sind. Die plattformabhängigen Teile (irgendwo hat man die dann immer) am besten parallel entwickeln.

Es verkompliziert (und verlängert) die Sache (Entwicklung) nur, wenn man alternative APIs parallel in einem Projekt benutzt, z.B. OpenGL und Direct3D. Konzentriert euch auf eine Sache und macht diese dafür richtig!

Und letzter (wichtiger) Punkt: Wenn ihr meint es sei eure Mission alles plattformunabhängig zu machen, dann tut dies, aber definiert dies nicht als DEN guten Stil, die Lösung aller Probleme und als DIE Sache, die jeder immer machen sollte. Gerade als Anfänger (und an die geht diese Sache wohl hauptsächlich) will man hauptsächlich sein erstes Projekt entwickeln, dass auf den am meisten genutzten Rechnertypen (von sich selbst und denen der Freunde) läuft. Nicht mehr und nicht weniger.

Bitte kein Flamewar jetzt anfangen, ich fand das sollte nur mal gesagt werden.
01.10.2004, 19:57:29 Uhr
windowsint Offline
ZFX'ler


Registriert seit:
25.02.2002

Schleswig-Holstein
Re: Tipps und Hinweise für sauberen CodeNach oben.
http://www.cbloom.com/3d/techdocs/coding.txt

Das sollte so eine Art Leitfaden für Codingstyle sein.

PK
01.10.2004, 20:07:59 Uhr
Tracert Offline
ZFX'ler


Registriert seit:
08.04.2002

Deutschland
Re: Tipps und Hinweise für sauberen CodeNach oben.
Nur so nebenbei: Warum wurden die Tipps zur Code-Optimierung jetzt total zugemacht? Als letztes stand, dass unsinnige Posts ab jetzt gelöscht werden, aber wie denn wenn man gar nix posten kann? ^^
01.10.2004, 21:46:19 Uhr
daedalus Offline
ZFX'ler


Registriert seit:
12.11.2004

Deutschland
Re: Tipps und Hinweise für sauberen CodeNach oben.
Zum guten Code gehört eine gute Planung, sei es nun als Referenzwerk für sich und Andere, die den Code nutzen, oder als "Anleitung", was man zu implementiereun hat. Zur Planung gehört:

- Lastenheft erstellen!
- Pflichtenheft erstellen!
- Objektorientierte Analyse durchführen!
- Objektorientiertes Design durchführen!
- Generelle Dinge wie Programmierparadigma, Entwicklungsmodell (Evolutionär/Iterativ) etc. in einem seperaten Paper festhalten!
- Zeitplan festlegen!
- Aufwandseinschätzungen durchführen! (sowohl für die Implementierung (für den Zeitplan, z.B. mit COCOMO) als auch für den Rechenaufwand, um Bottlenecks im Voraus absehen zu können)
- Für komplexere Funktionen: Funktionsdiagramme erstellen!

Es gibt (gerade für Anfänger) gute Bücher zur Planung einer Software, z.B. Helmut Balzert: "Lehrbuch der Software-Technik". Lesen bildet!

Nach der Planung folgt die Umsetzung (wobei die Implementierungsphase nach einem weit verbreiteten Modell nur eine von sechs Phasen ausmacht). Hier ist zu beachten, was bereits gesagt wurde. Zusätzlich:

- Hat man eine Idee, die man nicht "verlieren" möchte: im Psydocode aufschreiben! Auf keinen Fall einfach implementieren!
- Projekte auf der Festplatte gut sortieren! Man findet im Quellcode keinen Bug, wenn er nicht im Quellcode ist- verwendete Dateien (Bilder, Sounds etc.) gut strukturiert speichern!
- Einen guten Editor/Entwicklungsumgebung verwenden, um den Quellcode zu schreiben! (Selbst angepasste) Syntax-Hervorhebungen sind wichtig, dennoch an Standards halten!
- Einheitliche Datentypen verwenden, nicht mal long, mal DWORD etc.!
- Gerade bei der Entwicklung von Spielen: Programm frühzeitig unter verschiedenen Hardwarekonfigurationen und Betriebssystemen testen (lassen, von Freunden)!
Zitat:
You know your game is introuble, when the game runs perfectly on your system...only your system
28.11.2004, 14:59:00 Uhr
Mr.DX Offline
ZFX'ler


Registriert seit:
01.08.2002

Bayern
297101048
Re: Tipps und Hinweise für sauberen CodeNach oben.
Der letzte Post ja schon ein bißchen her, hier aber von meiner Seite 2 Links:
http://www.uwe-sauerland.de/richtlinien/Programmierrichtlinien.html#Inhalt
http://www.uni-koblenz.de/~daniel/Namenskonventionen.html

Gibts eigentlich irgendwelche Notationen für die Verwendung von Namespaces? Eine feingranulare Einteilung der ganzen Klassen in Kategorien in Namespaces (mit zig Namespaces in Namespaces in ...) ist ja wohl auch ned der Hit, oder?
20.08.2006, 18:42:36 Uhr
Devil Offline
ZFX'ler


Registriert seit:
26.07.2005

Baden-Württemberg
Re: Tipps und Hinweise für sauberen CodeNach oben.
Nja der Zweite Link is im Moment off. Beim ersten sind zum Teil recht gute Zusammenfassungen drin, aber auch nen paar Sachen die ich als Schwachsin ansehe, aber okay.

Und zu:
Code:
#ifndef _FILENAME_H
... mal sehen was euch einfällt, was der Standard davon hält

1 Mal gendert, zuletzt am 15.07.2008, 01:44:22 Uhr von Devil.
15.07.2008, 01:43:35 Uhr
Merlin - A Legend awakes
GepinntSeite: < 1 2 3 4 >


ZFX Community Software, Version 0.9.1
Copyright 2002-2003 by Steffen Engel