[Tipps & Tricks] bad programming

Programmiersprachen, APIs, Bibliotheken, Open Source Engines, Debugging, Quellcode Fehler und alles was mit praktischer Programmierung zu tun hat.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2257
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Tipps & Tricks] bad programming

Beitrag von Zudomon »

Ich glaube, ein Großteil meiner Programmierarbeit verbringe ich damit, nicht zu programmieren und mich ab zu lenken. Ich vermute mal, dass sich einfach das Unterbewusstsein weiter damit beschäftigt... zumindest geht es, wenn ich so arbeite im Endeffekt schneller voran.

Entbehrlich finde ich zum k.... ! Ich will nicht entbehrlich sein. Wenn ich es doch bin, heißt das nur, dass ich keine besondere Arbeit leiste.
Wenn man so drüber nachdenkt, dann stimmt es auch nicht. So wie es nicht stimmt, dass es immer einen besseren gibt. In einem endlichen System gibt es immer ein Maximum und ein Minimum. Außerdem macht man sich ja entbehrlich, indem man anderen haarklein vorkaut, was man gemacht hat. Denn ohne Doku usw. könnten andere das auch nicht mal eben so nach machen.

Was den riesen Switchblock angeht, da finde ich Regions effektiver als Unterfunktionen. Denn denen muss man auch wieder allemöglichen Variablen mitgeben, außer man macht diese global verfügbar. In Delphi kann man ja auch Funktionen in Funktionen machen. Die lokal deklarierten Variablen sind dann, je nachdem an welcher Stelle diese stehen, global für die darunter liegenden Funktionen. Aber letztlich halte ich das für nicht ganz so übersichtlich. Außerdem brauchen Funktionen ja wieder mehr Rechenzeit. Bei einer Skriptsprache würde das bestimmt schon ein wenig was ausmachen. Naja, ist halt nur meine Meinung.

StoneQuest hat nun übrigens knapp über 33k Zeilen... aber ich hoffe, dass es bald weniger werden. :D
Ich muss dazu sagen, viele Daten halte ich auch im Code, die sollte man wirklich mal auslagern und das ganze ein wenig trennen. Außerdem schreibe ich sehr redundanten Code. Das sollte ich auch mal unterlassen! Z.B. habe ich eine Funktion, die den Text rendert. Allerdings nichts, was sich um den Schatten kümmert. Deswegen bedeutet das, das überall wo Text mit Schatten ist, die Funktion zweimal aufgerufen wird. Einmal mit den Schattenparametern, einmal Normal... bei 2-3 Textzeilen nichts verwerfliches, aber auf dauer keine Lösung.
Ich finde es echt interessant. So wie ich nicht weiß, ob sich das Universum nun letztlich ausdehnt oder doch zusammenzieht, so kommt mir das auch mit meinem Code vor... ich weiß nicht, ob er letztlich kleiner oder größer wird, wenn sich das Spiel weiter entwickelt.
simbad
Establishment
Beiträge: 132
Registriert: 14.12.2011, 14:30

Re: [Tipps & Tricks] bad programming

Beitrag von simbad »

