• Programmiere so, dass dein Code auch die nächsten Jahre überstehen könnte (und nicht so, dass du ihn nach 2 Tagen selbst nicht mehr verstehst)
• Verwende als Parameter von Methoden immer das kleinstmögliche Interface (z.B. IEnumerable anstatt IList)! \cite{Bucher2009a}
• Verwende keine globalen Variablen (auch keine Singletons)! \cite{Smacchia2009a}
• Konstruktoren sollten keine "echte" Arbeit verrichten. \cite{Hevery2008}
• "The most reliable way to minimize the creation of regression bugs is to avoid modifying the existing code." \cite{Miller2007a}

• Validierung sollte auf Ebene des Domänendatenmodells durchgeführt werden und nicht als Teil des Domänenmodells. Beispiel: Prüfung einer gültigen PLZ nicht in Klasse Adresse, sondern in eigener Klasse PLZ. \cite[S.107]{Westphal2012}
• Wenn man richtig konsequent nach SRP arbeiten will, benutzt man semantisch genaue Datentypen für Eigenschaften, z.B. Fullname oder PhoneNumber bei Personen. Dadurch baut man sich eine Hierarchie von Datentypen auf: große Datentypen setzen sich aus kleineren Datentypen zusammen. \cite[S.108]{Westphal2012}
• Bei 1:n- oder m:n-Beziehungen liegt häufig auch eine komplexere Semantik vor. Diese sollte in spezielle Datentypen ausgelagert werden. \cite[S.109]{Westphal2012}

• kenne deine Werkzeuge (z.B. die IDE) in- und auswendig → höhere Produktivität
• benutze das richtige Werkzeug für deine Aufgaben und schaue dich ständig nach besseren Werkzeugen um
  • lerne mehrere Programmiersprachen und wähle die passende für deine Aufgaben

nach \cite[S. 43ff.]{Goodliffe2006}

• Klarheit ist wichtiger als Kürze.
• Funktionen sollten aus einer externen Sichtweise heraus benannt werden und die logische Operation beschreiben, nicht die Implementierung.
• Vermeide Redundanzen in Namen (insb. class, data, object, type)!

nach \cite[S. 6ff.]{Goodliffe2006}

• Defensive Programmierung bedeutet vorsichtiges, überwachtes Programmieren. Jede Komponente wird so entwickelt, dass sie sich selbst so gut wie möglich schützt. Unsichere Annahmen werden eliminiert.
• Defensive Programmierung ist nicht Fehlerbehandlung (sollte immer Standard sein!), Testen (stets Teil des Prozesses) und Debuggen (Finden von Fehlern, anstatt sie zu vermeiden)!
• Programmiere mit Bedacht und vertraue niemandem (auch nicht dir selbst)!
• "Readability is the best single criterion of program quality." \cite[S. 17]{Goodliffe2006}
• Benutze ein gutes Logging-Tool!
• Beispiele
  • Assert der Vor- und Nachbedingungen und der Invarianten
  • entsprechende Datentypen für nicht-negative Zahlen verwenden (z.B. unsigned int) um aufwändige Prüfungen des Wertebereichs zu vermeiden
  • Rückgabewerte von Funktionen immer prüfen (wofür sind sie sonst da?)
  • default-Zweig von switch-Anweisungen explizit implementieren/dokumentieren
  • Wertebereiche von Variablen im Hinterkopf behalten bei der Wahl eines Datentyps

In \cite[45:00]{RubyRogues47} sprechen sich die Teilnehmer dafür aus, nicht in allen internen Komponenten erneut Datengültigkeitsprüfungen durchzuführen (also auf defensive Programmierung zu verzichten), sondern lediglich in einer "Guard"-Klasse, deren einzige Aufgabe (→ Single Responsibility Principle) es ist, Eingaben zu validieren. Alles, was in das System reinkommt, muss diese zentrale Prüfung bestehen, sodass im Inneren des Systems von gültigen Daten ausgegangen werden kann.

(siehe Skript Datenstrukturen und Algorithmen)

