4. Wieso ist das Programm ein Alptraum?

Wieso ist das Programm ein Alptraum?

  • M

    knivil schrieb:

    Ich habe mal gehoert, dass Zeilenanzahl direkt proportional mit der Anzahl der Bugs korreliert.

    Absolut gesehen ja.

    Ich habe es hier auf das Beispiel von ihm bezogen, ich glaube ich habe eine Zeile mehr, weil ich für goto + Label eine Zeile mehr brauche als seine Lösung.

    0
  • K

    Mein Punkt war bloss, dass in gewissen Bereichen goto durchaus Verwendung findet.

    Das zweifelt niemand an. Dennoch ist es in den meisten Faellen eine schlechte Idee.

    0
  • M

    knivil schrieb:

    Ich finde nicht, dass der Linuxkernel ein gutes Beispiel ist.

    Das Originalbeispiel war Anprogrammierung von Grafik... also typische Init-Exit-Sachen von Grafikstruktur hier, Port da, etc.

    Die Masse der Leute hier wird ja hoffentlich die Anwendungen auch nicht in C schreiben...

    0
  • K

    Ich halte das ganze fuer einen Trollpost.

    0
  • ?

    Marc++us schrieb:

    Die Masse der Leute hier wird ja hoffentlich die Anwendungen auch nicht in C schreiben...

    ach, die masse ...
    richtige programmierer schreiben es in assembler 👍

    0
  • B

    Ich habe mal gehoert, dass Zeilenanzahl direkt proportional mit der Anzahl der Bugs korreliert. Das soll unabhaengig von Sprache, Programmierstil etc. Also etwa 100 Zeilen ein Bug.

    Das ist wohl der Grund warum einige Programmierer viel Code in eine Zeile packen...

    if (a==0) {b=5;c=6;d=-1}
switch (a) {
  case 0: b=5;c=4;break;
}

    :xmas1:

    Alle unnötigen Leerzeichen entfernen und soviel wie möglich in eine Zeile packen s.d. man möglichst wenig LOC hat s.d. man möglichst wenig Fehler hat.

    0
  • Mod

    Theoretisch braucht man nirgendwo Zeilenumbrüche. Der Zeilenumbruch hat keine besondere Bedeutung in C (außer dass er auch ein Whitespace ist).

    0
  • C

    Das werde ich ab jetzt ausnutzen, offenbar hilft es ja dabei Bugs zu vermeiden. 👍

    0
  • ?

    Thx an alle fuer den Tipp mit dem goto.
    Das Kartenspiel ('Watten') ist jetzt 'so gut wie' fertig, einzig beim
    'Verzoegern' der Animation scheint mir, dass ich nicht die optimale
    Loesung hinkriege, weil ja der CPU Gegner so extrem schnell seine Spielzuege
    berechnet, hab ich an mehreren Stellen die Ausfuehrung des Programms
    mit 'Sleep()' verzoegert, damit der User mitkriegt, was vor sich geht.

    Hier so eine Beispielfunktion:

    /* Spezielle, verzoegernde Anzeige der durch HUM_PLR 'als erster' ausgespielten Karte */
static void drawHumPlr1st(void){
	HBRUSH oldBrush;
	HDC hdc;
	RECT *oldLoc, *centLoc, *bltSrc;
	/* 1. -> Mit Hintergrund-Farbe uebermalen: Bereich der ausgespielten Karte im Talon
		 2. -> ausgespielte Karte kurz 'solo' im Ausspiel-Bereich darstellen */
	hdc = GetDC(GodObject->hAppWnd);
	if(hdc){
		oldLoc = &GodObject->Player[HUM_PLR].TalonBlitDest[Move.AusCardIdx];
		centLoc = &GodObject->Player[HUM_PLR].playedBlit;
		bltSrc = GodObject->BlitSrc[GodObject->Player[HUM_PLR].Cards[Move.AusCardIdx]];

		oldBrush = SelectObject(hdc, GodObject->BackColor);
		PatBlt(hdc, oldLoc->left, oldLoc->top, STD_CARD_WIDTH, STD_CARD_HEIGHT, PATCOPY); /* ok 1. */
		BitBlt(hdc, centLoc->left, centLoc->top, STD_CARD_WIDTH, STD_CARD_HEIGHT,
			GodObject->hMemDC, bltSrc->left, bltSrc->top, SRCCOPY); /* ok 2. */

		Sleep(DELAY_SHORT); /* <-- ?? UM GENAU DIESE STELLE GEHT'S */

		SelectObject(hdc, oldBrush);
		ReleaseDC(GodObject->hAppWnd, hdc);
	}
}

    Hier schlaeft das Programm z.B. fuer 500 ms (als #define so festgelegt),
    damit der Spieler das 'Nacheinander' des Ausspielens der Karten ueberhaupt
    mitkriegt.
    Aber auch eine halbe Sekunde vergeht ja ziemlich flott.
    Andererseits moechte man es dem User ersparen, dass er nach jeder Veraenderung
    in der GUI noch zusaetzlich wo draufklicken muss, damit das Spiel fortgesetzt
    wird.
    Habe wo gelesen, dass man eine GUI-Anwendung normalerweise nicht gar zu
    lange auf Sleep() schicken soll, weil sonst die Message Queue überquellen
    könnte. Die Message-Queue räume ich zwar in regelmäßigen Abständen mit
    PeekMessage() auf (das Programm schaltet ja auch ständig zwischen Warte-Modus
    und Aktiv-Modus hin- und her).
    Was wäre denn da eine gescheitere Lösung, um die Animation zu verzögern.
    Das Programm läuft zwar auch mit dem Sleep() halbwegs zufriedenstellend und
    so, wie geplant, aber vielleicht kennt ja wer von Euch eine 'elegantere'
    Lösung für solche Animations-Verzögerungs-Aufgaben, wäre echt toll
    wenn mir da nochmal jemand einen Tipp geben könnte !

    Und nochmal thx für die Tipps wegen dem goto, hab jetzt alle goto's eliminiert!
    Das ganze Programm ist halt ziemlich TopDown reingehämmert worden, aber
    die Hauptsache ist ja, dass es halbwegs funktioniert.

    mfg

    0
  • ?

    Hallo,

    das muss ein Trollthread sein, erkennbar am GodObject.

    0
Anmelden zum Antworten