Konsolenspiel - Snake Race(v2.0)

[lustig]

Mir hat das Spiel ziemlich gut gefallen. Schön sauber und einfach gehalten, funktioniert gut :).

Zum Sourcecode: Habe mir jetzt nicht alles angesehen, nur ein paar kleine Kommentare. Und nein, ich werde keine Noten (oder Prozente) vergeben ;).

Variablen / Konstanten:
- Variablennamen sollten nicht mit _ beginnen. Das ist zwar nicht verboten, aber unschön (wie z.B. const string _modus = ...).
- Konstanten werden meistens nur mit Grossbuchstaben geschrieben. Z.B. WEISS statt weiss
- Verwende doch const statt #define um deine Konstanten zu definieren
- Ich würde dir empfehlen nur eine Sprache für Variablennamen etc. zu verwenden und nicht unbedingt zu mischen (kleines Detail am Rande)

//ASCII-Zahlen für jeden Buchstaben und spezielle zeichen
#define Aa 97
#define Ab 98

Das ist ziemlich unnötig: 'a' ist 97 und besser lesbar als Aa.

Wiederholungen (unnützer Code, ersetzung durch Funktionen) [1-100%]

Da gibt es noch Optimierungspotential :). Du hast z.B. relativ oft Zeilen wie:

color(rot);
gotoxy(25, 15);
cout << "<- Maximum erreicht!";
color(weiss);

in unterschiedlichen Variationen. Wäre es nicht angenehm wenn du eine Funktion hättest wie:

printTextAt("<- Maximum erreicht!",25,15,rot)

mit der Farbe als optionales Argument?
Anderes Beispiel: Du hast die 4 Fälle: Nach oben bewegen, nach unten bewegen, nach rechts bewegen und nach links bewegen. Dabei hast du viel Code 4 mal praktisch genau gleich. Es wäre einfacher, da Funktionen zu verwenden. Z.B. eine Funktion die aufgerufen wird, wenn der Spieler das Spiel verliert. Die würde dann die Sounds abspielen, Bildschirm leeren, "VERLOREN" anzeigen, warten, fragen ob man nochmals spielen will. Schau mal wie oft du nur diesen einzelnen Block verwendest (und ich habe mir nur einen einzigen Spielmodus angeschaut ).

Das sind ein paar mehr oder weniger zufällige Dinge (nicht eine komplette Liste), die mir durch den Kopf gegangen sind, als ich deinen Code überflogen habe. Das sind alles Vorschläge, mehr als Denkanstösse gedacht, nicht als Kritik. Grundsätzlich hast du ein lauffähiges Spiel, das ist schon sehr viel :).

Ausserdem:
Hast du dich schonmal etwas mit Klassen etc. beschäftigt? Es wäre z.B. schön, dein Spielfeld durch eine Klasse zu kapseln. (Nur so als Hinweis, wenn du keine Ahnung hast was eine Klasse ist, einfach ignorieren :xmas1: )

Ach ja, wenn du fragen hast, oder möchtest dass wir uns z.B. ein Codestück genauer ansehen, einfach fragen :).

Edit: Hatte den Sound am PC ausgeschalten, als ich dein Spiel gespielt habe. Kann also nichts darüber sagen.

[Incocnito]

Erst mal Danke, dass du dir Zeit genommen hast, den Code anzusehen.

Das mit den Prozenten, war auch nur für Leute gedacht, die schnell eine Bewertung machen wollen.^^

Hm, wieso sollte ich denn keine Unterstriche _ verwenden?
Ist #define für Konstanten nicht C? Ich hab jetzt mit Absicht const genommen.
Und das präfix-A hab ich genommen, da es ja vorkommen kann, das ich mal irgendwann char a; brauchen könnte. Das präfix A ist nur für die Übersichtlicher (soll für ASCII stehen :))

Und was das mit den Wiederholungen angeht, hatte ich bereits den selben Gedanken wie du. Da es sich bei color allersings um ein Makro handelt (welches ich aus dem Internet kopiert hab, ich beschäftige mich nicht wirklich mit der winAPI) kann man das doch schlecht als Parameter an eine Funktion übergeben, oder wie soll das gehen?

Und ja, das mit dem rechts links usw. ist recht umständlich. Ich glaube ich werde für das überprüfen des jeweiligen feld-chars eine Funktion schreiben, die das ganze dann auswertet und jeweilige Sounds abspielt und Meldungen ausgibt. Da hast du wohl recht

