 |
JLI Spieleprogrammierung
|
| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
KI
JLI Master
Alter: 38
Anmeldedatum: 04.07.2003
Beiträge: 965
Wohnort: Aachen
Medaillen: Keine
|
 Verfasst am: 26.07.2005, 22:50 Titel: |
 |
|
Okay Leute. Ich habe gerade den Sourcecode zu FruitySnake beta 0.1.0.2 hochgeladen. (siehe erster Post dieses Threads)
Es ist eigentlich keine beta-Version, sondern ein voll funktionsfähiges Spiel. Der Code ist sehr sauber und strukturiert. Ihr werdet euch bestimmt gut zurechtfinden. Es lässt sich sofort kompilieren. Viel Spaß damit. 
Wir arbeiten gerade an der 3D-Version mit erweitertem Map-Format und "Visual Snake Map Builder". Ich schätze, dass wir Ende dieser Woche die erste spielbare Version veröffentlichen werden. 
edit: Wenn es irgednwas am Code auszusetzen gibt, oder ihr Verbesserungsvorschläge habt. Her damit.  |
|
| Nach oben |
|
 |
Kronos
Senior JLI'ler
Anmeldedatum: 19.03.2004
Beiträge: 290
Medaillen: Keine
|
| Verfasst am: 27.07.2005, 07:18 Titel: |
|
|
Naja, ist eigtl. übersichtlich, mich stören nur Klassenpräfixe, Präfixe allgemein und die ungarische Notation (ist veraltet)  . Ich halte nicht viel von der ungarischen Notation und auch nicht viel von Präfixen.. Man kann leicht mit der MFC oder sonst irgendwas in von MS in Konflikt kommen, wenn man das C Präfix für klassen verwendet.. Aber naja gut, da du ja noch keine ähnlichen Probleme hattest, wirst du sicher auch bei deiner Notation bleiben. Ich halte es nur für völlig übertrieben und außerdem ist die ungarische Notation veraltet. Wenn ich eine variable filesize habe, dann ist eigtl. logisch, dass die vom typ size_t sein sollte.
_________________
| David hat Folgendes geschrieben: | | Solang meine Beiträge konstruktiver sind als deiner bin ich zufrieden... |
Kein Kommentar notwendig. :rolleyes: |
|
| Nach oben |
|
|
KI
JLI Master
Alter: 38
Anmeldedatum: 04.07.2003
Beiträge: 965
Wohnort: Aachen
Medaillen: Keine
|
| Verfasst am: 27.07.2005, 11:14 Titel: |
|
|
MFC kann mich mal.
Im Notfall kann man seinen CString in einen Namespace packen.
Übrigens ist das noch weit entfernt von der ungarischen Notation, weil wir uns manchmal neue Präfixe ausdenken. Ich kann einfach nicht mehr ohne Präfixe. Ich behalte da einfach besser den Überblick. Ist Geschmackssache, denke ich.
edit:
Ich hab in WinMain.cpp ein gutes Beispiel für Präfixe gefunden.
Da wird die Fenstergröße angepasst und die Höhe der Statusleiste in die Berechnungen mit eibezogen. Da heißt es:
GetWindowRect(hStatus, &rcStatus);
Wenn ich das Präfix weglasse, kann ich nicht mehr zwischen RECT und hWnd unterscheiden. |
|
| Nach oben |
|
|
Kronos
Senior JLI'ler
Anmeldedatum: 19.03.2004
Beiträge: 290
Medaillen: Keine
|
| Verfasst am: 27.07.2005, 12:34 Titel: |
|
|
Wenn man aussagekräftige Namen wählt, passiert sowas nicht
Außerdem sind solche Geschichten wie
nicht wartbar. Wenn du den Typ änderst, dann musst du durch die Änderung auch überall den Namen ändern, was nicht praktikabel ist.
Wenn ich mal was zitieren darf (aus How to write unmaintainable code):
| Zitat: |
Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack. The following tips will help you corrupt the original intent of Hungarian Notation:
* Insist on using "c" for const in C++ and other languages that directly enforce the const-ness of a variable.
* Seek out and use Hungarian warts that have meaning in languages other than your current language. For example insist on the PowerBuilder "l_" and "a_ " {local and argument} scoping prefixes and always use the VB-esque style of having a Hungarian wart for every control type when coding to C++. Try to stay ignorant of the fact that megs of plainly visible MFC source code does not use Hungarian warts for control types.
* Always violate the Hungarian principle that the most commonly used variables should carry the least extra information around with them. Achieve this end through the techniques outlined above and by insisting that each class type have a custom wart prefix. Never allow anyone to remind you that no wart tells you that something is a class. The importance of this rule cannot be overstated: if you fail to adhere to its principles the source code may become flooded with shorter variable names that have a higher vowel/consonant ratio. In the worst case scenario this can lead to a full collapse of obfuscation and the spontaneous reappearance of English Notation in code!
* Flagrantly violate the Hungarian-esque concept that function parameters and other high visibility symbols must be given meaningful names, but that Hungarian type warts all by themselves make excellent temporary variable names.
* Insist on carrying outright orthogonal information in your Hungarian warts. Consider this real world example: "a_crszkvc30LastNameCol". It took a team of maintenance engineers nearly 3 days to figure out that this whopper variable name described a const, reference, function argument that was holding information from a database column of type Varchar[30] named "LastName" which was part of the table's primary key. When properly combined with the principle that "all variables should be public" this technique has the power to render thousands of lines of source code obsolete instantly!
* Use to your advantage the principle that the human brain can only hold 7 pieces of information concurrently. For example code written to the above standard has the following properties:
o a single assignment statement carries 14 pieces of type and name information.
o a single function call that passes three parameters and assigns a result carries 29 pieces of type and name information.
o Seek to improve this excellent, but far too concise, standard. Impress management and coworkers by recommending a 5 letter day of the week prefix to help isolate code written on 'Monam' and 'FriPM'.
o It is easy to overwhelm the short term memory with even a moderately complex nesting structure, especially when the maintenance programmer can't see the start and end of each block on screen simultaneously.
|
und
| Zitat: |
One followon trick in the Hungarian notation is "change the type of a variable but leave the variable name unchanged". This is almost invariably done in windows apps with the migration from Win16 :- WndProc(HWND hW, WORD wMsg, WORD wParam, LONG lParam) to Win32 WndProc(HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam) where the w values hint that they are words, but they really refer to longs. The real value of this approach comes clear with the Win64 migration, when the parameters will be 64 bits wide, but the old "w" and "l" prefixes will remain forever.
|
Aber gut, hier soll es ja nicht um die ungarische Notation gehen, daher lassen wir das jetzt
_________________
| David hat Folgendes geschrieben: | | Solang meine Beiträge konstruktiver sind als deiner bin ich zufrieden... |
Kein Kommentar notwendig. :rolleyes: |
|
| Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
Powered by phpBB © 2001, 2005 phpBB Group
Deutsche Übersetzung von phpBB.de |
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Medaillen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