Zudomon hat geschrieben:Ich glaube, ein Großteil meiner Programmierarbeit verbringe ich damit, nicht zu programmieren und mich ab zu lenken. Ich vermute mal, dass sich einfach das Unterbewusstsein weiter damit beschäftigt... zumindest geht es, wenn ich so arbeite im Endeffekt schneller voran.
Das ist bei mir auch so. Ich habe das im laufe der letzten 10-20 Jahre perfektioniert, was aber bei meinen Kunden/Auftraggebern manchmal Verwirrung hervorruft, wenn ich nach 6 Stunden nach Hause gehe und am nächsten Tag eine Lösung präsentiere die schon nahe an perfekt ist.
Das hat den Vorteil, das man sich auch mit anderen Dingen beschäftigen kann. Es hat den Nachteil, das ich nur die 6 Stunden bezahlt bekomme, obwohl mein Kopf weiter werkelt. Und manchmal kann ich auch bei der Bearbeitung eines Problems teilnehmen. Das war am Anfang ein wenig verwirrend, wenn zu drei oder vier Teilproblemen immer im Wechsel Teile einer Lösung auftauchen und wieder verschwinden. Aber man gewöhnt sich dran.
Entbehrlich finde ich zum k.... ! Ich will nicht entbehrlich sein. Wenn ich es doch bin, heißt das nur, dass ich keine besondere Arbeit leiste.
Wenn man so drüber nachdenkt, dann stimmt es auch nicht. So wie es nicht stimmt, dass es immer einen besseren gibt. In einem endlichen System gibt es immer ein Maximum und ein Minimum. Außerdem macht man sich ja entbehrlich, indem man anderen haarklein vorkaut, was man gemacht hat. Denn ohne Doku usw. könnten andere das auch nicht mal eben so nach machen.
Unentbehrlichkeit ergibt sich aus der Erfahrung die man im laufe der Jahre erwirbt. Oft kann ich bei einer Diskussion bestimmte Lösungsansätze als ungünstig erkennen einfach nur, weil ich das irgendwann schon einmal gemacht habe und dann wegen Unbrauchbarkeit verwerfen musste. Wenn sowas in einem Projekt mit fixen Terminen passiert wars das für das Projekt oder du hast Mengen an Arbeit die schnell und damit fehlerbehaftet ausgeführt werden muss, weil man eben einen Teil des Codes neu machen muss.
Das bedeutet in manchen Firmen, das die Design-/Test- Spezifikationen in jedem Fall überprüft werden müssen, dann durch ein Review gehen, der Code wird geändert und reviewed dann die Tests ausgeführt und wenn dann alles passt kann man ein Release machen.
Da kann durch 10-20 Zeilen Code ändern 1 Mann-Woche Arbeit entstehen. Das sind dann gleich mal ein paar Tausend Euronen.
Wenn man mit einem Erfahrenen Mann das verhindern kann, dann macht man das auch. Das ist eben eine andere Art von Unentbehrlichkeit.
Was den riesen Switchblock angeht, da finde ich Regions effektiver als Unterfunktionen. Denn denen muss man auch wieder allemöglichen Variablen mitgeben, außer man macht diese global verfügbar. In Delphi kann man ja auch Funktionen in Funktionen machen. Die lokal deklarierten Variablen sind dann, je nachdem an welcher Stelle diese stehen, global für die darunter liegenden Funktionen. Aber letztlich halte ich das für nicht ganz so übersichtlich. Außerdem brauchen Funktionen ja wieder mehr Rechenzeit. Bei einer Skriptsprache würde das bestimmt schon ein wenig was ausmachen. Naja, ist halt nur meine Meinung.
In C/C++ kann man Funktionen als inline deklarieren. Dann hast du keinen Funktionsaufruf mehr. Man kann die benötigten Parameter in eine Struktur packen und dann einen Pointer auf die Struktur übergeben, das geht auch recht schnell.
StoneQuest hat nun übrigens knapp über 33k Zeilen... aber ich hoffe, dass es bald weniger werden. :D
Das ist schon eine nette Größe. Ohne Tool-Support dürfte es somit eine Komplexität aufweisen, die kaum so ohne weiteres im Kopf zu bewältigen ist.
Benutzeravatar
BeRsErKeR
Establishment
Beiträge: 689
Registriert: 27.04.2002, 22:01

Re: [Tipps & Tricks] bad programming

Beitrag von BeRsErKeR »

