it-swarm.com.de

Was sind Beispiele für Kommentare, die Ihnen sagen, warum statt wie oder was?

Zunächst möchte ich mich in dieser Frage von der Polemik fernhalten, ob das Kommentieren von Quellcode gut oder schlecht ist. Ich versuche nur klarer zu verstehen, was die Leute meinen, wenn sie über Kommentare sprechen, die Ihnen sagen, WARUM, WAS oder WIE.

Wir sehen oft Richtlinien wie "Kommentare sollten Ihnen sagen, warum; Code selbst sollte Ihnen sagen, wie". Es ist leicht, der Aussage auf abstrakter Ebene zuzustimmen. Normalerweise lassen die Leute dies jedoch wie ein Dogma fallen und verlassen den Raum ohne weitere Erklärung. Ich habe gesehen, dass dies an so vielen verschiedenen Orten und in so vielen verschiedenen Kontexten verwendet wird, dass es so aussieht, als könnten sich die Leute auf das Schlagwort einigen, aber sie scheinen völlig über verschiedene Dinge zu sprechen.

Zurück zur Frage: Wenn Kommentare Ihnen sagen sollten, WARUM, wovon sprechen wir? Ist dies der Grund, warum dieser Code überhaupt existiert? Ist es das, was dieser Stückcode tun sollte? Ich würde mich sehr freuen, wenn jemand eine klare Erklärung geben und dann einige gute Beispiele hinzufügen könnte (schlechte Beispiele werden nicht wirklich benötigt, konnten sie aber als Kontrast hinzufügen).

Es gibt viele Fragen, ob Kommentare gut oder schlecht sind, aber niemand, der sich mit der spezifischen Frage befasst, was gute Beispiele für Kommentare sind, die Ihnen sagen, WARUM.

80
rick

Das häufigste und markanteste Beispiel sind Kommentare zu verschiedenen Problemumgehungen. Zum Beispiel dieses:

https://github.com/git/git/blob/master/compat/fopen.c :

/*
 *  The order of the following two lines is important.
 *
 *  FREAD_READS_DIRECTORIES is undefined before including git-compat-util.h
 *  to avoid the redefinition of fopen within git-compat-util.h. This is
 *  necessary since fopen is a macro on some platforms which may be set
 *  based on compiler options. For example, on AIX fopen is set to fopen64
 *  when _LARGE_FILES is defined. The previous technique of merely undefining
 *  fopen after including git-compat-util.h is inadequate in this case.
 */
#undef FREAD_READS_DIRECTORIES
#include "../git-compat-util.h"

Weitere Beispiele finden Sie sicherlich in Git- und Linux-Quellen. Beide Projekte versuchen, dieser Regel zu folgen.

Ich empfehle außerdem, diese Regel mit Commit-Protokollen noch strenger zu befolgen. Bei Codekommentaren kann es vorkommen, dass Sie den Code korrigieren, aber vergessen, den Kommentar zu aktualisieren. Mit der Menge an Code in einem normalen Projekt wird dies garantiert früher oder später geschehen. Andererseits ist das Festschreibungsprotokoll an die jeweilige Änderung gebunden und kann mithilfe der Funktion "Annotate"/"Blame" des Versionskontrollsystems abgerufen werden. Wieder haben Git und Linux einige gute Beispiele.

Schauen Sie z. at this commit . (hier nicht kopieren, es ist zu lang). Es hat vier Absätze, die fast die ganze Seite (und ein bisschen über den Bildschirm) dauern und beschreiben, was genau falsch war und warum es falsch war und dann weitergeht und alle sechs Zeilen modifiziert. Sie verwenden solche Kommentare für zwei Zwecke:

  1. Alle eingereichten Änderungen werden überprüft und das Festschreibungsprotokoll muss dem Prüfer die Änderung erklären.
  2. Wenn ein Fehler gefunden wird, werden die relevanten Protokolle mit "Spitzhacke" oder "Schuld" abgerufen, um zu vermeiden, dass zu einem früheren, auch falschen Verhalten zurückgekehrt wird.

