Laden...

Sollte alles im Code kommentiert werden?

Erstellt von itstata vor 14 Jahren Letzter Beitrag vor 14 Jahren 6.019 Views
I
itstata Themenstarter:in
302 Beiträge seit 2008
vor 14 Jahren
Sollte alles im Code kommentiert werden?

ich bin der Meinung bei selbstsprechenden Methoden- und Variablennamen ist dies nicht notwendig.

Beispiel: GetNameById()
oder eine Variable wie "id".

Wenn ich eine API erzeugen möchte muss ich alles kommentieren.

L
120 Beiträge seit 2007
vor 14 Jahren

Moin itstata,

wenn du das Programm selber geschrieben hast kennst du dich sicher aus,
aber was passiert wenn es mehrere Ids und Namen gibt die in dieser Seite
verwaltet werden und ein neuer in das Projekt einsteigt?! Bei "GetNameById()"
beispielsweise bleibt dann die Frage welchen Name du hier holst und welche Id
verwendet wird...

mfg,
Lec

4.207 Beiträge seit 2003
vor 14 Jahren

Ich kommentiere in meinen Projekten alles - lokale Variablen, private ebenso wie öffentliche Member.

Erstens hilft es dem eigenen Verständnis.
Zweitens hilft es dem Verständnis im Team.
Drittens muss ich dann nicht Kommentare nachziehen, wenn sich die Sichtbarkeit mal ändert - sprich, es ist von vornherein konsistenter.

Edit: Kleine Korrektur - lokale Variablen nur bedingt. Aber alles, wo man einen XML-Kommentar dranpacken kann, da schreibe ich ihn dazu.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

I
itstata Themenstarter:in
302 Beiträge seit 2008
vor 14 Jahren

Nehmen wir an die Methode ist in der Klasse User.
Ist das nicht eindeutig? User.GetNameById(..)

Ich kommentiere in meinen Projekten alles

Kommentierst du auch Konstruktoren?
ich wüsste nicht was ich hier reinschreiben sollte:


 /// <summary>
    /// Initializes a new instance of the <see cref="Contact"/> class.
    /// </summary>
    /// <param name="name">The name.</param>
      public Contact ( string name)
        {
....
        }

4.207 Beiträge seit 2003
vor 14 Jahren

Vorname? Nachname? Fullname? Wenn Fullname, in welchem Format? Was passiert, wenn die ID nicht existiert? Kommt null zurück? Eine Exception? ...?

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

5.941 Beiträge seit 2005
vor 14 Jahren

Salute zusammen

Ich halte es fast wie Golo, alles ausser privaten Variablen kommentieren.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

S
469 Beiträge seit 2007
vor 14 Jahren

Ich bin der Meinung, dass im Public-Bereich alles und auch alles einzeln kommentiert werden sollte.
Was den private Bereich betrifft, hier erstelle ich teilweise einen Kommentar für mehrere Variablen (Funktionen kommentiere ich immer, egal ob private oder public). Also wenn ich private Variablen habe, die nach außen durch Properties zugänglich sind, dann kann es sein, dass ich da obendrüber einen Kommentar mache "interne Variablen für die Properties", da es mir da etwas zu dumm und auch etwas als Zeitverschwendung vorkommt, über jedes einzeln zu schreiben "interne Variable für Property XYZ". Ich persönlich finde, dass ein Kommentar über jedem einzelnen aus einer Reihe zusammengehöriger Variablen das ganze auch etwas unübersichtlich machen kann.

gruß
sth_Weird

++++++++++++++++++++~+
Fluchen ist die einzige Sprache, die jeder Programmierer perfekt beherrscht


Linux is for free...if your time is worth nothing
++++++++++++++++++++~+

I
itstata Themenstarter:in
302 Beiträge seit 2008
vor 14 Jahren

Was passiert, wenn die ID nicht existiert? Kommt null zurück? Eine Exception? ...?

Wie kommentierst du dies? Solche Hinweise finde ich sehr hilfreich.

6.911 Beiträge seit 2009
vor 14 Jahren

Hallo,

entweder mit remarks, exception oder bei null auch dirket im param.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

Gelöschter Account
vor 14 Jahren

macht ihr auch codebeispiele in den kommentaren? ich meine nciht immer aber ab und an?

ich für mienen teil habe das schon ein paar mal gemacht, wo ich es als hilfreich angesehen habe (bei public sachen wo ich wußte das andere diese verwenden möchten)

