In der Computerprogrammierung ist Codegeruch jedes Symptom im Quellcode eines Programms, das vielleicht ein tieferes Problem anzeigt.

Häufig kann das tiefere durch einen Codegeruch angedeutete Problem aufgedeckt werden, wenn der Code einem kurzen Feed-Back-Zyklus unterworfen wird, wo es refactored in kleinen, kontrollierten Schritten ist, und das resultierende Design untersucht wird, um zu sehen, ob es weitere Codegerüche gibt, die das Bedürfnis nach mehr Wiederfactoring anzeigen. Aus dem Gesichtswinkel von einem wegen des leistenden Wiederfactorings angeklagten Programmierer sind Codegerüche Heuristik, um wenn zum Wiederfaktor, und was spezifische Wiederfactoring-Techniken anzuzeigen, zu verwenden. So ist ein Codegeruch ein Fahrer für das Wiederfactoring.

Der Begriff scheint, von Kent Beck auf WardsWiki gegen Ende der 1990er Jahre ins Leben gerufen worden zu sein. Der Gebrauch des Begriffes hat zugenommen, nachdem es im Wiederfactoring gezeigt wurde: Besserung des Designs des Vorhandenen Codes.

Codegeruch ist auch ein von flinken Programmierern gebrauchter Begriff.

Bestimmung, was ist und nicht ein Codegeruch ist, ist häufig ein subjektives Urteil, und wird sich häufig durch die Sprache, den Entwickler und die Entwicklungsmethodik ändern. Es gibt Werkzeuge, wie Checkstyle, PMD und FindBugs für Java, um für bestimmte Arten von Codegerüchen automatisch zu überprüfen.

Allgemeine Codegerüche

• Kopierter Code: Identischer oder sehr ähnlicher Code besteht in mehr als einer Position.
• Lange Methode: Eine Methode, Funktion oder Verfahren, das zu groß gewachsen ist.
• Große Klasse: Eine Klasse, die zu groß gewachsen ist. Sieh Gott protestieren.
• Zu viele Rahmen: Eine lange Liste von Rahmen in einem Verfahren oder Funktion macht Lesbarkeit und codiert schlechtere Qualität.
• Eigenschaft-Neid: Eine Klasse, die Methoden einer anderen Klasse übermäßig verwendet.
• Unpassende Intimität: Eine Klasse, die Abhängigkeiten von Durchführungsdetails einer anderen Klasse hat.
• Verweigertes Vermächtnis: Eine Klasse, die eine Methode einer Grundklasse auf solche Art und Weise überreitet, dass der Vertrag der Grundklasse durch die abgeleitete Klasse nicht beachtet wird. Sieh Ersatz-Grundsatz von Liskov.
• Faule Klasse / Schmarotzer: Eine Klasse, die zu wenig tut.
• Erfundene Kompliziertheit: Der erzwungene Gebrauch allzu komplizierter Designmuster, wo einfacheres Design genügen würde.
• Übermäßig lange Bezeichner: Insbesondere der Gebrauch, Vereinbarung zu nennen, um Begriffserklärung zur Verfügung zu stellen, die in der Softwarearchitektur implizit sein sollte.
• Übermäßig kurze Bezeichner: Der Name einer Variable sollte seine Funktion widerspiegeln, wenn es nicht offensichtlich ist.
• Übermäßiger Gebrauch von Druckfehlern: Diese sollten als genannt Konstanten codiert werden, um Lesbarkeit zu verbessern und zu vermeiden, Fehler zu programmieren. Zusätzlich können Druckfehler und sollten in Quellendateien/Schriften wo möglich offen gelegt werden, um Lokalisierung der Software zu erleichtern, wenn es beabsichtigt ist, um in verschiedenen Gebieten aufmarschiert zu werden.
• Ubercallback: Eine Rückrufaktion, die versucht, alles zu tun

Siehe auch

Antimuster

• Kategorie

Kategorie

• Liste von Werkzeugen für die statische Codeanalyse

Links

• CodeSmell an c2.com
• Die Taxonomie des Codes riecht
• Übersicht von vielen Codegerüchen