(Hinweis: Es dauerte höchstens 10 Minuten, bis ich das Git-Repo zufällig durchsucht hatte, um diese beiden Beispiele zu finden. Es wäre also sicher einfach, dort mehr zu finden.)

62
Jan Hudec

Ein Kommentar, der Ihnen sagt warum erklärt die Gründe für den Code - zum Beispiel:

// We need to sync the values if the temp <doodad> GUID matches one of the active <doodad>'s
// GUID, as the temp <doodad> has the most recent values according to the server and said 
// values might have changed since we added the <doodad>. We want a user to be able to <foo> 
// the <doodad> whenever, which means those values must be accurate.
for (doodad in doodads) {
    if ([doodad guid] == [tempDoodad guid]) {
        [doodad updateFromDoodad:tempDoodad];
        break;
    }
}

Ein Kommentar, der Ihnen sagt wie erklärt, was der Code tut.

// Loop through our <doodads> and check for a GUID match. If it matches, copy the new values
// on the <doodad> that matches 
for (doodad in doodads) {
    if ([doodad guid] == [tempDoodad guid]) {
        [doodad updateFromDoodad:tempDoodad];
        break;
    }
}

Der Unterschied besteht darin, dass ein Betreuer sich den ersten ansehen und sagen kann: "Oh, das könnte also veraltet sein!" Im zweiten Fall hat der Betreuer einen Kommentar, der Ihnen nichts sagt, was der Code selbst nicht preisgibt (unter der Annahme guter Variablennamen).

Hier ist ein Beispiel aus dem wirklichen Leben für einen Warum-Kommentar aus einem iOS-Code, an dem ich gearbeitet habe, wo wir eine Gateway-Adresse benötigen (oder eine vernünftige Vermutung dafür). Ich hätte einfach die Kommentare hinterlassen können, die Dinge wie "Initialisieren des Empfangs-Sockets" besagten, aber das würde nur einem Betreuer (oder mir in Zukunft) sagen, was passiert ist, und nicht, warum ich diesen seltsamen Kludge machen musste, um die Gateway-Adresse in der zu erhalten erster Platz.

/*
 We're going to do something really hacky here and use a custom partial
 implementation of traceroute to get our gateway IP address.

 [rant removed - irrelevant to the point]

 There's no good way to get at the gateway address of an iDevice
 right now. So, we have two options (per https://devforums.Apple.com/message/644915#644915 ):
 1. Get at and parse the routing table (like netstat -rn, or route -n)
 2. Do a traceroute and grab the IP address for the first hop

 As far as I can tell, the former requires <sys/route.h> from the Mac OS X
 header files, which doesn't seem like a good idea to me. Also, there's a
 thread on the Apple Developer forums that seems to imply that header isn't
 in iOS for a reason (https://devforums.Apple.com/message/774731#774731 ).

 So when we send our request with a TTL of one it will survive a single hop
 to the router and return, triumphant, with the router's IP address!

 Viva la kludge!

 PS: Original source was the below SO question, but I've modded it since then.
 http://stackoverflow.com/questions/14304581/Hops-tracing-ttl-reciveform-on-ios/14304923#14304923
 */

// Default to using Google's DNS address. We used to try checking www.google.com
// if reachability reported we had internet, but that could still hang on routers
// that had no internet connectivity - not sure why.
const char *ip_addr = [kGoogleDNS UTF8String]; // Must be const to avoid undefined behavior
struct sockaddr_in destination,fromAddr;
int recv_sock;
int send_sock;

// ... more code follows
29
thegrinner

Ich möchte meine Antwort mit einem Zitat beginnen, das Jeff Atwood in seinem Blog-Beitrag gemacht hat Code sagt dir wie, Kommentare sagen dir warum :