edit:

/// <summary>
    /// Initializes a new instance of the <see cref="Contact"/> class.
    /// </summary>
    /// <param name="name">The name.</param>
      public Contact ( string name)
        {
....
        } 

ein gutes beispiel für nutzlose kommentare. da kann man sie auch gleich weglassen.

du sollst nciht kommentieren, was passiert, sondern warum es so passiert wie es passiert 😃

was geschieht, kann ich dem code direkt entnehmen aber die motivation und den grund kann ich nur erahnen.

I
itstata Themenstarter:in
302 Beiträge seit 2008
vor 14 Jahren

aber selbst für das warum fällt mir dazu nichts ein. Es ist ein simpler Konstruktor der das Objekt erzeugt.

macht ihr auch codebeispiele in den kommentaren? ich meine nciht immer aber ab und an?

Im CleanCode-Buch steht dazu sinngemäß:
Man sollte den Code soweit verbessern das er selbsterklärend ist. Also gemeint ist wenn man ein Beispiel für die Verwendung benötigt ist was am Code faul.

Ist aus meiner Sicht auch Idealismus. Der Gedanke ist aber sicher richtig.

Ich selbst hab einmal ein Beispiel kommentiert.

5.941 Beiträge seit 2005
vor 14 Jahren

Salute zusammen

Das habe ich zwar schon einmal erwähnt, aber nochmal: Clean Code ist extra extrem um aufzurütteln, man soll nicht alles für bare Münzen nehmen.

Bspw. sind Xml Docs (Gibts in Java auch) explizit von der Regel ausgeschlossen das Kommentare böse sind. Also sollte auch nicht darüber diskutiert werden.

Zum Selbstreden: Nunja, selbstredenden Code ist ja gut und schön. Allerdings habe ich noch nie eine wirklich selbstredende API gesehen - und genau dafür sind diese Xml Docs für Beispiele gedacht.

@Jack
Deine Schlussfolgerung "Dann kann man die Kommentare doch gleich weglassen" ist schon mal ganz böse 😃.

Grundsätzlich sollte nicht das offensichtliche kommentiert werden, das ist einleuchtend.
Allerdings handelt es sich hier wieder um Xml Docs. Dafür bekommst du Intellisense und API Dokumentation frei Haus.

Soll die leer sein oder soll dort das stehen, was du im Kommentar hast?
Ich würde mich für zweiteres entscheiden.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

Gelöschter Account
vor 14 Jahren

Man sollte den Code soweit verbessern das er selbsterklärend ist. Also gemeint ist wenn man ein Beispiel für die Verwendung benötigt ist was am Code faul.

demnach ist das ganze .net framework faul 😃
der hat ja an allen ecken und enden beispiele.

ich weiß nciht.. mir haben die beispiele aus der msdn schon geholfen und wenn jemand neu im projekt ist und meine api verwenden will, dann wird er darüber eher erfreut sein. ein eingearbeiteter entwickler wird die beispiele wohl eher nciht benötigen.

aber selbst für das warum fällt mir dazu nichts ein. Es ist ein simpler Konstruktor der das Objekt erzeugt.

wenn du mehrere überladungen hast, dann kannst du erklären, in welchen zustand das objekt versetzt wird, ewnn man diesen konstruktor verwendet.

in deinem beispiel wäre das dann, das das name property gesetzt wird und sonst ncihts. aber auch das ist hilfreich, da der benutzer dann weiß ,das da keine weitere magie gemacht wird.

@Jack
Deine Schlussfolgerung "Dann kann man die Kommentare doch gleich weglassen" ist schon mal ganz böse 😃.

Grundsätzlich sollte nicht das offensichtliche kommentiert werden, das ist einleuchtend.
Allerdings handelt es sich hier wieder um Xml Docs. Dafür bekommst du Intellisense und API Dokumentation frei Haus.

Soll die leer sein oder soll dort das stehen, was du im Kommentar hast?
Ich würde mich für zweiteres entscheiden.

böse... ja. aber mal ganz ehrlich, wenn du gerade beim parameter "name" bist und nciht auswendig weißt, was du da eingeben sollst und deine intellisence zeigt dir "the name" an... brauchst du das?

5.941 Beiträge seit 2005
vor 14 Jahren

Salute Jack