Klar weiß ich was Klassen sind, im nachhinein ist mir aufgefallen, dass man es viel leichter hätte lösen können, wenn ich eine Klasse "Level" geschrieben hätte. Das wäre dann einmal massig Code, ließe sich dann aber sehr einfach per

Level Modus_eins(ohne_ende_werte);
Modus_eins.set_sleep_x(bla);
Modus_eins.start();
Level Modus_zwei;
//usw.

abändern. Leider fiel mir erst etwas später auf, dass es sich um ein doch relativ umfangreiches Projekt handelt, sodass es jetzt zu viel Arbeit wäre, alles Objektorientiert umzuschreiben. Oder?

EDIT: Wie soll ich denn das Spielfeld mit einer Klasse realisieren? So in der Art:

class Feld {

int X;
int Y;

public:
void ueberpruefe(int X, int Y);
usw.
};

Oder wie soll ich das machen?

[lustig]

Also

Incocnito schrieb:

Hm, wieso sollte ich denn keine Unterstriche _ verwenden?

Ich zitiere mal aus Stroustrups Buch

Die C++ Programmiersprache schrieb:

Mit einem Unterstrich beginnende Namen sind für spezielle Mittel der Implementierung und der Laufzeitumgebung reserviert, daher sollten solche Namen nicht im Anwendungsprogramm benutzt werden.

Ist #define für Konstanten nicht C? Ich hab jetzt mit Absicht const genommen.

Genau, du solltest nicht #define verwenden wie in rubbish.h.

Und das präfix-A hab ich genommen, da es ja vorkommen kann, das ich mal irgendwann char a; brauchen könnte. Das präfix A ist nur für die Übersichtlicher (soll für ASCII stehen :))

Es geht mir weniger um das Präfix-A, sondern vielmehr darum dass du etwas unsinniges definierst (abgesehen von ESC / Pfeiltasten). Immer wenn du Aa brauchst, könntest du auch 'a' schreiben. Das ist lesbarer unabhängig davon ob du deine Konstante Aa oder ASCII_A nennst. Diese Konstanten sind unnötig. Du kannst z.B. auch schreiben testVariable='a'+1 (gibt 'b' bzw. 98). Du musst nicht den Zahlenwert extra abspeichern.

Da es sich bei color allersings um ein Makro handelt (...) kann man das doch schlecht als Parameter an eine Funktion übergeben, oder wie soll das gehen?

Das kannst du schon (obwohl ich, wie schon gesagt Konstanten verwenden würde). Erstens: Du musst nicht das color Makro übergeben, sondern die Farbe. Das makro ist bekannt, wenn du in dem File in dem du die Funktion implementierst dein "rubbish.h" (wirklich blöder Name :P) includierst. Laut der Hilfe zu SetConsoleTextAttribute wird die Farbe als unsigned short übergeben. Also hast du etwas wie printTextAt([...], unsigned short fgColor). In der Funktion kannst du dann color(fgColor) verwenden oder alternativ statt dem color Makro direkt den Aufruf der WinAPI-Funktion.
Hmm, ich hoffe du bist jetzt nicht verwirrter als vorher.

[quote]sodass es jetzt zu viel Arbeit wäre, alles Objektorientiert umzuschreiben. Oder?[quote]
Ja, das ist sicher so. Es ist mir nur aufgefallen.

Edit: Habe jetzt keine Zeit mehr dein Edit zu beantworten. Mache ich dann morgen, falls das dann noch niemand anderes gemacht hat ;).

[Incocnito]

Hoppla, da hast du recht, wozu dann das ganze mit Aa
Werd ich (über)morgen abändern. Und die Funktion werde ich dann auch so machen, wie du gesagt hast (keine Angst, bin nicht verwirrt, war ich vorher auch nicht ). Mir ist nur eben aufgefallen, das ich ziemlich verpeilt war und vergessen hab, dass das ganze ja als ZAHLEN gespeichert sind, ich Idiot
Erst denke ich.. hää wie soll man denn einen Text als Parameter übergeben.. Achja, das sind ja ZAHLEN xD
Ja, dann rufe ich einfach mit den jeweiligen Zahlen gleich die Funktion auf, denke ich.
Ich sitz wohl zu lange vor dem PC für heute. Morgen ist ja auch schon Weihnachten..
Jo, rubbish steht einfach nur für alles Mögliche was sich so in den Jahren angesammelt hat.. ^^