die besten Kommentare sind diejenigen, die Sie nicht benötigen

Er gibt auch an, dass:

Sie sollten sich zunächst bemühen, Ihren Code so einfach wie möglich zu verstehen, ohne sich auf Kommentare als Krücke verlassen zu müssen. Nur an dem Punkt, an dem der Code nicht leichter verständlich gemacht werden kann, sollten Sie mit dem Hinzufügen von Kommentaren beginnen.

Ich stimme vollkommen zu und an dieser Stelle muss ich hinzufügen, dass ich, bevor ich anfangen kann, den Code so einfach wie möglich zu gestalten, den Code zum Laufen bringe und dann mit dem Refactoring beginne. Während des ersten Durchlaufs vor dem Refactoring hilft das Hinzufügen von , warum Kommentare sehr hilfreich sind.

Wenn Sie beispielsweise 3 verschachtelte Schleifen mit zweidimensionalen Hashtabellen verwenden, um eine Tabelle mit Wochentagen zu füllen, während Sie Daten analysieren, verlieren Sie leicht den Überblick darüber, was jemand oder sogar Sie selbst getan haben, wenn Sie einige Wochen lang nicht darauf achten und plötzlich umgestalten.

[loop1]6oclock -> [loop2]Monday -> [loop3]stage 1 to 4
         -> tuesday-> stage 1 to 4
         ...
         -> Saturday -> stage 1 to 4
    7oclock -> Monday-> stage 1 to 4
        ....etc.

Das obere ist ein Beispiel dafür, wie 3 verschachtelte Schleifen vor dem Refactoring funktionieren würden.
Auch das Erklären einiger Verzweigungsbedingungen kann helfen, Code besser zu verstehen, wenn man bedenkt, was man dabei gedacht hat:

// added a zero before the actual day in order for the days always to be 2 digits long.
if( actualDayFuture < 10 ) 
{ 
     actualDayFuture = padIfSingleDigitDate(actualDayFuture); 
}

Selbst einfacher und offensichtlicher Code funktioniert gut mit Kommentaren. Nur um die Dinge für Kollegen und sogar für sich selbst bei der Wartung von Software ein wenig offensichtlicher, klarer oder verständlicher zu machen.

Sicher, xp gibt an, Code zu haben, der sich selbst erklärt, aber tut ein einzeiliger Kommentar weh?

Ich finde auch die folgenden Regeln aus diesem Blog sehr hilfreich:

  • Verstehe das Material, bevor du schreibst
  • Schreiben Sie, als wäre Ihr Publikum ein Viertklässler
  • Überlegen Sie, wie Leser Sie falsch interpretieren könnten

Jeder, der wieder in seinen eigenen Code oder in einen anderen Code oder sogar in einen alten Code zurückkehren muss, weiß, dass dies Kopfschmerzen verursachen kann. Also, anstatt faul zu sein oder zu versuchen, ein Übercodierer zu sein, der nichts oder nur sehr wenig kommentiert, warum nicht Ihr eigenes oder ein schlechtes Arschloch, das Ihren Code pflegen muss, das zukünftige Leben viel einfacher machen, indem Sie die angegebenen Regeln befolgen.

Auch viele Programmierentscheidungen werden bei Überprüfungen angezweifelt, und es ist nicht immer klar, warum einige Teile so geschrieben wurden, wie sie waren, auch wenn einige Codeabschnitte für ein Programm von entscheidender Bedeutung sind, da ein schwerwiegender Fehler festgestellt wurde, als der Code über Jahre hinweg verwendet wurde . Um Sie nicht alle mit einem tl zu langweilen, schließen Sie mit einem letzten Zitat aus acmqueue :

Eine vorherige, klare und umfassende Dokumentation ist ein Schlüsselelement bei der Erstellung von Software, die überleben und sich anpassen kann. Das Dokumentieren nach hohen Standards verkürzt die Entwicklungszeit, führt zu besserer Arbeit und verbessert das Endergebnis. Es ist schwer, von irgendeiner Technik mehr als das zu verlangen.

