Benutzer-Werkzeuge
se:programmierung
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
|
se:programmierung [2009-02-14 22:13] stefan |
se:programmierung [2014-04-05 11:42] |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| - | ====== 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) | ||
| - | |||
| - | ===== 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 [[algorithmendatenstrukturen#codeoptimierungen|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 | ||
| - | - Tu es nicht! | ||
| - | - 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]]** | ||
| - | - Do you use source control? | ||
| - | - Can you make a build in one step? | ||
| - | - Do you make daily builds? | ||
| - | - Do you have a bug database? | ||
| - | - Do you fix bugs before writing new code? | ||
| - | - Do you have an up-to-date schedule? | ||
| - | - Do you have a spec? | ||
| - | - Do programmers have quiet working conditions? | ||
| - | - Do you use the best tools money can buy? | ||
| - | - Do you have testers? | ||
| - | - Do new candidates write code during their interview? | ||
| - | - Do you do hallway usability testing? | ||
se/programmierung.txt · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)
Seiten-Werkzeuge
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International