Gut Unterstriche entferne ich dann auch.
Und const statt #define, merk ich mir.

Danke dafür

Also, allen frohe Weihnachten :xmas2:

[lustig]

Und die Funktion werde ich dann auch so machen, wie du gesagt hast

Das waren nur Beispiele, schau den Code durch und überlege dir, was du doppelt und dreifach machst (wie wäre es z.B. mit einer Funktion erstelleSpielfeld(anzahlBrunnen)? um ein weiteres Bsp. zu nennen). Es geht ja darum, dass du merkst für was man Funktionen brauchen könnte um den Code übersichtlicher zu machen.

[cooky451]

Habs mir nur kurz angesehen, vielleicht schaue ich später noch mal über den Code..
Aber nur so nebenbei.. sind die CS-Sounds eigentlich frei?

[Incocnito]

Keine Ahnung, die sind noch vom alten 1.6 (das ist von 2003). Aber ich glaube das stört wohl niemanden

[Incocnito]

Soo, falls es noch jemanden interessiert, ich arbeite jetzt wieder an dem Projekt weiter.
Ich hab die Ratschläge von lustig berücksichtigt und erstmal alle #define direktiven durch const und Funktionen ersetzt. Außerdem habe ich statt zb. 'Aj' einfach 'j' genommen, womit die Konstanten dafür nutzlos werden.
Außerdem bin ich nun dabei, für jede Modus-Datei eine Header zu schreiben, die den jeweiligen Bewegen-Funktion-Prototyp beinhaltet. Ich konnte keine allgemeine Funktion schreiben, da bei jedem Modus ja in eine andere Highscore-Datei geschrieben wird, ander Sounds verwendet werden und noch diverse andere Kleinigkeiten anders ablaufen. Die Definition dieser 'speziellen' Bewegungsfunktion schreibe ich dann gleich mit in die selbige Datei 'Modus_X.cpp', Ich habs nämlich so gelernt, dass in Headerdateien niemals Funktions-Definitionen stehen.
Ich werd das dann morgen oder so hochladen, eben wenn ich fertig bin.
Und ich werd das ganze mal bei sourceforge.net hochladen, file-upload gefällt mir nicht besonders.

ps. Ich hab schon fast 70 Downloads, das hätte ich nicht erwartet

EDIT: Mir ist gerade noch etwas aufgefallen. Wenn ich eine Funktion "void bewegen(...)" schreiben will, muss ich fast 10 Variablen übergeben. Ich werde wohl eine Struktur Player oder so schreiben müssen, wo das dann gespeichert wird.

[Incocnito]

Ach was, mir ist es jetzt egal, wie lange das dauern wird: ich schreibe mir jetzt eine geeignete Klasse und mache das ganze Objektorientiert. Wenn mir dann etwas auffällt oder ich Fragen hab, werde ich mich hier wieder melden

[Incocnito]

Also endlich, ich habs dann doch noch geschafft. Snake Race ist nun Objektorientiert^^
Jetzt brauch ich natürlich wieder eure Hilfe. Ich muss natürlich wissen, was ihr von meinem Code haltet. Die Größe hat sich mal eben halbiert, und das bei gleichbleibender Leistung.
Ich hab jetzt 2 Klassen: Einmal Spiel (Spiel.h und Spiel.cpp) und Feld (Feld.h und Feld.cpp).
Wie hätte man es besser lösen können?
Und wie findet ihr den Codestil, hab ich was falsch gemacht?
Und dann eben die selben Fragen wie vorher auch.
Ich hab das ganze jetzt nicht auf sourceforge.net hochgeladen, sondern wieder auf file-upload.net:
Snake Race feat cs 1.8
Ich freu mich schon auf Rückmeldungen im Bezug auf den Quellcode

[BasicMan01]

Lustiges Teil Aber mir viel was auf

Die Highscore als Klartext in einer exe halte ich eher für gewöhnungsbedürftig.
Nehm lieber sowas wie .dat und speichere die Daten binär.
Außerdem gibts da noch ein Formatierungsproblem mit dem Datum >>> 030.1.2011

Es gibt einen Grafikbug bei Modus 1, nach dem das Spiel gewonnen wurde und
der Name eingegeben wurde.
Bestätigt man das weitere Spielen mit "n" so gibt es lustige Effekte. Die Schlange
beginnt trotzdem von neuem

> auch bei Modus 2

Modus 3: Nach dem einsammeln des ersten Objekts ist das Spiel bereits zu Ende

