Gibt es einen allgemein akzeptierten besten Ansatz zur Codierung komplexer Mathematik? Zum Beispiel:
%Vor%Ist das ein Punkt, an dem die Nummern hart codiert werden? Oder sollte jeder Zahl eine Konstante zugeordnet sein? Oder gibt es noch einen anderen Weg, wie die Berechnungen in der Konfiguration zu speichern und sie irgendwie aufzurufen?
Es wird eine Menge Code wie dieser geben, und ich versuche, ihn wartbar zu halten.
Hinweis: Das oben gezeigte Beispiel ist nur eine Zeile. Es würde Dutzende oder Hunderte dieser Codezeilen geben. Und nicht nur die Zahlen könnten sich ändern, sondern auch die Formel.
Im Allgemeinen gibt es zwei Arten von Konstanten - solche mit der Bedeutung für die Implementierung und solche mit der Bedeutung für die Geschäftslogik.
Es ist in Ordnung, die Konstanten der ersten Art fest zu codieren: Sie sind privat, um Ihren Algorithmus zu verstehen. Wenn Sie beispielsweise eine ternäre Suche verwenden, müssen Sie das Intervall in drei Teile unterteilen, indem Sie es durch einen hartcodierten Teil dividieren 3 ist der richtige Ansatz.
Konstanten mit der Bedeutung außerhalb des Codes Ihres Programms sollten andererseits nicht fest codiert sein: geben Sie ihnen explizite Namen, gibt jemand, der Ihren Code beibehält, nachdem Sie die Firma verlassen, keine Chance, die richtigen Änderungen ohne zu machen Dinge von Grund auf neu schreiben oder per E-Mail um Hilfe bitten.
"Ist es in Ordnung"? Sicher. Soweit ich weiß, gibt es keine paramilitärische Polizeitruppe, die diejenigen zusammenführt, die gegen den einen wahren Glauben der Programmierung sündigen. (Noch.).
Ist es klug?
Nun, es gibt alle möglichen Arten, dies zu entscheiden - Leistung, Skalierbarkeit, Erweiterbarkeit, Wartbarkeit usw.
Auf der Wartbarkeitsskala ist dies pures Übel. Es macht die Erweiterbarkeit sehr schwierig; Leistung und Skalierbarkeit sind wahrscheinlich keine große Sorge.
Wenn Sie eine einzelne Methode mit vielen ähnlichen Zeilen zurückgelassen haben, hat Ihr Nachfolger keine Chance, den Code beizubehalten. Er würde Recht haben, eine Neufassung zu empfehlen.
Wenn du es kaputt gemacht hast wie
%Vor%und jede der inneren Methoden ist ein paar Zeilen lang, aber du hast dort einige hartcodierte Werte hinterlassen - nun, nicht brillant, aber nicht schrecklich.
Wenn sich jedoch einige dieser fest codierten Werte im Laufe der Zeit ändern (wie der Steuersatz), ist es nicht in Ordnung, sie als fest codierte Werte zu belassen. Es ist schrecklich.
Der beste Rat, den ich geben kann, ist:
Normalerweise frage ich mich, ob ich den Code um drei Uhr nachts behalten und reparieren kann, wenn er sechs Monate nach dem Schreiben des Codes nicht mehr schlafen kann. Es hat mir gut gedient. Wenn ich deine Formel ansehe, bin ich mir nicht sicher, ob ich das kann.
Vor Jahren arbeitete ich in der Versicherungsbranche. Einige meiner Kollegen wurden beauftragt, die versicherungsmathematischen Formeln in Code umzuwandeln, zuerst für FORTRAN und später C. Mathematische und Programmierfähigkeiten variierten von Kollege zu Kollege. Was ich gelernt habe, war die folgende Überprüfung ihres Codes:
Das heißt, es gibt Zeiten, in denen hartes Codieren einfach Dinge vereinfacht, besonders wenn diese Werte in einem bestimmten Kontext gut verstanden werden. Zum Beispiel, indem Sie etwas durch 100 oder 1000 teilen (oder multiplizieren), weil Sie einen Wert in Dollar umrechnen. Ein anderer ist es, etwas mit 3600 zu multiplizieren, wenn Sie Stunden in Sekunden umwandeln möchten. Ihre Bedeutung wird oft aus dem größeren Zusammenhang angedeutet. Das folgende sagt nicht viel über magische Nummer 100:
%Vor%aber das folgende könnte Ihnen einen besseren Hinweis geben:
%Vor%Wie der obige Kommentar feststellt, ist dies alles andere als komplex.
Sie können jedoch die Magic -Nummern in constants / app.config-Werten speichern, um es dem nächsten Entwickler zu erleichtern, Ihren Code zu verwalten.
Wenn Sie solche Konstanten speichern, stellen Sie sicher, dass Sie dem nächsten Entwickler (lesen Sie selbst in einem Monat) erklären, was Ihre Gedanken waren und was sie beachten sollten.
Überlegen Sie auch, wofür die eigentliche Berechnung und was sie gerade macht.
Gehen Sie nicht so wie in der Reihe.
Konstante, damit Sie sie wiederverwenden, leicht finden, ändern und besser pflegen können, wenn jemand Ihren Code zum ersten Mal sieht.
Sie können eine Konfiguration vornehmen, wenn sie angepasst werden kann / sollte. Welchen Einfluss hat ein Kunde auf den Wert? Manchmal ist es am besten, ihnen diese Option nicht zu geben. Sie könnten es selbst ändern und dann die Schuld geben, wenn die Dinge nicht funktionieren. Andererseits, vielleicht haben sie es häufiger im Fluss als Ihre Veröffentlichungspläne.
Es ist erwähnenswert, dass der C # -Compiler (oder ist es die CLR) automatisch 1-Linien-Methoden inline, also wenn Sie bestimmte Formeln in einen Liner extrahieren können Sie sie als Methoden ohne Leistungseinbußen extrahieren.
BEARBEITEN:
Konstanten und solche mehr oder weniger hängt von der Mannschaft und der Menge der Nutzung ab. Wenn Sie dieselbe fest codierte Nummer mehr als einmal verwenden, müssen Sie sie natürlich konstant halten. Wenn Sie jedoch eine Formel schreiben, die wahrscheinlich nur von Ihnen bearbeitet wird (kleines Team), dann ist die Codierung der Werte in Ordnung. Alles hängt von den Ansichten Ihres Teams zu Dokumentation und Wartung ab.
Wenn die Berechnung in Ihrer Zeile etwas für den nächsten Entwickler erklärt, dann können Sie es verlassen, andernfalls ist es besser, in Ihren Code- oder Konfigurationsdateien einen konstanten Wert zu berechnen.
Ich habe im Produktionscode eine Zeile gefunden, die wie folgt aussah:
%Vor% Ohne Kommentar war es nicht schwer, dass der ursprüngliche Entwickler 1 hour in Millisekunden meinte, anstatt einen Wert von 3600000 zu sehen.
IMO Vielleicht sind Berechnungen für solche Szenarien besser.
Namen können zu Dokumentationszwecken hinzugefügt werden. Der Umfang der erforderlichen Dokumentation hängt weitgehend vom Zweck ab.
Betrachten Sie folgenden Code:
%Vor%Und kontrastiere es mit dem folgenden:
%Vor% Auch wenn die Variablennamen in letzterem nicht sehr "beschreibend" sind, werden Sie viel bessere Vorstellung davon haben, was der Code tut - vielleicht ist es nicht nötig, c in speedOfLight umzubenennen, m bis mass und e für Energie, da die Namen in ihren Domänen erklärend sind.
Ich würde behaupten, dass der zweite Code der klarste ist - vor allem, wenn der Programmierer erwarten kann, STR im Code zu finden (LHC-Simulator oder etwas Ähnliches). Zusammenfassend - Sie müssen einen optimalen Punkt finden. Je ausführlicher der Code ist, desto mehr Kontext liefert er - was sowohl dazu beitragen kann, die Bedeutung zu verstehen (was e und c vs. wir tun etwas mit Masse und Lichtgeschwindigkeit) und das große Bild zu verdunkeln (wir quadrieren c und multiplizieren Sie mit m gegen die Notwendigkeit, ganze Zeile zu scannen, um die Gleichung zu erhalten).
Die meisten Konstanten haben etwas tiefere meening und / oder etablierte Notation, so würde ich es zumindest nach der Konvention benennen ( c für Lichtgeschwindigkeit, R für Gaskonstante, sPerH für Sekunden in der Stunde). Wenn die Notation nicht klar ist, sollten die längeren Namen verwendet werden ( sPerH in der Klasse Date oder Time ist wahrscheinlich in Ordnung, während sie nicht in Paginator ist). Die wirklich offensichtlichen Konstanten könnten fest codiert sein (sagen wir - Division durch 2 bei der Berechnung der neuen Array-Länge in merge sort).
Tags und Links c#