Code Optimierung
31. Januar 2009 Roland
- Programmierung
- Variablenzuweisungen und Berechnungen
- Alter berechnen nur mit JavaScript
- Alter berechnen mit und ohne Javascript
- Code Optimierung
- Client Server Applikationsarchitektur
- Eigenschaften eines Webbrowsers
- Stylesheets
- Interaktive Webclients
- Mit HTML, oder SVG, interaktive Ein- Ausgaben erstellen
- Mit JavaScript aus einem Dokument Daten lesen
- Der Webserver
- Webserver-seitige Programmierung
- Datenbankanbindung
- Architekturprinzip Separation of Concerns
- Beschreibung von Anwendungsfällen
- Mit JavaScript einen wiederkehrenden Event erzeugen
- Kommunikationswege bei Einsatz von Java auf dem Webclient
- Einbinden der JavaScript Timer Klasse in eine Webseite
- AJAX Kommunikation ohne Fassaden Pattern
- JavaScript Klassen mit Object-Literal Syntax erstellen
- Knackpunkte bei der Klasse AsyncCommunication
- Speicherverbrauch in AJAX Applikationen
- Auch bei JavaScript immer die Variablen sauber deklarieren
- Eventhandler im JavaScript mit dem HTML Dokument verknüpfen
- Objekte in JavaScript mit JSON deklarieren
Der erste Versuch eine Auswahlbox für Jahre zu erstellen hat zumindest geklappt. Aber ist der Code überhaupt optimal?
Hier gibt es diverse Punkte, über die man diskutieren kann.
Geschwindigkeit vs Lesbarkeit
Zum Einen könnte man sagen, dass der dynamisch generierte Code für den Menschen nicht mehr lesbar sein muss und daher die Option-Felder ohne Leerzeichen ausgegeben werden sollten.
Dann gibt es das andere Lager welches behauptet, man sollte zuerst einmal jeden Quellcode, auch den dynamisch erzeugten, lesen können. Zu diesem Lager gehöre ich (meistens). Wenn ich normalerweise an eine Programmierung herangehe erstelle ich zuerst einen lesbaren, funktionsfähigen Code. Falls ich später feststelle, dass der Code nicht schnell genug ist, versuche ich ihn zu beschleunigen. Ein alter Spruch sagt: First make it run, then make it fast.
Somit ist dass korrekte Einrücken des dynamisch generierten Codes für mich die bessere Alternative. Ein Fehler läßt sich so wesentlich einfacher finden.
Optimierungsmöglichkeiten
Mir fällt hierzu sofort die Generierung der Einrückung ein. Im Moment steht da drin:
// Unsere HTML Datei soll sauber eingerückt
// dargestellt werden.
// Mit diesem Füllelement erreichen wir eine
// saubere Darstellung.
$spaceFiller = "";
if($year > $startYear){
$spaceFiller = " ";
}
// Gebe das aktive Jahr als HTML-Option Element aus.
echo $spaceFiller
Wieso mach ich dass so kompliziert?
Weil ein weiterer Spruch sagt: “Die dümmsten Programmierer haben die dicksten Programme.”
Besser wäre es, die erste Einrückung schon im HTML Code zu machen, wie ich es übrigens getan habe:
<select name="year">
<?
Und dann die if-Abfrage entfernen und erst nach dem ersten Durchlauf die Variable $spaceFiller befüllen.
Der PHP Code sieht dann folgendermaßen aus:
// Auslesen des aktuellen Jahres.
$currentYear = (int)date("Y");
// Es werden nur 100 Jahre berücksichtigt.
// Sorry für alle, die älter als 100 sind 
$startYear = $currentYear-100;
// Unsere HTML Datei soll sauber eingerückt
// dargestellt werden.
// Mit diesem Füllelement erreichen wir eine
// saubere Darstellung.
$spaceFiller = "";
// Laufe durch alle möglichen Jahre.
for( $year = $startYear
; $year <= $currentYear
; $year++){
// Falls das aktive Jahr 25 Jahre vor dem aktuellen Jahr liegt,
// möchten wir dieses Jahr als selektiert markieren.
$selected = "";
if($year == $currentYear-25){
$selected="selected ";
}
// Gebe das aktive Jahr als HTML-Option Element aus.
echo $spaceFiller
.'<option '
.$selected
.'value="'
.$year
.'">'
.$year
.'</option>;'
."\n";
$spaceFiller = " ";
}
Hin- und wieder ist es sinnvoll seinen eigenen Code zu durchstöbern und nicht optimal gelöste Konstrukte zu beseitigen. Natürlich soll man dafür nicht ewig Zeit aufwenden. Es muss immer im Rahmen bleiben. Wenn ich Entwicklungsprojekte leite sorge ich dafür, dass die Entwickler einmal die Woche den Code aufräumen gehen. Dieses Vorgehen nennt man Refacturing. Alter defekter Code, sogenannter LavaCode, kann hiermit reduziert werden.
Aufgabe an die Kursteilnehmer
Fragt euch selbt einmal ob ihr euren Code zwischendurch aufräumt. Falls ihr dass nicht tut, was fehlt euch um hin- und wieder Code Refacturing zu machen? Ist es keine Lust oder ist es keine Zeit?
Der Beitrag wurde
am Samstag, den 31. Januar 2009 um 00:01 Uhr veröffentlicht
und wurde unter Programmieren abgelegt.
Kurzlink: http://www.baldenhofer.eu/blog/?p=64
Dir gefiel der Artikel? Dann abonniere doch den RSS Feed
Du kannst die Kommentare zu diesem Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.
Ich glaube meistens ist es wohl eine Mischung aus Beidem. Doch wenn man sich dann nach längerer Zeit mit seinem “alten” Code wieder beschäftigen muss wäre man dankbar, man hätte schon während dem Erstellen auf Sauberkeit, Übersichtlichkeit und eine gute Dokumentation Wert gelegt.
Natürlich kann es vorkommen, dass man nach längerer Zeit den Wald vor lauter Bäumen nicht mehr sieht, und einiges überhaupt nicht mehr auffällt. Dann wäre eine kleine Pause angebracht um sich den Code und die Dokumentation nocheinmal anzuschauen. Meistens findet man dann noch einiges zum Verbessern.
Weiterhin kostet so ein wöchentliches Review unterm Strich weniger Zeit, als das wieder Einarbeiten in nicht optimierten Code.
Bei Projekten, die veröffentlicht werden oder online stehen, achte ich in der Regel immer auf strukturierten Code. Einrückungen Tabs mache ich direkt im Code beinahe automatisch. Und wenn man HTML Seiten generiert, dann lohnt es sich oftmals so wie oben gesehen, extra Funktionen einzurichten, damit der Code gut lesbar wird.
Ich hatte zum Beispiel einmal eine Bildergalerie zu programmieren, bei der CSS Eigenschaften per PHP ausgefüllt wurden. Merkwürdigerweise besaßen die Variablen, die ich eingefügt habe aber Zeilenumbrüche am Ende, sodass sie im HTML nicht sauber angezeigt wurden. Das hat verhindert, dass ich offensichtliche Fehler schnell gefunden habe. Schließlich habe ich in den Strings, die ich eingefügt habe, alle Sonderzeichen (Absatz, Line feed…) entfernt, sodass der HTML Code wieder lesbar wurde.
Kommentieren tue ich meist nicht direkt während dem Programmieren. Da bin ich eher in einer Eile und will vorwärts kommen. Dafür finde ich dann eher Zeit, wenn es mal hängt oder ich ein denkfaul bin. Dann starte ich mit Einrückungen und Kommentaren zu malen, sodass der Code verständlich wird.
Ein bisschen unsicher bin ich mir immer, bei Variablen. Manchmal ist es ziemlich unnötig, genauer darauf einzugehen, aber manche Variablen sind auch so wichtig oder komplex, dass man sie schon beschreiben sollte. Zurzeit beschreibe ich komplexere Variablen und ihre Eigenschaften, zum Beispiel arrays die irgendwo übergeben werden, aber normale count oder iteration Variablen ignoriere ich in der Regel, weil ich das kontraproduktiv finde.
Ich hoffe mal dass du dir angewöhnst nicht nur bei Projekten die veröffentlicht werden sauber einzurücken. Wenn du es mal gewohnt bist einzurücken machst du das eigentlich immer.
Variablen kommentiere ich immer wenn es sich um Membervariablen handelt. Einen Schleifenzähler oder eine Variable, die in einer Funktion einen Zwischenwert aufnimmt braucht man meiner Meinung nach auch nicht kommentieren. Die Variablen sollten ja sprechende Namen haben und somit sollte klar sein warum die da sind.