Code hab ich mir allerdings nur mal grob angeschaut aber mir viel auf:

1. modus_eins bis modus_vier
sieht mir bissl nach Copy-Paste aus und abändern, was anders ist.
Hier bieten sich ebenfalls Klassen / Vererbung an. z.B. Basisklasse Modus und dann Kindklassen ModusFoo und ModusBar.

2. es gibt viele identische Codesegmente, die überall auftauchen. Zentralisiere solche Sachen und nutze Funktionen.
Beispiel:

system("cls");
                    make_rang();
                    gotoxy(1, 1);
                    std::cout << "Gebe deinen Namen ein (keine Leerzeichen und max. 10 Zeichen): "; //gewinner bekannt machen
                    std::string gewinner;
                    std::cin >> gewinner;
                    set_name(gewinner);
                    if(gewinner.size() > 10) {
                        color_cout(10, 30, GELB, "Name zu gross!");
                        Sleep(1000);
                        while(kbhit()) getch();
                        continue;

Schreib dir hier eine Funktion enterName, dann musst du diesen Schnipsel nicht überall reinkopieren

3. Entscheide dich für eine Sprache
-Deutsch
-Englisch
-Denglisch (natürlich nicht :D)

4. vielleicht an der ein oder anderen Stelle sinnvollere Namen wie get_durch() << ??? denn ich muss lange suchen, was "durch" ist

5. Bei Übergabe von Objekten an Klassen nutze Referenzen
von char Feld::get_zeichen(const Spiel para) const
nach char Feld::get_zeichen(const Spiel &para) const

Mach dir vielleicht mal ein Klassendiagramm. Was brauchst du für Klassen. Was sollen diese für Daten kapseln. Was muss wo drauf zugreifen. Quasi ein Konzept, bevor du anfängst wild umzubauen.

[Incocnito]

Erst mal danke für die Anwort!

Highscore als Klartext in einer .exe hab ich deswegen gemacht, damit man die Highscores nicht so einfach abändern kann (sowas wie rechtsklick -> öffnen mit geht bei einer .exe ja nicht), und außerdem weiß ich auch nicht, was binär speichern bedeutet^^

Der Formatierungsfehler war ein kleiner Tippfehler, den hab ich eben behoben.

Einen Grafikfehler gibts bei mir nicht
Ich hab jetzt einfach mal ein break dabei eingefügt, und noch einige Dinge so abgeändert, dass es funktionieren sollte.

Zu 3: Sowas aber auch :D:D Ich war noch beim debuggen, und weil ich nicht jedes mal 15 Punkte einsammeln wollte hab ich die Punkte gleich mal auf 14 gesetzt, damit ich sehen konnte, ob alles funktioniert. Ist jetzt wieder auf 0

Zum Code:

Naja es sind eben viele Kleinigkeiten die geändert werden, sodass es schwierig für mich war, das ganze nur einmal zu schreiben. Da ich jetzt nicht so ein Profi mit Klassen bin, ist mir das noch zu kompliziert.

Gut, die Variablennamen sind vielleicht nicht immer beste Wahl - statt y_minus hätte man auch stumpf RECHTS benutzen können, aber was solls. Darauf achte ich dann beim nächsten mal

Eigentlich hab ich immer auf die richtige Verwendung von const und Referenzen geachtet, ich kann das aber auch mal übersehen haben.

Ich hab das geupdatete nochmal hochgeladen, tritt der Grafikfehler bei dir immer noch auf?
Link: Download

[BasicMan01]

Incocnito schrieb:

damit man die Highscores nicht so einfach abändern kann (sowas wie rechtsklick -> öffnen mit geht bei einer .exe ja nicht)

Wo hast du das denn gelesen. Öffne mal notepad und zieh des Teil per drag&drop rein

Ja, der Grafikfehler ist bei mir nun behoben ... löblich löblich.
Dann bin ich mal auf Version 2.0 gespannt

[Incocnito]

Ich hab nochmal ordendlich optimiert. Die main.cpp ist von 16kB auf 6kB gesunken und in jeder modus_x.cpp - datei stehen nun weniger als 200 zeilen
Ohne eure Hilfe hätt' ich das nicht geschafft.
Ich hab also nochmal einige neue Funktionen geschrieben zu so ziemlich allem, was doppelt vorkam. Wenn ihr noch irgendwas findet, was doppelt vorkommt und woraus man eine Funktion basteln könnte, wär das wirklich cool. Mal sehen, ob ihr noch irgendwas findet, es ist jetzt ja schon extrem wenig geworden ^^

Ach ja, natürlich kann man leicht eine exe im Editor öffnen, ich weiß das schon. Nur wissen das eben viele Computer-Noobs nicht, und deswegen ist es wenigstens ein kleiner Schutz. Außerdem ist die Endung ja prinzipiell egal - und wenn die exe in diesem Fall das leichte rumeditieren um einige Sekunden verzögert, warum nicht^^
Ansonsten würde ich gerne wissen, wie ich das "binär" speichern sollte, und wie ich das dann wieder lesen kann.

Hier der aktuelle Downloadlink: Download

[lustig]

Zu Dateien in C++ gibts auch einen FAQ Eintrag, da steht auch wie man eine Datei binär öffnet / liest / schreibt.

http://www.c-plusplus.net/forum/39469

[Incocnito]

Ich hab jetzt nochmal wieder ordentlich was geändert und alles erreicht, was ich in Version 1.8 erreichen wollte.

Ich werde dann weiterhin etwaige Aktualisierungen und neue Versionen hier posten, und dann könnt ihr auch noch Kritik/Verbesserungsvorschläge zum Spiel äußern. Nachdem ich nun tagelang mit dem Code beschäftigt war, wirds Zeit wieder was neues zu adden
Den neuesten Downloadlink findet ihr dann immer auf der ersten Seite dieses Threads.
Die neueste Version mit dem umgekrempelten Menu findet ihr auch dort.

[Incocnito]

So, Version 1.9 ist nun fertig.

Es gibt nun Items, die einem Spielvorteile verschaffen können. Außerdem wurde das Menu komplett umgekrempelt und benutzerfreundlicher gestaltet.
Was geändert wurde steht aber auch noch mal im Programm beim ersten Start und natürlich in der Versions.log. Downloadlink auf der ersten Thread-Seite zu finden.

Viel Spaß^^

[lustig]

Ich habe mal kurz über den neuen Sourcecode geschaut (naja, über einen Teil zumindest ).
Erst mal Kompliment, das sieht schon viel aufgeräumter auf.

2 Dinge fallen trotzdem auf. Du hast jetzt eine Klasse geschrieben für dein Spiel. Im Moment ist das aber vom Prinzip her eher eine Struktur mit ein paar Hilfsfunktionen. Du hast für _jede_ Variable eine get und set funktion, die nichts anderes machen als den Wert der Variable ohne überprüfung zu setzen bzw. zurückzugeben.
So könntest du ja gerade so gut alle Variablen public machen und hättest dir eine Menge Schreibarbeit gespart.

Ein Beispiel was z.B. verändert werden könnte.

drei.set_points(drei.get_points()+1);
            gotoxy(13, 55);
            cout << drei.get_points() << " von 15 Punkten";

Immer wenn du die Punkte veränderst willst du auch die Punkteanzeige am Bildschirm updaten. Lass das doch deine Klasse (bzw. die set Funktion) machen. Die Set Funktion würde dann immer wenn die Punkte geändert werden, diese auch an die entsprechende Position am Bildschirm schreiben. So weisst du dass die Anzeige immer mit der Punktzahl übereinstimmt.
Evt. sollte die set Funktion sogar noch mehr machen, z.B. überprüfen ob du schon gewonnen hast. Wenn ja kannst du ja true zurückgeben sonst false.
Ausserdem bietet es sich auch an eine erhoehe_Punkte Funktion zu schreiben, wenn du öfters so etwas wie oben machst.
Oder

zwei.setze_richtung(c);
        } //if(kbhit())

        if(!zwei.get_x_plus()  && !zwei.get_y_plus()
        && !zwei.get_x_minus() && !zwei.get_y_minus()) continue;

