CleanCode

In dem Artikel Vergleich von MS Test und NUnit habe ich kurz das AAA-Pattern angerissen. Heute sehen wir uns das AAA-Pattern genauer an, warum man es nutzen sollte und welche Vorteile es bietet.

Während Software entwickelt oder geplant wird, stellen sich diverse Fragen und es werden Entscheidungen getroffen. Oft gibt es das Problem, dass nach vielen Jahren (oder durch einen Wechsel der Entwickler) die ursprüngliche Entscheidung nicht mehr nachvollziehbar oder verständlich ist.

Versionsnummern können in der Softwareentwicklung wichtig sein. Doch wann sind Versionsnummern schlecht und stören bei der Entwicklung von Software? Dieser Artikel gibt euch Tipps. Was sind Versionsnummern Versionsnummern geben einen bestimmten Stand einer Software, Bibliotheken oder Dokumenten an. Diese Nummern können im Prinzip überall angewendet werden und einen beliebigen Aufbau haben. Versionsnummern definieren einen gewissen Stand. Wenn sich zwei Versionen von X unterscheiden sollte auch die Versionsnummer unterschiedlich sein. In der Softwareentwicklung helfen die Nummern dabei festzustellen, welchen Stand ein Produkt hat.

Zu vielen Projekten gibt es Changelogs, welche die Änderungen von Version zu Version dokumentieren. Doch wie schreiben wir einen Changelog und was sollte enthalten sein? Diese Fragen wird dieser Artikel behandeln. Sinn und Zweck Wozu brauchen wir Changelogs? Bei sehr kleinen Projekten macht es vielleicht wenig Sinn, einen Changelog zu pflegen. Handelt es sich um ein größeres Projekt (eine Anwendung oder große Bibliothek) ist es schön, neue Funktionen und Änderungen schnell zu erfassen.

Ich bin über folgenden Artikel von Joel Spolsky gestoßen: Making Wrong Code Look Wrong . Der Artikel ist schon einige Jahre alt aber, wie ich finde, immernoch aktuell. Wir Entwickler lieben es, lesbaren Code zu schreiben und immer positiv zu bleiben 😉 Verschiedene Kriterien wie Wartbarkeit, Erweiterbarkeit usw. sind bekannt. Leider kommt es manchmal dazu, dass wir unsauberen Code schreiben. Vor allem, wenn es sich ein Provisorium zur einmaligen Ausführung handelt (welche erfahrungsgemäß am längsten im Einsatz sind).

Damit meine ich nicht nur die persönliche Einstellung zu bestimmten Dingen. Auch in der Softwareentwicklung kann eine positive Bezeichnung der Variablen erheblich helfen und die Wartung von Code vereinfachen. Schauen wir uns zur Veranschaulichung folgendes Beispiel an (in leicht abgewandelter Form schon mehrmals so gesehen): if (!fooBar.IsNotEmpty){ // .. code .. } Worin besteht hier genau das Problem? Der Code ist ja eindeutig. Wenn „IsNotEmpty“ nicht wahr ist, wird der Code ausgeführt.