Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

1

23.06.2007, 21:59

Code lesbarkeit

Ich arbeite vielleicht bald mit 2 Freunden an einem Spiel und habe zu meinem Codestil eine Frage

Ich habe als kleines Beispiel ein typisches Zufallsspiel programmiert
(wie in Heikos Buch)

hier ist mal der Quelltext vom Hauptprogramm:

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
#include "cRandom.h"

//Glabale Instanz von cRandom

cRandom gameRandom(10);

//Eingegebener Versuch

int input;

//Bereich festlegen

void setLevel();

//Spielen

void game();

//Hauptfunktion

int main()
{
    //Wahl im Hauptmenü

    int chose;

    //Zufallsgenerator erzeugen

    srand(timeGetTime());

    //Spielschleife

    do
    {
        //Hauptmenü

        cout << "\n\n*-- Zufallsraten --*\n\n";
        cout << "<1> Level setzen\n";
        cout << "<2> Spielen\n";
        cout << "<0> Spiel beenden\n\n";

        //Menüwahl einlesen

        cin >> chose;

        //Menüwahl auswerten

        switch(chose)
        {
        case 1:
            //Bereich festlegen

            setLevel();
            break;
        case 2:
            //Spielen

            game();
            break;
        case 0:
            //Nichts tun

            break;
        default:
            cout << "Fehlerhafte wahl!\n\n";
            break;
        }

    }while(chose != 0);

    return 0;
}

void setLevel()
{
    int iMax;

    //Wiederholen bis die Levelzahl korekt ist

    do
    {
        cout << "Level angeben! (1-50)\n";
        cin >> iMax;

        //Wenn Levelzahlö nicht korrekt ist, Meldung ausgeben

        if((iMax < 1) || (iMax > 50))
        {
            cout << "Kein bekannter Level!\n";
        }
    }while((iMax < 1) || (iMax > 50));

    //Max setzen

    gameRandom.setMax(iMax * 10);
}

void game()
{
    //Versuche

    int tries = 0;

    //Punkte

    int points = gameRandom.Max * 100;

    //Zufallszahl erzeugen

    gameRandom.setRandom();

    //Wiederholen, solange die Eingabe nicht der Zufalszahl entspricht

    do
    {
        cout << "\nZahl eingeben!\n";

        cin >> input;

        //Falls Eingabe richtig

        if(input == gameRandom.random)
        {
            cout << "RICHTIG!!!\n";
        }

        //Fals Eingabe zu groß

        else if(input > gameRandom.random)
        {
            cout << "Die gesuchte Zahl ist kleiner!\n";
        }

        //Falls Eingabe zu klein

        else if(input < gameRandom.random)
        {
            cout << "Die gesuchte Zahl ist groesser!\n";
        }

        tries ++;

    }while(input != gameRandom.random);

    //Punkte = Maximale Punkte Pro Level - Versuche * 10

    points -= tries * 10 + 10;

    //Punkteantahl ausgeben

    cout << "Punkte: " << points;
}


es gibt noch 2 Dateien, die die cRandom Klasse beinhalten

meine Frage ist folgende:

ist der Code gut lesbar und richtig kommentiert und ist der Codestil
gut genug für ein größeres Projekt wie ein 3D-Spiel?

LagRange

Frischling

Beiträge: 26

Wohnort: dzt. Aalborg, DK

Beruf: Student

  • Private Nachricht senden

2

23.06.2007, 22:28

Mein persönlicher Geschmack:

Nicht jede Zeile dokumentieren. Das macht alles irgendwie unübersichtlich.
Der Code sollte an sich möglichst selbsterklärend sein ("Globale Instanz von cRandom" z.B. ist schon allein aus der Deklaration ersichtlich). Sprechende Variablennamen innerhalb von Blöcken reichen um deren Aufgabe zu erklären.
Wichtig ist aber die Dokumentation von Klassen, Methoden, globalen Funktionen, etc. so dass man gleich weiß was diese machen, ohne die Implementierung ansehen zu müssen.
Und Blöcke sollten nicht zu lang sein. Sofern man ein wenig Overhead verkraften kann ziehe ich es vor lange Blöcke in Unterfunktionen aufzuteilen (z.B. Hauptmenü nicht in der Spielschleife sondern in einer eigenen Funktion)
Science is common sense applied to evidence.