wie wäre es, wenn setze_richtung die überprüfung gleich durchführt und das Ergebnis zurückliefert?
Das gilt nicht nur für die Spiel Klasse sondern für alle, das zieht sich durch den ganzen Code... z.B. auch wenn du den Spieler auf ein Feld setzt machst du jede Menge abfragen (ist da ein Brunnen? Spieler nicht zeichnen. Ist da eine Wand? Spieler vor der Wand zeichnen. etc.). Wäre es nicht einfacher, wenn du eine Funktion hättest die all das erledigt sobald du die Position des Spielers änderst (und dann halt zurückgibt, ob er noch lebt).

Zweiter Punkt: Deine modus1, modus2, modus3, etc. files sind fast identisch. Da brauchst du eigentlich nur eine Funktion, bei dem du das Spiel je nach Modus mit unterschiedlichen Start / Gewinn Werten initialisierst.

[Mr X]

Ich find das Spiel gut! Sourcecode hab ich nur überflogen. Auslachen lassen musst Du dich deswegen keinesfalls!

Tipps/Anmerkungen/Prinzipienreiterei:

• Verwende enums (z.B.: rest.h, "farben für die color-funktion")
• Vermeide Wiederholungen (Ja, damit wiederhole ich nur, was mein Vorredner schon sagte^^)
• in den einzelnen Modus-Funktionen setzt Du jeweils den random-seed. Mach das doch einmal ganz vorne in main(), dann brauchst Du das im ganzen Programm nicht wieder.
• Das zusammenstückeln der Strings wie z.B. in rest::hilfe_modus ist unästhetisch und macht den Code nicht lesbarer. Ich glaube, derartige Optimierung ist in einem solchen Programm an dieser Stelle etwas übertrieben.
• Bei den get/set-Funktionen kann ich meinem Vorredner nur zustimmen.
• Es wäre gut, wenn Du deinen Einrückstil etwas konsequenter befolgen würdest - das macht den Code lesbarer
• using namespace std; ist zwar eine Tipperleichterung, aber es hat einen Grund, dass die Funktionen in einen namespace gelegt wurden: Diesen nun in den global namespace auszukippen macht den Vorteil zunichte, dass man bei der Benennung eigener Variablen/Funktionen nicht darum scheren muss, ob es vielleicht eine gleichnamige Funktion in der Standardbibliothek gibt. -> Ich weiß, es ist mühsam, immer std:: davor zu schreiben, aber ich würds mir angewöhnen.
• int main() fehlt das return 0; am Ende. Ja, (leider) muss man es nichtmehr schreiben, aber ich finds inkonsequent, es wegzulassen.