Nein, aber wieso soll ich mir damit die Vollständigkeit meiner API Kommentare versauen? 😉

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

I
itstata Themenstarter:in
302 Beiträge seit 2008
vor 14 Jahren

wenn du mehrere überladungen hast, dann kannst du erklären, in welchen zustand das objekt versetzt wird, ewnn man diesen konstruktor verwendet.

ok. das ist hilfreich. allerdings sag ich dann auch was gemacht wird, nicht warum 😃
man gibt dann u.u. interne dinge nach aussen die wichtig sind?

Gelöschter Account
vor 14 Jahren

@Peter Bucher: ok das hat was 😃

allerdings sag ich dann auch was gemacht wird, nicht warum 😃

warum ist im falle eines konstruktor klar. aber was in ihm passiert, wenn du ihn verwendest, ist nciht klar. bei konstruktoren muss der kommentar dabei helfen sich für den richtigen zu entscheiden.

man gibt dann u.u. interne dinge nach aussen die wichtig sind?

was wollen dann die leute damit anfangen? wenn du z.b. schreibst, das sich im konstruktor das objekt an den or-mapper manager hängt, dann kann das dem benutzer nur helfen. hier hast du zwar internas verraten (es gibt einen ormapper intern) aber was solls? reich wird man davon nciht.

5.742 Beiträge seit 2007
vor 14 Jahren

Hallo zusammen,

bei XML-Kommentaren stimme ich durchaus zu, dass man hier alle öffentlichen Typen kommentieren sollte.

Beim Rest ist mir meine Zeit ehrlich gesagt zu schade - was ist z.B. an


List<int> numbersToSummate = new List<int> {1, 2, 3, 4};

int sum = 0;
foreach (int number in numbersToSummate )
   sum += number;

nicht verständlich? IMHO nichts.

Das große Problem an solchen Kommentaren ist ja - laut CleanCode, dem ich mich in diesem Punkt anschließe - auch die Aktualität: Häufig werden die Kommentare nicht so sorgfältig gepflegt, wie der Code selbst, was zu noch mehr Verwirrung führt.
Besser als Kommentare seien sogar UnitTests (auch hier schließe ich mich CleanCode an): Auch anhand der Tests kann man ablesen, was unter welchen Umständen das erwartete Verhalten ist.

Wenn man Code verständlich genug schreibt, braucht man meiner Meinung nach keine Kommentare (XML-Doku für öffentliche Member wie gesagt ausgenommen!) - sie steigern (bis auf wenige Ausnahmen) die Klarheit des Codes nicht.

Und "dumm" ist ja derjenige, der den Code liest, auch nicht. Eine gewisse Ahnung darf man IMHO schon voraussetzen.

Gelöschter Account
vor 14 Jahren

Und "dumm" ist ja derjenige, der den Code liest, auch nicht. Eine gewisse Ahnung darf man IMHO schon voraussetzen.

ja und nein. die frage ist was darfst du vorraussetzen und was nciht. da ist die grenze absolut uneindeutig.