18
Ben McDougall

Ich neige dazu, Kommentare entweder auf Referenzen zu reduzieren, in denen eine bestimmte Funktionalität/ein bestimmter Code ausführlicher erklärt wird, oder zu erklären, warum eine bestimmte Art der Programmierung gewählt wird.

In Anbetracht der Tatsache, dass andere Programmierer mit ähnlichen Fähigkeiten Ihren Code verwenden oder lesen, ist es wichtig zu kommentieren, ob Sie eine andere als erwartete Methode verwenden, um etwas zu erreichen. So können Sie in einem Kommentar erklären, warum Sie diesen Weg wählen.

Wenn Sie beispielsweise zwei verschiedene Sensoren auf einem Android Gerät) verwenden können und einer davon nicht Ihren Anforderungen entspricht, können Sie im Kommentar erklären, warum Sie den anderen ausgewählt haben.

Das 'Warum' sollte also ein Begründung für Ihre getroffenen Entscheidungen geben.

8
Roalt

Kommentare sollten Ihnen sagen, was der Code nicht tut, nicht unbedingt abgegrenzt durch WARUM , WIE = oder WAS . Wenn Sie gute Namen und gut abgegrenzte Funktionen haben, ist es durchaus möglich, dass der Code Ihnen genau sagt, was los ist. Zum Beispiel:

List<LightMap> maps = makeLightmaps(receivingModels);
TrianglePartitioner partition = new Octree(castingTriangles);
List<Photon> photons = firePhotons(lights, partition);

if (photons.Count > 0)
{
      PhotonPartitioner photonMap = new KDTree(photons);
      gatherPhotons(maps, photonMap, partition, lights);
}

Dieser Code braucht wirklich keine Kommentare. Die Funktions- und Typnamen erleichtern das Verständnis.

Manchmal kann es jedoch schwierig oder unmöglich sein, wirklich fließenden Code wie den oben genannten zu erstellen. Das nächste Codeausschnitt dient beispielsweise zum Auffinden eines statistisch zufälligen Punkts auf einer Kugel. Die Mathematik ist ziemlich undurchsichtig, daher soll ein Kommentar mit einem Link zur Erklärung helfen, WIE es funktioniert. Dies kann in eine Funktion eingeschlossen werden, die WHAT mitteilt, ohne dass bei Bedarf mehr als einmal ein Kommentar erforderlich ist. Andernfalls hilft der Link-Titel auch in dieser Abteilung.

double randomA = localGenerator.NextDouble();
double randomB = localGenerator.NextDouble();

//http://mathworld.wolfram.com/SpherePointPicking.html
double theta = 2 * Math.PI * randomA;
double phi = Math.Acos(2 * randomB - 1);

Vector3 randomDirection = new Vector3(Settings.ambientRayLength * (float)(Math.Cos(theta) * Math.Sin(phi)),
                                      Settings.ambientRayLength * (float)(Math.Sin(theta) * Math.Sin(phi)),
                                      Settings.ambientRayLength * (float)Math.Cos(phi));

Ein weiteres Beispiel dafür, wann Kommentare Ihnen sagen, was der Code nicht tut, ist die Erklärung einer Entscheidung. Im nächsten Beispiel sperrt der Code keine nicht threadlokale Variable in einem Code mit Thread. Es gibt einen Grund dafür und der Kommentar erklärt WARUM . Ohne den Kommentar könnte es als Fehler angesehen werden oder einfach nicht einmal bemerkt werden.

