Wie man Sonderfälle und Heuristiken verwaltet

Question

Ich habe oft Code basierend auf einem bestimmten gut definierten Algorithmus. Dies wird gut kommentiert und scheint richtig zu sein. Für die meisten Datensätze funktioniert der Algorithmus hervorragend.

Aber dann werden die Randfälle, die Sonderfälle, die Heuristiken hinzugefügt, um bestimmte Probleme mit bestimmten Datensätzen zu lösen. Wenn die Anzahl der Sonderfälle wächst, werden die Kommentare immer dunstiger. Ich befürchte, zurück zu gehen und diesen Code in ungefähr einem Jahr zu betrachten und mich daran zu erinnern, warum jeder spezielle Fall oder jede Heuristik hinzugefügt wurde.

Ich wünschte manchmal, es gäbe eine Möglichkeit, Grafiken in den Quellcode einzubetten oder zu verknüpfen. Daher könnte ich effektiv sagen. Code wurde hinzugefügt ".

Was sind einige Best-Practices, um mit solchen Situationen umzugehen?

Besondere Fälle scheinen immer erforderlich zu sein, um diese ungewöhnlichen/Kantenfälle zu bewältigen. Wie können sie geschafft werden, den Code relativ lesbar und verständlich zu halten?

Betrachten Sie ein Beispiel, das sich mit der Feature -Erkennung von Fotos befasst (nicht genau das, woran ich arbeite, aber die Analogie scheint passend). Wenn ich ein bestimmtes Bild finde, für das der allgemeine Algorithmus fehlschlägt und ein Sonderfall benötigt wird, zeichne ich so am besten auf, dass ich diese Informationen in einem Kommentar (oder wie unten vorgeschlagen wird, einen beschreibenden Funktionsnamen). Was jedoch häufig fehlt, ist ein dauerhafter Link zu der bestimmten Datendatei, die das betreffende Verhalten ausweist. Während mein Kommentar das Problem beschreiben sollte und wahrscheinlich sagen würde "siehe Datei foo.jp für ein Beispiel für dieses Verhalten", befindet sich diese Datei nie im Quellbaum und kann sich leicht verlieren.

Fügen Sie in solchen Fällen den Quellbaum als Referenz zum Quellbaum Datendateien hinzu?

Answer 1

Wenn Sie eine Wissensbasis oder ein Wiki für das Projekt haben, können Sie das Diagramm hinzufügen und in der Methode gemäß der Methode verknüpfen Matthews Fowler -Quotee und auch in der Quellungssteuerungs -Commit -Nachricht für die Edge -Falländerung.

//See description at KB#2312
private object SolveXAndYEdgeCase(object param)
{
   //modify param to solve for edge case
   return param;
}

Commit Message: Solution for X and Y edge case, see description at KB#2312

Es ist mehr Arbeit, aber eine Möglichkeit, Fälle gründlicher zu dokumentieren als bloße Testfälle oder Kommentare. Auch wenn man argumentieren könnte, dass Testfälle dokumentation genug sein sollten, möchten Sie beispielsweise möglicherweise nicht den gesamten fehlenden Datensatz im IT speichern.

Denken Sie daran, vage Probleme führen zu vagen Lösungen.

Answer 2

Martin Fowler sagte in seinem Refactoring -Buch, dass Sie zuerst sehen können, ob Sie diesen Code in eine Methode in eine Methode einschließen und der Methode einen Namen geben würden, der den Kommentar ersetzen würde.

Als Zusammenfassung können Sie also eine Methode namens erstellen.

private bool ConditionXAndYHaveOccurred(object param)
{
   // code to check for conditions x and y
   return result;
}

private object ApplySolutionForEdgeCaseWhenXAndYHappen(object param)
{
   //modify param to solve for edge case
   return param;
}

Dann können Sie Code wie schreiben wie

if(ConditionXAndYHaveOccurred(myObject))
{
    myObject = ApplySolutionForEdgeCaseWhenXAndYHappen(myObject);
}

Kein hartes und schnelles konkretes Beispiel, aber es würde in ein oder zwei Jahren bei der Lesbarkeit helfen.

Answer 3

Unit -Tests können hier helfen. Wenn Sie Tests haben, die die speziellen Fälle tatsächlich simulieren, können sie häufig als Dokumentation darüber dienen, warum der Code das tut, was er tut. Dies kann oft besser sein als nur das Problem in einem Kommentar zu beschreiben.

Nicht, dass dies ersetzt wird, um das Sonderfall -Handling in ihre eigenen Funktionen und anständigen Kommentare zu ersetzen ...

Answer 4

Ich bin normalerweise kein Verfechter der testgetriebenen Entwicklung und ähnlichen Stilen, die zu viel Stresstests testen, aber dies scheint ein perfekter Fall zu sein, bei dem ein Haufen Unit -Test viel helfen kann. Und nicht einmal in erster Linie, um Fehler aus späteren Änderungen zu erfassen, sondern einfach alle Sonderfälle zu dokumentieren, die angegangen werden müssen.

Ein paar gute Unit -Tests mit Kommentaren in ihnen sind an sich die beste Beschreibung der Sonderfälle. Und das Kommentieren des Code selbst wird auch einfacher. Man kann einfach auf einige Unit -Tests verweisen, die das Problem veranschaulichen, das an diesem Punkt im Code gelöst wird.

Answer 5

Über die

Ich wünschte manchmal, es gäbe eine Möglichkeit, Grafiken in den Quellcode einzubetten oder zu verknüpfen. Daher könnte ich effektiv sagen. Code wurde hinzugefügt ".

Teil:

Wenn die "Grafik", die Sie einbetten möchten, ein Diagramm ist und wenn Sie verwenden Doxygen, du kannst einbetten Punkt Befehle in Ihrem Kommentar, um eine Grafik in der Dokumentation zu generieren:

/**
If we have a subgraph looking like this:
\dot
digraph g{
A->B;
A->C;
B->C;
}
\enddot
the usual method does not work well and we use this heuristic instead.
*/

Answer 6

Don Knuth erfand Lemerkörperprogrammierung Um es Ihrer Programmdokumentation leicht zu machen, Handlungen, Diagramme, Diagramme, mathematische Gleichungen und alles, was Sie sonst noch zu verstehen müssen, enthalten. Ein gebildetes Programm ist eine großartige Möglichkeit zu erklären, warum etwas so ist, wie es ist und wie es im Laufe der Zeit so gekommen ist. Es gibt viele, viele literarische Programme. Das "Noweb" -Tool ist eines der einfachsten und wird mit einigen Linux -Verteilungen versendet.

Answer 7

Ohne zu wissen, dass die spezifische Natur Ihres Problems nicht einfach ist, um eine Antwort zu geben, aber nach meiner eigenen Erfahrung muss der Umgang mit Sonderfällen auf Hardcode vermieden werden. Haben Sie nicht darüber nachgedacht, eine Regeln -Engine oder ähnliches zu implementieren, um Sonderfälle außerhalb Ihres Hauptverarbeitungsalgorithmus zu bearbeiten?

Answer 8

Es hört sich so an, als ob Sie eine gründlichere Dokumentation benötigen als nur Code -Kommentare. Auf diese Weise könnte jemand die fragliche Funktion in der Dokumentation nachschlagen und ein Beispielbild präsentiert werden, das einen Sonderfall erfordert.