3

23.06.2007, 22:57

stimmt.

reicht ja eigentlich wenn man z.B.

C-/C++-Quelltext

1
2
3
//Funktionsprototypen

void game();
void setLevel();

schreibt.

Danke!

koschka

Community-Fossil

Beiträge: 2 862

Wohnort: Dresden

Beruf: Student

  • Private Nachricht senden

4

23.06.2007, 23:44

Wie LagRange (nicht der Mathematiker :D) schon sagte ist es besser nicht jede Zeile zu dokumentieren.
Meine Erfahrungen (auch Teamarbeit) sind, das nicht jedes Teamitglied gleich kommenteieren, aber sehrwohl dokumentieren sollte.

Beim kommentieren reicht es meiner Meinung wenn man grob sagt was das tut, z.B. "Holt alle Benutzer aus dem System", "geht alle Soundateien durch" oder so, in tieferen Ebenen kann man das dann natürlich noch konkretisieren wie z.B. "... und sucht nach Sound "bangbuffplatz" ".

Zum Dokumentieren sollte man Tools nehmen, für C/C++ Doxygen, für Java JavaDoc (bei eclipse mit dabei). Da man eh da Parameter angeben kann (z.B. @param, @return etc.) Sollte die Dokumentation im Team auch einigermaßen gleich und übersichtlich sein. Wie gesagt aber nur wichtige, also meist öffentliche / vererbbare Methoden/Attribute sowie Klassen, Interfaces und Abstraktes Kram dokumentieren.

ChrisJ

Alter Hase

Beiträge: 487

Wohnort: Schweich

Beruf: Schüler

  • Private Nachricht senden

5

24.06.2007, 01:24

ein dickes plus, sind die sprechenden variablennamen - das macht dein programm gut lesbar.
"Don't trust your eyes: They are a hell of a lot smarter than you are"

Fred

Supermoderator

Beiträge: 2 121

Beruf: Softwareentwickler

  • Private Nachricht senden

6

24.06.2007, 10:07

In einem buch hab ich neulich gelesen:
Die Kunst des Kommentieren liegt nicht darin hinzuschreiben, was jeder sehen kann, sondern eine Erklärung zu geben, warum etwas geschieht.

Faule Socke

Community-Fossil

Beiträge: 1 915

Wohnort: Schreibtischstuhl

  • Private Nachricht senden

7

29.06.2007, 23:10

du kannst mit den kommentaren ruhig etwas sparsamer umgehen. kommentier nur die nötigsten stellen. Dokumentation ist wesentlich wichtiger.

Ausserdem ist es hilfreich, rechtschreibfehler zu vermeiden.(Beim code funktioniert das bei mir irgendwie von alleine nur bei den kommentaren schreibe ich schon absichtlich langsamer, um buchstabendreher zu vermeiden.)

naja mir fällt nix mehr ein was ich dir noch so an tipps geben könnte.

PS: Ich habe eine eigene Art von Notation etwikelt. Kommt von der ungarischen ist aber in einigen bereichen anders.


Socke

riCo

Treue Seele

Beiträge: 165

Beruf: Student

  • Private Nachricht senden

8

12.07.2007, 15:06

Ich hoffe du musst nie Programme mit mehr als 1000 Codezeilen programmieren.. :)
Wir leben alle unter dem Sternenhimmel, aber wir haben nicht alle den gleichen Horizont.

dax.

Frischling

Beiträge: 24

Beruf: Mathematiker (Student)

  • Private Nachricht senden

9

16.07.2007, 15:47

Das kommentieren ist absolut wichtig in grösseren Projekten. Heute mag vielleicht trivial erscheinen, was in den kommentaren steht, aber wochen, monate, jahre und 100 000de zeilen quellcode später ist man froh über jedes einzelne kommentar.

Wenn du wissen willst wie man effektiv kommentiert schau dir den artikel an:
http://www.gamedev.net/reference/articles/article1384.asp
Weiter ist es wichtig auch tools wie doxygen zu verwenden! Aber doxygen ersetzt keinesfalls eine komplette dokumentation eines quellcodes.
Siehe auch http://www.gamedev.net/reference/articles/article1764.asp (muss ja kein buch werden, aber das projekt einmal klar illustrieren).

mfg
dax.
>> blub <<

Werbeanzeige