bei basissachen wie sprachkonstrukte ist es klar aber angenommen du programmierst für steuerungen. alle in deinem umfeld verwenden für einen oberbegriff eine abkürzung (z.b. statt Symbolische addressierung RidAidLid). nun ist diese abkürzung derart geläufig (in diesem umfeld, das du sie im code verwendest und dir denkst "hey, wer das nciht kennt hat im code ncihts zu suchen".

nun kommt ein neuer kollege aus einem anderen bereich und schaut in den code...

jetzt kann man natürlich sagen, das die methode z.b. falsch benannt ist... oder auch vielleicht schlecht kommentiert?

6.911 Beiträge seit 2009
vor 14 Jahren

Hallo,

es gibt ja auch noch Algorithmen/Berechnungen die von sich aus schon sehr kompliziert sind und sich mit Refactoring nichts machen lässt. Da ist jede Kommentar-Zeile sehr goldeswert. V.a. wenn nach längerer Zeit am Code wieder was angepasst werden soll.

Es kommt halt sehr auf den Fall darauf an...

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

I
itstata Themenstarter:in
302 Beiträge seit 2008
vor 14 Jahren

es gibt ja auch noch Algorithmen/Berechnungen die von sich aus schon sehr kompliziert sind und sich mit Refactoring nichts machen lässt. Da ist jede Kommentar-Zeile sehr goldeswert. V.a. wenn nach längerer Zeit am Code wieder was angepasst werden soll.

Damit meinst du wahrscheinlich innerhalb von Methoden? Das macht natürlich viel Sinn. Es ist halt nur sehr oft der Fall das man sowas sieht:


 /// <summary>
  /// class that represents a customer.
  /// </summary>
  class Customer
    {
    /// <summary>
    /// Initializes a new instance of the <see cref="Customer"/> class.
    /// </summary>
    /// <param name="name">The name of a customer.</param>
    public Customer (string name )
      {
      Name = name;
      }

    /// <summary>
    /// Gets or sets the name of a customer.
    /// </summary>
    /// <value>The name of a customer.</value>
    public string Name { get; private set; }
    }

Für mich stellt sich die Frage ob das eine gute Klasse ist. Ich denke nicht. Es ist zu unübersichtlich. Ich beschränke mich auf die wesentlichen Dinge. Klassenkommentar sollte nach meiner Meinung immer da sein. Nicht eindeutige Variablen und Methoden kommentiere ich.

Der Gegenfall:


/// <summary>
  /// class that represents a customer.
  /// </summary>
  class Customer
    {
    public Customer (string name )
      {
      Name = name;
      }

    public string Name { get; private set; }
    }

Gelöschter Account
vor 14 Jahren

ich würde es so machen:

/// <summary>
  /// This class represents a customer and stores all necessary informations
  /// </summary>
  class Customer
    {
    /// <summary>
    /// Initializes a new instance of the <see cref="Customer"/> class and sets the name property.
    /// </summary>
    /// <param name="name">the nickname of the customer</param>
    public Customer (string name )
      {
      Name = name;
      }

    /// <summary>
    /// Gets the nickname of the customer.
    /// </summary>    
    public string Name { get; private set; }
    } 
I
itstata Themenstarter:in
302 Beiträge seit 2008
vor 14 Jahren

Find ich alleine durch diese kleinen Änderungen bedeutend besser. Jetzt ist klar das die Klasse nur die Informationen kapselt.

Gelöschter Account
vor 14 Jahren

auch die tatsache, was genau mit name gemeint ist, ist in meinen augen wichtig. gerade bei ambivalenten bezeichnern ist is ungemein wichtig, diese mit kommentaren zu vervollständigen. bei name könnte man z.b. mehrere sachen erlauben. z.b. "could be familyname or the nickname but NOT the first name". so weiß der verwender genau, was er da reinstopfen soll, wenn er mehrere möglichkeiten hat, wie beim programmieren des anmeldeformulars.

I
itstata Themenstarter:in
302 Beiträge seit 2008
vor 14 Jahren

gut ist natürlich wenn man Name gar nicht verwenden muss.
Es gibt ja auch Variablennamen die noch schlimmer sind:
z.B. "Data" was alles und nichts sein kann.

M
334 Beiträge seit 2007
vor 14 Jahren

Ich finde, Kommentar ist hier das falsche Wort. Es sollte durch Dokumentation ersetzt werden, dann ist es sofort verständlich.

Sowas in der Art hier ist meiner Meinung nach total sinnlos. Es gibt hier nichts herausragendes, was dokumentiert werden sollte, denn jedem sollte klar sein wozu ein Konstruktor da ist.


/// <summary>
/// Initializes a new instance of the <see cref="Customer"/> class.
/// </summary>
public Customer ()
{
}

Das gleiche mit den "erzwungenen" Kommentaren bei ToString() oder Equals().

Das hingegen gehört für mich schon zur Dokumentation und ist absolut notwendig. Es zeigt den Sinn der Klasse, evtl. noch Beispiele zur Verwendung usw.


/// <summary>
/// This class represents a customer and stores all necessary information
/// </summary>
class Customer{
}

U
282 Beiträge seit 2008
vor 14 Jahren

Ist zwar schon ein wenig älter, will aber auch mal meinen Senf dazu geben.

Ich finde, das über 95% der Kommentare überflüssig sind.
XML-Kommentare finde ich als Nutzer einer API nur dann sinnvoll, wenn sie wirklich ausführlich geschrieben sind - was sind die Annahmen, was die Auswirkungen der Methode, welche Exceptions können geworfen werden. Meistens ist das aber offensichtlich.
Wenn ein Kommentar beschreiben muss, was eine Methode tut, ist die Methode falsch benannt.

Innerhalb des Codes sind nur sehr wenige Kommentare notwendig. Lieber mehr und sprechendere Methoden. Ich halte mich da recht Konsequent an "Clean Code" und finde seit dem auch alten Code wirklich gut lesbar.

Z.B. finde ich folgenden Vorschlag ein schönes Gegenbeispiel für die Nützlichkeit von Kommentaren:


/// <summary>
  /// This class represents a customer and stores all necessary informations
  /// </summary>
  class Customer
    {
    /// <summary>
    /// Initializes a new instance of the <see cref="Customer"/> class and sets the name property.
    /// </summary>
    /// <param name="name">the nickname of the customer</param>
    public Customer (string name )
      {
      Name = name;
      }

    /// <summary>
    /// Gets the nickname of the customer.
    /// </summary>    
    public string Name { get; private set; }
    }

Die Klassenbeschreibung ist redundant. Natürlich repräsentiert die Klasse Customer einen Customer. Und natürlich speichert sie alle Daten dazu, dass ist die Aufgabe einer Klasse.... Es müsste dokumentiert werden, wenn sie es nicht tut. Noch besser würde man dann die Klasse anders benennen.

Dann werden die Beiden Kommentare dazu verwendet, zu beschreiben, welcher Name gemeint ist.... Warum nenne ich nicht das Property direkt so?

Ich würde es (abgesehen von der leidigen Notwendigkeit der API-Doku) folgendermaßen machen:


class Customer
{
    public string NickName { get; private set; }

    public Customer (string nickName ) {
        NickName = nickName;
    }  
}

Wenn zu 85% die Kommentare von GhostDoc übernommen werden: Warum kann nicht der Kommentar automatisch in die API-Doku generiert werden, ohne den Code aufzublähen.

Denn dann würden Kommentare im Code als wichtig erkannt werden, weil sie etwas dokumentieren, was nicht selbstverständlich oder trivial ist.

Gelöschter Account
vor 14 Jahren

Wenn ein Kommentar beschreiben muss, was eine Methode tut, ist die Methode falsch benannt.

CCD guide. das ist überspitzt formuliert und jeder versteht unter einem bestimmten ausdruck etwas anderes. ein klarstellender kommentar ist da gold wert. vor allem wenn dann so eine methode ensteht:



public bool IsAidRidLidAddressingAllowed()

hier sind drei akronyme eingebaut. ausgeschrieben würden sie einem nicht steuerungsprogrammierer keine aussage geben, was damit gemeint ist und sie würden die 120 zeilen-code-marke brechen.

für leute, die sich in sterungssystemen auskennen, ist das eineindeutig. für apibenutzer, je nach kenntnissstand aussagekräftig.

ohne kommentar ist so eine methode meistens ein frustgenerator.

das das beispiel mit dem customer evtl nicht das allerbeste ist, kann ich gut verstehen aber ich vertrete die ansicht, das man besser alles kommentieren soll, als nichts.

gutes beispiel ist das .net framework. alles ist dokumentiert. egal ob trivial oder nicht. ich bin mir sicher das auch die trivialen sachen schon nachgeschlagen wurden. oft auch nur deswegen um sicher zu gehen, das die frameworkentwickler genau das selbe unter dem begriff verstehen wie einer selbst (und das lässt sich nur durch kommentare bewerkstelligen).

49.485 Beiträge seit 2005
vor 14 Jahren

Hallo Uwe81,

was sind die Annahmen, was die Auswirkungen der Methode, welche Exceptions können geworfen werden.

ja, das sehe ich genauso, aber meistens wird das leider nicht gemacht. Auch du hast es in deinem Beispiel trotz dieser deiner eigenen Forderung leider nicht gemacht. Darf bzw. kann NickName null sein? Darf bzw. kann NickName der leere String sein oder kann man sich darauf verlassen, dass ein Name gesetzt ist? Ist NickName eindeutig oder können mehrere Kunden den gleichen NickName haben? Das gehört alles in die Doku.

Natürlich sehe ich, wenn ich mir den Code anschaue, dass NickName auch null oder leer sein kann und nicht eindeutig sein muss, aber es geht ja um die API-Doku, die mir die Klasse verständlich machen soll, ohne dass ich in den Code gucken muss.

Meistens ist das aber offensichtlich.

Finde ich nicht. Es wird im Gegenteil leider viel zu oft davon ausgegangen, dass vieles offensichtlich ist, was es nicht ist, zumindest dann nicht, wenn man den Programmierstil des Implementiers nicht sehr gut kennt.

Hier mal ein Beispiel, was man über eine so einfache Klasse wie IndexedItemList <T> Klasse sinnvollerweise schreiben kann, wenn man ernsthaft vorhat, den Benutzer der Klasse umfassend zu informieren (und selbst da bin ich mir nicht sicher, dass ich nichts vergessen habe):

Zusammenfassung

Stellt eine stark typisierte Liste von Objekten (=Einträgen) dar, auf die über einen Index zugegriffen werden kann, wobei die Einträge ihren eigenen Index kennen.

Beschreibung

Diese Klasse erbt von System.Collections.ObjectModel.Collection <T> und stellt daher mehr Methoden zur Verfügung als hier beschrieben, inbesondere die Methoden, die durch IList implementiert sind: Add, Clear, Contains, IndexOf, Insert, Remove, RemoveAt. Die Beschreibung der zusätzlichen Methoden finden Sie in der MSDN-Dokumentation. Durch das Überschreiben von Methoden in dieser Klasse ändert sich das jedoch Verhalten der genannten Methoden gebenüber der Beschreibung in der MSDN. Deshalb sollte zusätzlich die Beschreibung der überschrieben Methoden in dieser Dokumentation konsultiert werden.

Die Einträge der Liste müssen das Interface IIndexedItem implementieren.

Auf Einträge in dieser Auflistung kann mit Hilfe eines ganzzahligen Index zugegriffen werden. Diese Auflistung verwendet nullbasierte Indizes.

Die Liste ist änderbar. Einen schreibgeschützten Wrapper, den Sie für diese Liste verwenden können, finden Sie unter ReadOnlyCollection <T> in der MSDN-Doku.

Die Liste stellt sicher, dass bei jeder Änderung an der Liste IIndexedItem.Index jedes Eintrags mit dem Index des Eintrags in der Liste übereinstimmt (vorausgesetzt IIndexedItem.IndexChanged ist korrekt implementiert). Andersherum stellt die Liste sicher, dass jede zulässige Änderung an IIndexedItem.Index den Eintrag innerhalb der Liste an den entsprechenden Index verschiebt.

Die Liste lehnt null als Wert für Verweistypen ab und lässt keine doppelten Einträge zu, auch nicht listenübergreifend. Ein Eintrag befindet sich also zu jedem Zeitpunkt in gar keiner oder in genau einer IndexedItemList.

Wird ein Eintrag in eine Liste hinzugefügt (Add/Insert/Set), in der er sich schon befindet, wird er von seiner bisherigen Position an die neue Position verschoben. Erfolgt die Verschiebung dabei von von einem niedrigeren zu einem höheren Index, ist der Index des Eintrags nach der Operation um eins niedriger als angegeben. Nach list.Insert (8, list [5]) hat der Eintrag den Index 7.

Wird ein Eintrag in eine Liste hinzugefügt (Add/Insert/Set), obwohl er sich schon in einer anderen IndexedItemList befindet, wird er aus der anderen Liste entfernt.

In dieser Klasse gibt drei Arten von Methoden:1.Die öffentlichen Action-Methoden (Move, Swap, ...)
Diese prüfen die Parameter und rufen die zugehörigen ActionItem-Methoden auf.

1.Die geschützten ActionItem(s)-Methoden (MoveItem, SwapItems, ...)

Diese können sich - bis auf die Prüfung von tItem auf null, die sie selbst durchführen - auf gültige Parameter und einen konsistenten Zustand verlassen. Sie verhindern einen möglichen rekursiven Aufruf durch den Setter von Index, ermitteln aufgrund des Zustandes, was genau zu tun ist und rufen dann die entsprechende ActionItem(s)Core-Methoden auf.

1.Die geschützten ActionItem(s)Core-Methoden (MoveItemCore, SwapItemsCore, ...)

Diese können sich auf gültige Parameter verlassen und darauf, dass der rekursive Aufruf durch den Setter von Index verhindert ist. Der Zustand des aktuellen Eintrags ist möglicherweise schon inkonsistent. Sie führen die eigentliche Aktion aus und tun dabei genau, was sie gesagt bekommen. Anschließend bringen sie den aktuellen Eintrag wieder in einen gültigen Zustand.

herbivore