mfg
Mr X

[Incocnito]

Hm das mit den Überprüfungen in den get/set Methoden scheint sinnfoll, das werde ich wohl machen. Gute Idee^^

Ja, eine Funktion die das ganze zeichnet und überprüft ob er noch lebt, bzw. wie er gestorben ist, wäre auch nicht schlecht.

Zu den verschiedenen Modi:
Es sind ja nicht nur die Anzahl der Objekte und die Geschwindigkeit die sich unterscheiden. Die Schrittbegrenzung ist anders und in Modus 3 und 4 gar nicht erst vorhanden, die maximale Punktzahl ist anders, bei Modus 4 wird beim verlieren immer der Name abgefragt, bei Modus 1, 2, und 3 nicht, im vierten Modus gibt's ab 20 Punkten noch extra-Objekte, bei jedem Modus-Start wird ein anderer text animiert und andere Farben verwendet uvm.
Es wäre ziemlich schwierig, eine Funktion zu schreiben, die dann jedes mal überprüfen müsste, welcher Modus gemeint ist (Ist es der vierte? Keine Schrittbgrenzung, kein Punktelimit, Text animieren usw., ist es der zweite? Schrittlimit 800, kein Punktelimmit, den Text animieren usw.).
Das sind eben alles Kleinigkeiten die in den Modi anders sind.

Okay, enums könnte ich verwenden, gute Idee.
Und stimmt, srand() vorzubereiten brauche ich nur einmal. Das mir das nicht aufgefallen ist o.o
Echt nicht? es sind nämlich nur 2 Wörter die sich unterscheiden, sodass es mir sinnfoll schien, einfach zu überprüfen welcher Modus übergeben wurde.
Ja, ich bin zwischendurch auf 2 Leerzeichen pro Tab umgestiegen, da hast du recht.
Das stört mich allerdings schon mit using namespace std;
Denn bei einem Quellcode mit knapp 500 Zeilen (was ja noch sehr wenig ist) über 100 mal std:: schreiben zu müssen, nur damit ich ein paar Funktionsnamen und Variablennamen selbst definieren kann, scheint mir eigentlich unsinnig. Außerdem, wenn etwas mal schon in std steht, dann mache ich halt den Anfangsbuchstaben groß o.ä. Und außerdem gilt using namespace std; ja nur für die aktuelle Datei.
Und zu return 0; -> wenn main sowieso 0 zurückgibt wenn mans nicht angibt, wozu sollte ichs dann angeben?

Also danke für die Tipps, da sind einige wirklich gut bei