Zudomon hat geschrieben:Was den riesen Switchblock angeht, da finde ich Regions effektiver als Unterfunktionen. Denn denen muss man auch wieder allemöglichen Variablen mitgeben, außer man macht diese global verfügbar. In Delphi kann man ja auch Funktionen in Funktionen machen. Die lokal deklarierten Variablen sind dann, je nachdem an welcher Stelle diese stehen, global für die darunter liegenden Funktionen. Aber letztlich halte ich das für nicht ganz so übersichtlich. Außerdem brauchen Funktionen ja wieder mehr Rechenzeit. Bei einer Skriptsprache würde das bestimmt schon ein wenig was ausmachen. Naja, ist halt nur meine Meinung.
Nun ja ich hatte für meinen letzten Script-Interpreter auch einen riesigen switch-Block verwendet, weil ich sonst für jede Funktion die Parameter hätte preparieren müssen. Letztlich wurde in jedem case-Block sogar eine Funktion aufgerufen, aber da jede Funktion andere Parameter in anderen Formen benötigte, wäre das mit Funktionspointern recht häßlich geworden. Die Parameter mussten teilweise durch Wildcard-Replacement-Routinen laufen oder nach Variablennamen durchsucht werden. Aber halt nicht immer.

Ich hab dafür allerdings von meinem Kollegen eins auf den Deckel bekommen, allerdings hatte ich auch ziemlichen Zeitdruck und das Programm tat was es sollte. Wartbar war es prinzipiell auch noch, da der Befehlssatz recht klein gehalten war.

Manchmal ist es wirklich schwierig sowas zu vermeiden, aber man sollte halt versuchen es zu vermeiden, wenn es geht. 2,8k Zeilen in einer Funktion klingt aber z.B. verdammt nach Redundanz. Regions sind ja nur Anzeigeoptionen und die hat man in Standardeditoren halt nicht zwingend (z.B. vim). Klar wenn du dich auf eine IDE einschießt mag das gehen, aber wie schon angemerkt gibt es inline-Funktionen und selbst normale Funktionscalls sollten nicht unbedingt etwas ausmachen. Programmcode mit einem riesigen switch-Block würde ich eh nicht in zeitkritischen Schleifen etc durchackern.

Letztlich ist aber das wichtigste das es funktioniert und du damit klar kommst.
Ohne Input kein Output.
odenter
Establishment
Beiträge: 207
Registriert: 26.02.2009, 11:58

Re: [Tipps & Tricks] bad programming

Beitrag von odenter »

BeRsErKeR hat geschrieben:
kimmi hat geschrieben:Dazu gibt es nicht selten so etwas wie Wissensmonopole, die von den Entwicklern gehütet werden wie der heilige Grahl. Ein Freelancer hat mir dazu mal eine witzige weil wahre Begebenheit geschildert: Bekannte bauen Systeme gern verwirrend, damit sie über Jahre hinweg noch als Berater tätig sein können -> Jobgarant. Code-Reviews helfen da nur bedingt, wenn der Zeitplan mal wieder auf Kante genäht wurde und keine Zeit für wirkliche Änderungen bleibt. Oder man hat zu einem speziellen Thema wie Mathlab nur einen Spezialisten in der Firma, so dass keiner wirklich Code-Reviews auf Augenhöhe durchführen kann.
[Offtopic]Das ist ein großes Problem, nicht nur in der Softwareentwicklung. Es gibt eine Menge Leute, die so tun als wären sie unentbehrlich oder verrichten Wunder und dabei sind sie einfach nur faul. Mir ist das bei meinem neuen Arbeitgeber aufgefallen. Einer der größten Konzerne Deutschlands. Da sitzen hunderte Leute und arbeiten an etwas, was man mit ein wenig Organisation mit 2 Arbeitern in der gleichen Zeit schafft. Die kriegen ein Schweinegeld, arbeiten 4 Stunden am Tag und sind nur am Jammern. Ich hab als Neuling da in der Hälfte der Zeit das 7-fache geschafft ohne jegliche Vorkenntnisse. Und das ist nun wahrlich keine Raketenwissenschaft. Da fragt man sich echt was hier im Lande los ist. Ich kannte das vorher nicht so. Da war für mich ein Arbeitstag von 8 bis 20 Uhr normal und wenn ich jetzt um 8 auf Arbeit bin, bin ich allein und nach 17 Uhr auch wieder. Was ich allerdings eigentlich sagen wollte ist, dass die Leute halt alle so tun als wäre die Arbeit extrem schwierig und anstrengend und kriegen daher viel Kohle. Prinzipiell sehr clever aber für sowas bin ich einfach zu ehrlich.[/Offtopic]

