Benutzer-Werkzeuge

Webseiten-Werkzeuge


se:programmierung

**Dies ist eine alte Version des Dokuments!**

Tipps zur (objektorientierten) Programmierung

Allgemein

  • 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)! Peter Bucher
  • Verwende keine globalen Variablen (auch keine Singletons)! Patrick Smacchia

Werkzeuge

  • 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

Namensgebung

nach {[quellen:Goodliffe2008|S. 43ff.]}

  • 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)!

Defensive Programmierung

nach {[quellen:Goodliffe2008|S. 6ff.]}

  • 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." {[quellen:Goodliffe2008|S. 17]}
  • 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

Codeoptimierungen

(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 {[quellen:Goodliffe2008|S. 214ff.]}

  • 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 {[quellen:Goodliffe2008|S. 200ff.]}

  • 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)

Designprinzipien

nach {[quellen:Bleek2008|S. 87]}

  • Don't Repeat Yourself (DRY): Funktionen werden nur einmal implementiert und nicht mehrmals (womöglich gar durch Copy-and-Paste) → Modularisierung, bessere Wartbarkeit
  • Speaking Code Principle (SCP): der Code muss auch ohne Kommentare verständlich sein → bessere Wartbarkeit, einfachere Einarbeitung anderer Entwickler
  • Separation of Concerns (SoC): jedes Modul hat genau eine Aufgabe → Modularisierung, bessere Wartbarkeit, DRY
  • Tell, don't ask (TDA): Klassen sollten nicht nach Werten gefragt, sondern aufgefordert werden, eine Funktion zu liefern (z.B. nicht MwSt-Satz abfragen, sondern auffordern, Mehrwertsteuer zu berechnen) → verhindert ausufernde Abhängigkeiten zu anderen Klassen, evtl. jedoch Konflikt zu SoC

nach http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod:

  • Single Responsibility Principle (SRP): A class should have one, and only one, reason to change.
  • Open Closed Principle (OCP): You should be able to extend a classes behavior, without modifying it.
  • Liskov Substitution Principle (LSP): Derived classes must be substitutable for their base classes.
  • Dependency Inversion Principle (DIP): Depend on abstractions, not on concretions.
  • Interface Segregation Principle (ISP): Make fine grained interfaces that are client specific.

ToDo

  • Law of Demeter
  • Test-first

Checklisten

nach http://www.codinghorror.com/blog/archives/000568.html

  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?

When to throw an exception

nach {[quellen:Seguin2008|S. 69]}

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

Continuous Improvement (als Entwickler)

Fragen, die man sich als (guter) Entwickler öfter einmal stellen sollte (nach {[quellen: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?
se/programmierung.1260280656.txt.gz · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)