Was ist für euch guter Programmcode?
-
void set_color (unsigned index, unsigned color) { colors_[index] = color; }
da mach ich gerne ein assert()
unsigned colors () const { return colors_.size(); }
uU zweideutig? colors() könnte ja auch das array returnen...
World &world () const { return world_; }
Das mag ich nicht: World &world
ein World *p;
ist OK, weil man sagen kann, dass * zur variablen gehört
aber bei einer funktion kann ich mir das nur schwer vorstellenWorld (WorldView *view = 0) : view_(view) {} WorldView *view () const { return view_; } void view (WorldView *view) { view_ = view; }
Soll man wirklich das view beliebig setzen können?
das ist doch nur wegen dem WorldView da, oder?
Directions direction; World &w_; int x_, y_;
unterstricht bei direction vergessen
void move (int i = -1) { //wow, was hab ich hier gemacht? Directions direction = this->direction; if (i != -1) { direction = Directions(i); } switch (direction) { case Up: y_ = y_==0 ? World::Y-1 : y_-1; break; case Down: y_ = y_+1==World::Y ? 0 : y_+1; break; case Left: x_ = x_==0 ? World::X-1 : x_-1; break; case Right: x_ = x_+1==World::X ? 0 : x_+1; } }
Das frage ich mich auch
und deshalb sag ich nix dazu
SDLView::draw () { for (int x = 0; x < world().length(); ++x) { for (int y = 0; y < world().height(); ++y) { sdl::Screen::get_screen().put_pixel(x, y, color_map_[world().color(x,y)%color_map_.colors()]); } } sdl::Screen::get_screen().sync(); }
Oh, fäält mir erst jetzt auf: world.length und world.height? warum nicht width statt length?
#ifdef R Syntax Error #endif #ifdef L Syntax Error #endif
??
wenn schon error, dann geht doch #error
aber warum nicht einfach "umdefinen" und nachher zurück definen?#define R &Ant::move_right #define L &Ant::move_left void (Ant::*functions[]) () = { R,L }; //damit mütter den code leichter handhaben können ;) #undef R #undef L
uU könnte man bei World X und Y doch etwas dynamischer gestalten, sonst bringt sich das ableiten davon ja nicht so viel,
wenn ich immer 800x600 machen mussbis auf move() und dem R und L Ding ists aber nice
-
@Gregor
Werde mir die Annotations mal vornehmen, wenn du davon so schwärmst.Zu "final"
Gregor schrieb:
Das betrifft nicht nur das Überschreiben von Variablen. Es gibt auch andere Fehler, die dadurch frühzeitig erkannt werden. Zum Beispiel fällt es auf, wenn man vergißt, einer solchen Variablen/Konstanten in einem Konstruktor einen Wert zuzuweisen.
Ich hab keine Argumente die gegen final sprechen, allerdings finde ich deine Argumentation auch nicht überzeugender.
Ich hab noch nie jemanden gesehen, der so oft von ihnen Gebrauch macht wie Du. Hast Du damit wirklich schonmal einen Fehler entdeckt, oder ist das eher eine Tradition (von einem Prof oder so...)?
Bisher konnte ich ohne final ganz gut überleben.
-
Ich verwende final auch sehr oft. Bei Datenelementen sowieso, damit kann man auch durchaus ganz gut Fehler früher feststellen.
Bei lokalen Variablen mache ich es je nach Übersichtlichkeit. Wenn eine Methode etwas länger ist und ich einer Variable je nach Bedingung einen anderen Wert gebe, kann ich damit gut sicherstellen, dass sie nur genau einmal einen Wert kriegt.
-
groovemaster schrieb:
Hast du dir die Beiträge überhaupt durchgelesen? Es ging um Windows, nicht um Linux.
Naja, Du hast da irgendwas geredet von wegen "Nicht jedes Betriebssystem bringt Schnittstellen für Treiber mit", das hat er damit für Linux eigentlich recht wirkungsvoll entkräftet.
Zudem hab ich kein Linux, kann also im angegebenen Verzeichnis auch nicht nachschaun. Da musst du schon konkret werden, wenn du sinnvolle Argumente bringen willst.
In diesem Verzeichnis befindet sich die Dokumentation von Linux, auch zu massig Treiber-spezifischen Themen, die allesamt Deine Aussage widerlegen.
Aber ich möchte das hier ebenfalls nicht zu einem WindowsVsLinux-Thread machen; wenn Du weitere Fragen hast, dann stell sie am besten einfach in einem neuen Thread.
-
JBeni schrieb:
Ich hab noch nie jemanden gesehen, der so oft von ihnen Gebrauch macht wie Du. Hast Du damit wirklich schonmal einen Fehler entdeckt, oder ist das eher eine Tradition (von einem Prof oder so...)?
Bisher konnte ich ohne final ganz gut überleben.Das ist eine prinzipielle Sache, die in erster Linie von mir selbst ausgeht. Es ist ziemlich irrelevant, wieviele Fehler ich damit schon gefunden habe. Ich nutze jetzt auch Generics, obwohl ich früher nie Casting-Probleme ohne die Generics hatte. Früher oder später gibt es immer einen Fehler, der mit solchen Dingen rechtzeitig gefunden wird, warum sollte man also darauf verzichten? Es bietet einfach keine Nachteile (wenn man mal von 5 mehr Zeichen in der Zeile absieht) und man kann damit eine Fehlerklasse von vornherein ausschließen.
-
In welchem Kontext und nach welchen zuvor stattgefundenen Initialisierungen Du die Funktion überhaupt aufrufen darfst, wenn Du schwere Systemfehler verhindern willst? Nein.
(Wir sehen davon ab, dass das irgendwie nicht nach einem normalen deutschen Satz klingt.)
Solche Probleme hatte ich auch gelegentlich. Sowas ist hart. Da stizt man echt Ewigkeiten, bis man endlich eine Lösung gefunden hat, damit es solche Funktionen, die nur unter bestimmten Vorraussetungen aufrufen kann, nicht mehr gibt.
Aber Funktionen, bei denen dann als Kommentar steht: "mach erst dann, dann dies, dann jendes und dann einen Kopfstand und wenn dann auch nocht Dienstang und Vollmond ist, darfste sie vielleicht auch mal aufrufen", sind nicht akzeptable.
-
Du hast den Sack Reis vergessen, der noch umfallen muss.
-
Optimizer schrieb:
Du hast den Sack Reis vergessen, der noch umfallen muss.
Da habt ihr völlig recht, so eine Funktion denk ich mir als nächstes aus, die nur dann aufgerufen werden darf, wenn erst ein Sack Reis umgefallen ist.
Aber der Sack Reis wird natürlich in Direct3D animiert
ob ihr es glaubt oder nicht sogar solche Funktionen kann man sich ausdenken
-
nman schrieb:
Naja, Du hast da irgendwas geredet von wegen "Nicht jedes Betriebssystem bringt Schnittstellen für Treiber mit"
Bitte?
Wo soll ich denn sowas gesagt haben? Obwohl das für bstimmte BS teilweise zutrifft (zB DOS), das ist aber ein anderes Thema.
Ich hab lediglich gesagt, dass in der Treiberschnittstelle auch Arbeit steckt. Das ist nicht in ein paar Stunden gemacht. Und das bezog sich auf folgende AussageROFL schrieb:
Glaubst DU bei Windows war das schon immer so? Soundkarte rein, Plug'n Play und alles klappt? Das ist kein Verdienst der MS Programmierer, sondern der Hardware Industrie!
Sowas ist ein geben und nehmen. Da kann imo keiner die Lorbeeren für sich selbst beanspruchen. Soviel zum Thema... aber es ging ja eigentlich um was anderes, also offtopic.close().
-
groovemaster schrieb:
Bitte?
Wo soll ich denn sowas gesagt haben?
Keine Ahnung, aber bei einem 27-Seiten-Thread mag ich jetzt nicht suchen müssen.
-
Pfff, Weichei. Ich hab schon längere Flame-Threads verursacht.
-
nman schrieb:
Keine Ahnung, aber bei einem 27-Seiten-Thread mag ich jetzt nicht suchen müssen.
Musst du auch nicht, denn du wirst diesbezüglich nix finden.
-
ist sowas guter code: http://rafb.net/paste/results/LLUB3v51.html ?
-
lang. schrieb:
ist sowas guter code: http://rafb.net/paste/results/LLUB3v51.html ?
ne. schau mal bei www.ioccc.org, wie es die KÖNNER machen!
-
www.ioccc.org konnte nicht gefunden werden...
Un sowieso man schreibt doch nicht plötzlich einfach so was in nen monate alten Flamethread rein...
-
BloodLord schrieb:
www.ioccc.org konnte nicht gefunden werden...
Un sowieso man schreibt doch nicht plötzlich einfach so was in nen monate alten Flamethread rein...
Warum nicht?
-
lang. schrieb:
ist sowas guter code: http://rafb.net/paste/results/LLUB3v51.html ?
leider sehen alle mir bekannten open source server so aus. da braucht man sich über sicherheitslöcher nicht zu wundern.
-
http schrieb:
lang. schrieb:
ist sowas guter code: http://rafb.net/paste/results/LLUB3v51.html ?
leider sehen alle mir bekannten open source server so aus. da braucht man sich über sicherheitslöcher nicht zu wundern.
lol. der code ist cool.
hab mal ein wenig den von lightppd gelesen, um ein bug zu fixen. war eigentlich ganz lesbar un den gegenden, wo ich stöbern mußte. (aber noch weit von "hübsch" entfernt.)
-
Immer noch schöner als mein Code
Mir fällt gerade so nebenbei ein: Gibt es eigentlich einen Standard für das Zählen von Zeilennummern eines Programmes? Oft gibt man ja an "Core: 100.000 Lines" oder so ähnliches. Die könneten jetzt aber so:
1: #include <iostream> 2: #include <string> 3: using namespace std; 4: int main() { cout << "Welcome!" << endl; string eingabe; cin.getline(eingabe,80); cout << eingabe; return 0; }
oder so aussehn:
1: /*¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯/ 2: / The genius Input-Output Tool / 3: / ============================ / 4: / / 5: / Version 0.1 / 6: / (C) 2005 by whoever / 7: /__________________________________________*/ 8: 9: 10: 11: // Include section 12: 13: #include <iostream> 14: 15: /* Includes iostream standard library, required for 16: using cin and cout methods. */ 17: 18: #include <string> 19 20: /* Includes string standard library */ 21: 22: // End of include Section 23: 24: 25: using namespace std; // Sets namespace std 26: 27: 28: 29: int main() 30: 31: /* Function main... 32: (stupid discription) ... */ 33: { 34: 35: cout << "Welcome!" 36: << endl; 37: 38: 39: string eingabe; 40: 41: 42: cin.getline(eingabe,80); 43: 44: cout << eingabe; 45: 46: 47: return 0; 48: 49: }
-
Meist gibt man effective lines of code an. Da werden Kommentare, Leerzeilen usw. nicht mitgezählt.