Random random = new Random();
Parallel.For(0, maxPhotons, delegate(int photonIndex, ParallelLoopState state)
{
    ...
    //I don't actually care if this random number is unique between threads, threadsafty is not that big of a deal
    //  in this case and locking the random object could cause a lot of lock contention
    while (random.NextDouble() > reflectProbability)
    {
        ...
    }
    ...
}

Es könnte vielleicht verbessert werden zu sagen, warum das zufällige Objekt überhaupt nicht innerhalb der parallelen Schleife erstellt wird. Wenn es keinen Grund gibt, könnte es auch jemanden dazu bringen, mitzukommen und zu erkennen, dass die ganze Idee dumm ist und ein guter Ort für Refactoring ist.

8
Chewy Gumball

Es kann hilfreich sein, verschiedene Arten von "Warum" zu erkennen - insbesondere:

  • Gründe dafür, dass Code, der zu komplex erscheint, bei Vereinfachung nicht funktioniert (z. B. kann eine scheinbar überflüssige Typumwandlung erforderlich sein, um sicherzustellen, dass Code in einigen Eckfällen funktioniert).

  • Gründe dafür, dass eine bestimmte einfache Operation, die gefährlich aussieht, tatsächlich sicher ist (z. B. "Unsere Routine zum Abrufen von Daten meldet, dass ein Dummy-Element nach dem letzten Element kleiner als alles andere ist und das Element danach als größer; jedes Element, das sortiert werden soll." vor einem anderen folgt in einer konsistenten aufsteigenden oder absteigenden Reihenfolge mindestens ein weiteres (möglicherweise Dummy-) Element ").

In vielen Fällen kann ein Kommentar des zweiten Typs in einem Teil des Codes mit einem Kommentar des ersten Typs in einem anderen "übereinstimmen" (z. B. "Obwohl es so aussieht, als könnte diese Abfolge von Operationen vereinfacht werden, stützt sich die Fitz-Routine darauf Die Wongle wird erst verwöhnt, nachdem der Bandersnatch geblasen wurde. ")

5
supercat

Nicht alle meine Kommentare sind vom Typ "Warum", aber viele sind es.
Dies sind Beispiele aus einer (Delphi) Quelldatei:

// For easier access to the custom properties:

function GetPrivate: Integer;   // It's an integer field in the external program so let's treat it like that here

// The below properties depend on the ones above or are calculated fields.
// They are kept up-to-date in the OnEventModified event of the TTSynchronizerStorage
// or in the ClientDataSet.OnCalcFields of the TcxDBSchedulerStorage.DataSource.DataSet
property IsModified       : Boolean   read GetIsModified   write SetIsModified;
property IsCatTT          : Boolean   read GetIsCatTT      write SetIsCatTT;
property IsSynced         : Boolean   read GetIsSynced     write SetIsSynced;

lLeftPos := pos(' - [',ASubject); // Were subject and [shiftnaam:act,project,cust] concatenated with a dash?

// Things that were added behing the ] we will append to the subject:

// In the storage the custom value must also be set for:
Self.SetCustomFieldValueByname(cCustFldIsCatTT,Result);

// When we show the custom fields in a grid, the Getters are not executed,
// because the DevEx code does not know about our class helpers.
// So we have two keep both properties synchronized ourselves:

// lNewMasterEvent was set to usUpdated, overwrite because we added:
if ARepair then
  lNewMasterEvent.CustUpdateStatus := usRecreated

// The source occurrence date may have bee changed. Using GetOriginalDate we can retrieve the original date,
// then use that for creating a target occurrence (and update its date):

lNewTTOccurrence.CustSyncEntryID := cSyncEntryID0;    // Backward compatibility with old sync methode

// Single event became recurring or vice versa; replace entire event

// In contradiction to CopySingleEventToTimeTell, CopyMasterEventToTimeTell does not have a ANewStatus parameter
// because master events are always added.

Beachten Sie, dass (my) warum Kommentare normalerweise vor dem Code stehen, der dies tun wird (daher mit einem Doppelpunkt enden).

Ich habe einige Kommentare, die nur erklären , was passiert, z. Wenn ein Prozess viele Schritte hat, die eine logische Gruppierung haben (und der Code nicht überarbeitet wird, um dies automatisch anzuzeigen), werde ich Folgendes kommentieren:

// Step 1. Initialization
2
Jan Doggen

Vergessen Sie nicht, wenn Sie ein Programm schreiben, tippen Sie nicht nur zufällig etwas, sondern tun es, weil Sie ein Modell dessen, was Sie wollen haben, ob es sich um ein formelles Dokument handelt oder nur in deinem Kopf. Dinge in Ihrem Kopf sind genauso real wie Software/Daten in einem Computer (und enthalten genauso wahrscheinlich Fehler).

Jemand, der Ihren Code liest, hat dieses Modell möglicherweise nicht im Kopf, sodass Kommentare dazu dienen können, ihm zu sagen, was das Modell war und wie sich der Code darauf bezieht. Ich denke, das ist es, was mit "warum" gemeint ist. Natürlich ist es gut, den Code selbst so selbsterklärend wie möglich zu gestalten, aber das ist nicht immer gut genug. Beispiel:

// transform the x,y point location to the nearest hexagonal cell location
ix1 = (int)floor(0.5 + x + y/2);
iy1 = (int)floor(0.5 + y);

Darüber hinaus ändert sich das Modell im Laufe der Zeit, und diese Änderungen müssen in den Code übertragen werden. Die Kommentare müssen also nicht nur "warum" etwas im Code enthalten, sondern auch genauso wichtig wie man es ändert als Reaktion auf erwartete Modelländerungen. Beispiel:

// to change to square cell locations, remove the "+ y/2" in the above code

Ich denke, dass der Zweck für Kommentare manchmal vernachlässigt wird.

2
Mike Dunlavey

Ich verstehe das WARUM als den Grund, warum Sie etwas auf möglicherweise seltsame oder möglicherweise unlogische Weise tun, aufgrund der gegebenen Umstände, die dies erfordern. Das WIE kann im Code selbst gesehen werden, egal wie seltsam es ist, auch wenn der Code keinen "Sinn" ergibt. Das WAS wird wahrscheinlich am besten am Anfang der Klassen-/Funktionsdokumentation gesagt. Sie müssen also das WARUM hinzufügen, in dem Sie alles erklären, was nicht im WIE und WAS enthalten ist, und die besonderen Wege, die Sie aus darüber hinausgehenden Gründen einschlagen müssen Ihre Kontrolle.

Natürlich ist dies nicht immer der Fall, außerhalb des Landes der Einhörner und Regenbogen ...

WIE :

foreach($critters as $creature) {
   $creature->dance();
}

WAS :

/* Dancing creatures v1.0
 * 
 * The purpose of this is to make all your critters do the funky dance.
 */

foreach($critters as $creature) {
  $creature->dance();
}

WARUM :

// We had to store the items in an array of objects because of _____ (reason)
foreach($critters as $creature) {
   $creature->dance();
}
1
Juha Untinen

Ich habe gelernt, IMMER Kommentare in C++ - Headerdateien zu schreiben (da nicht immer klar ist, WAS eine Funktion tut, obwohl der Name einen guten Hinweis gibt), insbesondere wenn Sie eine API an andere Entwickler weitergeben oder ein Tool für Autodoc wie doxygen verwenden.

Für mich sieht ein typischer Kommentar so aus

/*** Functionname
/*   What happens here
/*  [in] Params
/*  [out] params
/*** 

Das einzige Mal, dass ich WARUM Kommentare verwendet habe, sind Dinge, die schwer zu verstehen sind und manchmal sogar für den Programmierer, wie "BERÜHREN SIE DIESES NICHT! Weil ..." oder "PROGRAMM STEIGT AB, WENN LINE IS GELÖSCHT ... "

Problemumgehungen, Hacks und seltsames Verhalten qualifizieren sich in meinen Augen für WARUM-Kriterien ...

Ein sehr gutes und sogar witziges Beispiel ist diese "Problemumgehung" für einen durcheinandergebrachten Code, der von einer Person namens Richard geschrieben wurde. Eine andere Person hat ihn verpackt und in den Kommentaren erklärt, warum ... https://stackoverflow.com/a/184673/979785

Leider gibt es einige Male, in denen Sie gezwungen sind, Bull **** einzuwickeln, weil Sie das Original nicht berühren können, entweder weil "es immer so war" oder weil Sie keinen Zugang haben oder ... nun, Sie Ich habe nicht die Zeit, das Original für den Zweck zu reparieren, der nicht wirklich für den Overhead qualifiziert ist.

1
AnyOneElse

Der Code soll den Ausführungsplan angeben. Auf diese Weise kann der Programmfolger (oder der Compiler) herausfinden, was zu tun ist und wie es zu tun ist. Das, was in Schritte unterteilt ist, denen der Programmfolger folgen kann. Die primitiven Schritte sind das Wie.

Die Absicht des Codierers ist eine andere Sache. In einfachem, klarem und unkompliziertem Code ist die Absicht offensichtlich. Jeder einigermaßen kompetente menschliche Leser wird durch Lesen des Codes zur Absicht eines Codeblocks gelangen. Der meiste Code sollte so lauten.

Gelegentlich ist die Beziehung zwischen Absicht und Plan dunkel. Der Code enthüllt das Was und das Wie, aber nicht das Warum. Dann lohnen sich Kommentare, die die Absicht offenbaren. Die Absicht des Programmierers ist das Warum.

0
Walter Mitty

Dieses Problem wird derzeit durch gespeicherte Prozeduren und Ansichten gegen ein komplexes und etwas kompliziertes Datenmodell übertragen.

Wir haben (zahlreiche) Auswahlen wie "Fall, wenn x.account nicht null ist und x.address in (Adresse von fedex auswählen), dann x.account sonst y.account endet" durchgehend erstellt und Produktivität wird erwartet, obwohl es keine Zeit gibt all to read den gesamten Quellcode. Und dieses Beispiel macht irgendwie Sinn, ist aber immer noch unergründlich.

Die Kommentare, die erklären, warum, wenn in Fedex, dann x und wenn nicht, y - Licht auf das gesamte System werfen und wenn wir genug davon lesen, beginnen wir, es zu bekommen. Und das ist zu stark vereinfacht und es gibt Hunderte oder Tausende ähnlicher Aussagen. Mein Herz glüht warm gegenüber demjenigen, der die Art von Entwickler aus dem Jahr 2007 war, der die Gründe dafür eingegeben hat.

Also ja, komplexe verschlungene Datenmodelle und haarige Ansichten und gespeicherte Prozeduren mit mehreren gültigen benannten Pfaden, bitte sagen Sie uns aus Liebe zu G-tt, warum.

0
naftalimich

Ich habe gerade diesen Kommentar geschrieben; Es ist ein konkretes Beispiel für die Erklärung von warum Eine Codezeile ist das, was sie ist, und insbesondere, warum ich sie geändert habe.

Die Methode untersucht gespeicherte Daten und bewertet, ob sie bis zum heutigen Tag einerseits und bis zum Startdatum am anderen Ende vollständig sind.

// In principal, this should be ">=", as we may have data up to the account start
// date but not complete for that day; in practice, 98% of the time if we have
// data for the start date it *is* complete, and requerying it would be a waste
// of time.
while (endDate > accountStartDate)
    ...

Wie Sie wahrscheinlich erraten können, war der Operator größer als gleich größer oder gleich. Der Kommentar erklärt, warum der alte Wert sinnvoll ist und warum der neue Wert besser ist. Wenn sich jemand dies in Zukunft ansieht, wird er feststellen, dass die Verwendung von ">" kein Versehen, sondern eine Optimierung ist. Sie können es dann ändern oder verlassen, je nach Bedarf zu diesem Zeitpunkt.

0
user25946