Zum Thema Riesen-Switch-Block: Damit hab ich auch schon oft was sehr längliches fabriziert, z.B. bei Scriptinterpretern, allerdings kann man da in der Regel auch maps mit Funktionspointern nutzen oder wenigstens den Inhalt der case-Blöcke in Funktionen auslagern. Regions kann man ja eventuell nutzen, aber nicht jeder arbeitet mit IDEs und bei großen switch-Blöcken geht auch damit irgendwann die Übersicht flöten. 2,8k Zeilen Code würde ich nicht mal in einer Datei unterbringen. Die halte ich nach Möglichkeit auch recht klein genau wie Klassen. Auch mit dem Gedanken eines Soloprojekts im Hinterkopf seh ich das kritisch. Ich hatte auch schon Monsterprojekte und habe auch noch 2 am laufen. Wenn man da mal 1-2 Monate nicht mehr reinguckt hat man ganz schön zu schlucken wenn das schlecht strukturiert ist oder einen der Code erschlägt. Daran bin ich schon oft gescheitert bzw. habe dadurch temporär oder gänzlich die Lust verloren am Projekt weiterzuarbeiten.
Strategy- und Factory- pattern helfen bei solchen Konstrukten, lohnt allerdings nicht für ein switch Statement mit 2 Einträgen/Werten.
Kann Euch aber nur zustimmen, habe vor ca. einem Jahr den Arbeitgeber gewechselt und pflege nun eine Software die vor ca. 13 Jahren entworfen wurde. Der ursprüngliche Entwurf wäre immernoch wartbar, wenn man sich die ganzen Jahren auch wirklich an den Entwurf gehalten hätte und nicht irgendwann mit CTRL+C und CTRL+V angefangen hätte Logik in Views zu packen und dort auch noch zu verfielfältigen...
Hat auch einfach was mit Erfahrungen zu tun ob ich ein "switch/case", "if/else/else if" Konstrukt durch ein Designpattern ersetze oder nicht. Zum Beispiel weil ich abschätzen kann ob hier Erweiterungen kommen werden oder nicht.

Aufgrund von eigenen Erfahrungswerten würde ich sagen das Hauptproblem sind die Entwickler selber.
Ich erlebe es immer wieder das Softwareentwickler Optionen auf den Tisch werfen die eigentlich keine sind. Und wenn darüber Diskutiert wird ob Lösung A (10h) oder Lösung B (50h) gewählt wird, dann wählt der Chef Lösung A. Also bietet man Ihm diese gar nicht erst an!

Ganz aktuell habe ich ein paar Kollegen die haben einfach keinen Bock mehr (scheiss Arbeitgeber blah usw.) die schreiben richtig lustigen Code (ironisch). Kopplung ist dermaßen hoch, das man hier wirklich nur neue Views erzeugen kann ohne irgendwo den Stecker rauszuziehen.

Selbst bei neuen Projekten brauchten ein Kollege und ich zusammen 7 Tage um eine Kleinigkeit zu ändern, das kann nur falsch sein. Das geht aber auch nur weil ich in einer Firma beschäftigt bin die Ihr Geld nicht mit der Software verdient.
War mal bei einem Softwarehersteller, da lief zwar auch nicht alles perfekt, aber die Software war viel besser wartbar.

Gute Software ist Software die sich schnell/einfach/leicht an neue Anforderungen anpassen lässt.
Antworten