• Constant Propagation: wo es geht Konstanten anstatt von Variablen verwenden
• Common Subexpression Elimination: einmalige Berechnung gleicher Ausdrücke
• Operator Strength Reducing: Bitshifts beim Rechnen mit Zweierpotenzen verwenden
• Copy Propagation: keine überflüssigen oder doppelten Berechnungen
• Loop Strength Reduction: Vermeiden überflüssiger Schleifendurchläufe durch Verwenden des passenden Inkrements (z.B. i += 10 anstatt i++)
• Invariant Code Motion: Entfernen invarianter Ausdrücke (Berechnungen mit immer gleichem Ergebnis in der Schleife oder dem Schleifenkopf) aus Schleifen
• Loop Jamming: Zusammenfassen mehrerer Schleifen zu einer
• Vermeidung unnötiger Indexzugriffe auf Arrays (da interne Multiplikationen zur Ermittlung des Speicherplatzes nötig)
• keine überflüssigen Funktionsaufrufe (Operatoren sind meist schneller)

nach \cite[S. 214ff.]{Goodliffe2006}

• Loop Unrolling: Schleifen mit kurzem Rumpf sind evtl. teurer als einfach mehrfache gleiche Aufrufe hintereinander
• Code Inlining: teure Funktionsaufrufe durch inline ersetzen
• Prüfung zur Compile-Zeit: so viele Prüfungen wie möglich zur Compile-Zeit machen, anstatt zur Laufzeit (z.B. negative Werte ausschließen durch unsigned int)
• unnötigen Code eliminieren
• Short-circuit evaluation: bei booleschen Vergleichen die Werte, die am wahrscheinlichsten falsch sind, zuerst abfragen (dadurch müssen z.B. bei && nicht beide Vergleiche gemacht werden)

nach \cite[S. 200ff.]{Goodliffe2006}

• 2 Gesetze der Optimierung
  1. Tu es nicht!
  2. nur für Experten: Tu es noch nicht!
• Bedenke die Optimierung deines Codes von Beginn an und vermeide ungetestete Hacks am Ende!
• Korrekter Code ist wichtiger als schneller Code!
• Probleme mit "optimiertem" Code
  • Code ist komplexer und schwerer zu verstehen und damit zu warten/erweitern
  • die Optimierung ist evtl. plattformabhängig
  • Optimierung ist zusätzlicher Aufwand (→ sollte lieber in die Entwicklung gesteckt werden)

nach \cite{Atwood2006}

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

nach \cite{Roden2010b}

1. It does satisfy all its functional and non-functional requirements.
2. It does not contain any known errors.
3. It has been commented and documented.
4. It has been either pair-programmed or reviewed.
5. It has been developed test-driven using 4-Step TDD.
6. It does not need to be refactored or rearranged.
7. It has been written according to well-known best practices.
8. It does conform to accepted coding standards.
9. It does pass static code analysis without any errors or warnings.
10. It has been integrated and does not break the integration build.
11. It has been checked in into source control.

nach \cite[S. 69]{Seguin2008}

Generally speaking, I find it easy to decide what should and shouldn't throw an exception. I generally ask myself questions like:

• Is this exceptional,
• Is this expected,
  * Can I continue doing something meaningful at this point and
• Is this something I should be made aware of so I can fix it, or at least give it a second look

Fragen, die man sich als (guter) Entwickler öfter einmal stellen sollte (nach \cite[]{KanatAlexander2009}):

• Do you know as much as possible about every single word and symbol on every page of code you’re writing?
• Did you read and completely understand the documentation of every single function you’re using?
• Do you have an excellent grasp of the fundamental principles of software development–such a good grasp that you could explain them flawlessly to novice programmers at your organization?
• Do you understand how each component of the computer functions, and how they all work together?
• Do you understand the history of computers, and where they’re going in the future, so that you can understand how your code will function on the computers that will be built in the future?
• Do you know the history of programming languages, so that you can understand how the language you’re using evolved and why it works like it does?
• Do you understand other programming languages, other methods of programming, and other types of computers than the one you’re using, so that you know what the actual best tool for each job is?

nach \cite{Nygard2009}

• Stabilität der Software
  • "consistent long-term availability of features the users care about"
  • jeder Integrationspunkt zu anderen Anwendungen ist eine potentielle Bedrohung der Stabilität
• Kapazität
  • bestmögliche Ausnutzung der gegebenen Ressourcen
  • Lasttests bei der Entwicklung sind enorm wichtig, damit die Software nicht am ersten Tag in Produktion in die Knie geht
• Operations
  • die Administratoren müssen sehen können, was in der Software vor sich geht, dafür sind fast ausschließlich Logfiles geeignet und daher sehr wichtig
  • die Logfiles sollten einfach automatisch auszulesen sein (z.B. Fehlercodes verwenden)