Wieviele LOC für Funktion?

pumuckl

Bashar schrieb:

Eine einzigartige Applikationslogik in gleicher Weise auseinanderzustrahieren ist ungleich schwerer,

Ist eine Behauptung. Gegegenbehauptung: Ist nur dann schwerer wenn die Logik in schlechtem Design umgesetzt wird.

der Nutzen nicht unmittelbar einsichtig,

Wie stehts mit Lesbarkeit, Wartbarkeit, Verständlichkeit, Erweiterbarkeit? Ist das nicht Nutzen genug?

manchmal ist es sogar kontraproduktiv.

Definiere kontraproduktiv in dem Zusammenhang und zeig dann wo es kontraproduktiv sein soll. Ich stimme nur dann zu, wenn kontraproduktiv = "kurzfristig zeitaufwändiger (und langfristig interessiert nicht)"

volkard

manchmal. und vor allem sind die gewinne nicht unmittelbar ersichtlich, weshalb mans besser trotzdem tut.

Xebov

Shade Of Mine schrieb:

Xebovs Code wuerde zB sogar einen enormen Geschwindigkeitsvorteil bekommen...

Wieso würde der Code nen Geschwindigkeitsvorteil bekommen? Was spricht den gegen ein Struct zum lagern der Daten? Was hätte ich davon wenn ne Modelklasse die daten in ein Array legt und diese daten in enr eigenen klasse sind und somit alles was rein muß zu den datens elbst durch muß statt vond er Klasse direkt behandelt zu werden, das wäre ja doppelt gemoppelt.

Bashar

pumuckl schrieb:

Bashar schrieb:

Eine einzigartige Applikationslogik in gleicher Weise auseinanderzustrahieren ist ungleich schwerer,

Ist eine Behauptung. Gegegenbehauptung: Ist nur dann schwerer wenn die Logik in schlechtem Design umgesetzt wird.

Ich verstehe deine Gegenbehauptung nicht. Ein gutes Design zu finden ist nur schwer, wenn man es schlecht macht?

der Nutzen nicht unmittelbar einsichtig,

Wie stehts mit Lesbarkeit, Wartbarkeit, Verständlichkeit, Erweiterbarkeit? Ist das nicht Nutzen genug?

Doch, aber das bekommst du nicht automatisch. Dazu muss das Design nämlich auch gut sein. Den Code von Xebov kann man einfach von oben nach unten lesen und verstehen. Wenn du das ganze durch ein Klassenkonstrukt ersetzt, wird es erstmal komplizierter, es sei denn, du machst es wirklich richtig gut.

manchmal ist es sogar kontraproduktiv.

Definiere kontraproduktiv in dem Zusammenhang und zeig dann wo es kontraproduktiv sein soll. Ich stimme nur dann zu, wenn kontraproduktiv = "kurzfristig zeitaufwändiger (und langfristig interessiert nicht)"

Kontraproduktiv heißt, dass der Code schwerer verständlich und weniger wartbar wird.

pumuckl

Bashar schrieb:

Ich verstehe deine Gegenbehauptung nicht. Ein gutes Design zu finden ist nur schwer, wenn man es schlecht macht?

Nein. Ein gutes Design ist schwer zu finden wenn schon das übergeordnete Design schlecht ist.

Doch, aber das bekommst du nicht automatisch. Dazu muss das Design nämlich auch gut sein. Den Code von Xebov kann man einfach von oben nach unten lesen und verstehen. Wenn du das ganze durch ein Klassenkonstrukt ersetzt, wird es erstmal komplizierter, es sei denn, du machst es wirklich richtig gut.

Den Code von Xebov find ich alles andere als leicht zu lesen und zu verstehen. Die Funtkion erfüllt mehrere Aufgaben auf einmal, auf verschiedenen Abstraktionsebenen (von byteweise I/O bis zu den ModelParts) und benutzt zu allem Überfluss auch noch schlecht gewählte Namen (wenn ich ModelParts und Model lese, gehe ich davon aus, dass Model ein Modell ist, das aus modelParts besteht - es scheint sich aber um eine Datei zu handeln). Natürlich muss das Design gut sein damit man die Vorteile von sauberem Code nutzen kann. Aber ein gutes Design zu finden ist eben nicht so schwer wie einige behaupten.

Kontraproduktiv heißt, dass der Code schwerer verständlich und weniger wartbar wird.

Noch schwerer verständlich als ein Moloch von über 60 Zeilen wäre nur eine Funktion mit noch mehr Zeilen oder schlechter gewählten Variablennamen. Ich werd mich nachher zu Hause mal kurz dransetzen und versuchen zu skizzieren wie man die Funktion ein wenig lesbarer gestalten könnte.

Xebov

pumuckl schrieb:

Den Code von Xebov find ich alles andere als leicht zu lesen und zu verstehen. Die Funtkion erfüllt mehrere Aufgaben auf einmal, auf verschiedenen Abstraktionsebenen (von byteweise I/O bis zu den ModelParts) und benutzt zu allem Überfluss auch noch schlecht gewählte Namen (wenn ich ModelParts und Model lese, gehe ich davon aus, dass Model ein Modell ist, das aus modelParts besteht - es scheint sich aber um eine Datei zu handeln). Natürlich muss das Design gut sein damit man die Vorteile von sauberem Code nutzen kann. Aber ein gutes Design zu finden ist eben nicht so schwer wie einige behaupten.

Das leseproblem liegt nur daran das du die Klassenvariablen nicht kennst. Die Funktion ist von oben nach unten zu lesen, sie liest nur Daten ein und reicht sie ggf an die Richtige Stelle weiter, ich sehe da keine Stellen wo die Funktion nochetwas anderes tut als einlesen und weitergeben. Die Funktion liest aus einer Modelldatei die Modell-Teile ein. Deswegen heist die Datei auch Model. Leichte rweiterbar ist die Funktion auch, ich hab für den Dateitypen eine Kleine Dokumentation geschrieben in der steht was an welcher Stelle steht und in welchem Format.

Um dir noch etwas Überblick zu verschaffen wenn du dann selbst was Skizieren willst. Die Funktion ist Teil eienr Gruppe von Einlesefunktionen, die Klasse öffnet eine Modell-Datei als Model und fängt an einzulesen (das Dateidesign habe ich so gemacht das man sie ohne springen am Stück von oben nahc unten lesen kann) Sie liest aus der datei die Anzahl der Model-Teile aus (ModelParts) und erstellt ein Array eienr Struktur in richtiger Größe (ModelParts) dieses Struktur beinhaltet alle Details über den Modelteil, und diese Details werden in dieser Funktion nacheinander für jeden ModelPart eingelesen (die liegen auch in der Datei hintereinander)

volkard

pumuckl schrieb:

Den Code von Xebov find ich alles andere als leicht zu lesen und zu verstehen.

naja, echt schrecklich ist was anderes. der code geht so. und ist unreparierbar, außer man schmeißt verdammt viel weg. außerdem ist bei gamecoderz manches suboptimal, deaswegen liest sich der code auch ganz angenehm, weil man diese funktion und ihre vettern schon lange kennt. und wenn man's anders macht, entfernt man sich von der gemeinde, was beim gegenseitig-helfen wieder von nachteil ist.

unskilled

Das leseproblem liegt nur daran das du die Klassenvariablen nicht kennst

super - damit ist er wohl wartbar, wenn man erst alle klassenvariablen kennen muss, um den code zu verstehen? Oo

die Funktion nochetwas anderes tut als einlesen und weitergeben

also erfüllt sie nur eine aufgabe - oder doch mehrere?!

klar macht es ihn nicht zu furchtbar schlechtem code, den niemals mehr wieder irgendwer verstehen kann - aber es macht ihn nicht zu perfektem Code - und das man ihn übersichtlicher gestalten könnte, solltest du nun auch langsam mal glauben ^^

bb

Nexus

volkard schrieb:

und wenn man's anders macht, entfernt man sich von der gemeinde, was beim gegenseitig-helfen wieder von nachteil ist.

Das ist mal eine Legitimation.

Man kann übrigens auch beim Spiele-Programmieren versuchen, aufs Design zu achten. Bei dieser Art von Programmen, die unter Umständen besonders bug- und wartungsanfällig ist, kann sich das erst recht auszahlen. Manchmal ist sauberes Design eben nicht ganz einfach, besonders, wenn man faul ist und schnelle Resultate erzielen möchte. Es braucht relativ viel Erfahrung, bis man merkt, welche Strukturierung einem Vorteile in der Handhabung bringt und sich auch längerfristig bewährt...

unskilled schrieb:

aber es macht ihn nicht zu perfektem Code

Irgendwann kommt der Punkt der Entscheidung zwischen Aufwand für Design und Zweckmässigkeit der Applikation. Am Design kann man oft ewig weiterfeilen, bei komplexeren Problemen wird es immer mehrere Lösungen geben, und so richtig gefällt einem meist doch keine, egal, wie lange man schon daran gearbeitet hat.

Bashar

pumuckl schrieb:

Bashar schrieb:

Ich verstehe deine Gegenbehauptung nicht. Ein gutes Design zu finden ist nur schwer, wenn man es schlecht macht?

Nein. Ein gutes Design ist schwer zu finden wenn schon das übergeordnete Design schlecht ist.

Letzteres kann man in jedem größeren Projekt als gegeben annehmen, daher q.e.d.

Den Code von Xebov find ich alles andere als leicht zu lesen und zu verstehen. Die Funtkion erfüllt mehrere Aufgaben auf einmal, auf verschiedenen Abstraktionsebenen (von byteweise I/O bis zu den ModelParts) und benutzt zu allem Überfluss auch noch schlecht gewählte Namen (wenn ich ModelParts und Model lese, gehe ich davon aus, dass Model ein Modell ist, das aus modelParts besteht - es scheint sich aber um eine Datei zu handeln).

Die gewählten Namen könnten ein Problem sein, allerdings kein Designproblem. Dass die Funktion mehrere Aufgaben auf einmal erfüllt, ist nur dann ein Problem, wenn man diese Teilfunktionalitäten auch separat nutzen möchte. Dann muss man nämlich Code duplizieren. Ob das hier der Fall ist? Aber Wiederverwendbarkeit und Verständlichkeit sind zwei verschiedene Paar Schuh.
Verschiedene Abstraktionsebenen sind es, weil die Funktion die Schnittstelle zwischen zwei solchen bildet, sie konstruiert ja High-Level-Objekte aus Bytes.

Noch schwerer verständlich als ein Moloch von über 60 Zeilen wäre nur eine Funktion mit noch mehr Zeilen oder schlechter gewählten Variablennamen. Ich werd mich nachher zu Hause mal kurz dransetzen und versuchen zu skizzieren wie man die Funktion ein wenig lesbarer gestalten könnte.

Können wir die Variablennamen mal beiseite lassen? Mir geht es um Design, also etwas strukturelles. Und "lesbar" ist auch dehnbar. Mich interessieren konkrete Designprobleme.

Xebov

unskilled schrieb:

super - damit ist er wohl wartbar, wenn man erst alle klassenvariablen kennen muss, um den code zu verstehen? Oo

Nein man muß nicht alle kennen, aber du kannst ja nun auch keinen motor Reparieren wenn du nur 4 Schrauben davon kennst oder?

unskilled schrieb:

also erfüllt sie nur eine aufgabe - oder doch mehrere?!

Eine, Daten einlesen und an einigen Stellen werden sie weitergegeben wenn sie nicht direkt verwertbar sind.

unskilled

ok - du hast recht...

der rest ist dumm, hat keine ahnung oder naja.. ist einfach im unrecht...

hf

Xebov

unskilled schrieb:

ok - du hast recht...

der rest ist dumm, hat keine ahnung oder naja.. ist einfach im unrecht...

hf

Bist du jetzt beleidigt weil ich bei eienr Klassenfunktion vorraussetze das man dir Klassenvariablen zum Teil kennt und weil ich es nunmal als eine Aufgabe ansehe die Daten einzulesen und weiterzugeben?

Shade Of Mine

Xebov schrieb:

Wieso würde der Code nen Geschwindigkeitsvorteil bekommen?

Weil du dir den temporaeren Speicher sparen kannst den du dauernd per new anforderst. Je nachdem wieviel Daten du da hin und her schaufelst kann das relevante Vorteile bringen es einzusparen.

Was spricht den gegen ein Struct zum lagern der Daten?

Nichts, nur dass man dann eben auch noch einen Ctor definiert und uU named ctors um die Daten leichter initialisieren zu koennen.

Was hätte ich davon wenn ne Modelklasse die daten in ein Array legt und diese daten in enr eigenen klasse sind und somit alles was rein muß zu den datens elbst durch muß statt vond er Klasse direkt behandelt zu werden, das wäre ja doppelt gemoppelt.

Eine struct ist eine Klasse. Einer struct einen ctor und uU sinnvolle Methoden zu geben tut nicht weh. Zumindest der Ctor sollte sein. Da du zB bei deinem Code immer doppelte Initialisierungen hast. Das ist fehleranfaellig. Lieber die Daten gleich direkt initialisieren - das bringt nicht nur mehr lesbarkeit und oft mehr performance, sondern erleichtert auch die Wartbarkeit enorm.

Wie gesagt, das ganze etwas generischer aufbauen und vorallem von dem rohen lesen der Datei weggehen. Das waere der wichtigste Schritt. Der Rest kommt dann von alleine.

ob im nachhinein ein redesign sinn macht sei mal dahingestellt. meistens kostet refactoren zuviel zeit. aber wenn moeglich wuerde ich das design so frueh wie moeglich so schoen wie moeglich hinbekommen.

das bisschen zeit das man dadurch verliert ist irrelevant wenn man dann naemlich spaeter die anforderungen anpassen muss (was bei jedem groesseren projekt sowieso passiert) und dann hat man die zeit wieder drinnen. deshalb: wenn man die zeit hat, so gut designen wie irgend moeglich. gerade am anfang vom projekt ist genug zeit da - die laeuft erst gegen ende aus.

Tachyon

Xebov schrieb:

Nein man muß nicht alle kennen, aber du kannst ja nun auch keinen motor Reparieren wenn du nur 4 Schrauben davon kennst oder?

Nö, aber immerhin hat so ein Motor Schrauben. Deiner ist aus einem Stück gegossen und müsste weggeschmissen werden, wenn er kaputt ist.

pumuckl

die Funktion nochetwas anderes tut als einlesen und weitergeben

und temporäre dynamische Arrays verwalten und den Chunk verwalten (wozu auch immer der gut sein soll) und über das ganze Array iterieren...

Ich bin schon dabei, dauert noch bissl...
Wird auch noch keinesfalls zufriedenstellend, da ich die äußeren Gegebenheiten nicht kenne.

unskilled

Xebov schrieb:

Bist du jetzt beleidigt weil ich bei eienr Klassenfunktion vorraussetze das man dir Klassenvariablen zum Teil kennt und weil ich es nunmal als eine Aufgabe ansehe die Daten einzulesen und weiterzugeben?

ne - aber ist sinnlos, dir erklären zu wollen, dass deine Fkt eben mehr macht, als nur einwas und genau so sinnlos zu erklären, dass deine Fkt weder gut zu lesen (und damit wartbar) noch sonderlich performant ist.

Das haben dir jz schon mind. 4 versch. Leute gesagt und jedes Mal (gut) begründet - und alles, was du machst ist zu sagen, dass es doch gut ist, so wie du es machst...

Dazu kommt noch, dass die Fkt in deinen Augen jz super ist, obwohl du vor paar Tagen noch meintest (als die ersten Kritiken kamen), dass du sie ohnehin überarbeiten willst und sie nicht um sonst auf der Liste der zu überarbeiteten Dateien steht...

bb

Xebov

pumuckl schrieb:

und temporäre dynamische Arrays verwalten [...] und über das ganze Array iterieren...

An dieser Stelle kann ich dir leider nicht ganz folgen.

pumuckl schrieb:

den Chunk verwalten (wozu auch immer der gut sein soll)

Das ist ein Datenkopf, der enthält eine Identifikation und die größe der darunterliegenden Daten.

pumuckl schrieb:

Ich bin schon dabei, dauert noch bissl...
Wird auch noch keinesfalls zufriedenstellend, da ich die äußeren Gegebenheiten nicht kenne.

Macht nichts bin gespannt drauf.

unskilled schrieb:

dass deine Fkt eben mehr macht, als nur einwas und genau so sinnlos zu erklären, dass deine Fkt weder gut zu lesen (und damit wartbar) noch sonderlich performant ist.

Das sie nicht gerade das performanteste Stück Code ist hab ich ja nie angezweifelt. In Punkto Lesbarkeit und Wartbarkeit scheiden sich aber die Geister ganz eindeutig, Bashar zB konnte ihn lesen. Gewartet habe ich ihn selber auch schon, da er von oben nach unten die Datei abbildet lassen sich neue Teile einfach dazwischen einfügen.

unskilled schrieb:

Das haben dir jz schon mind. 4 versch. Leute gesagt und jedes Mal (gut) begründet - und alles, was du machst ist zu sagen, dass es doch gut ist, so wie du es machst...

Das sage ich garnicht, leider erschließt sich mir der Sinn einiger Argumente ganz und garnicht. Ich gebe da mal ein Beispiel. Shade bemängelt den Rohspeicher, er wird geholt, befüllt, an eine andere Klasse durchgereicht und dann wieder gelöscht. Nun ist aber die andere Klasse eine Standalone Vertexbuffer Klasse, die ist nicht allein für den Gebrauch im Model vorgesehen, um den Speicher aber wegzulassen müsste ich die Vertexbuffer Klasse um neue Funktionen erweitern, das hieße aber auch das ich jedesmal wenn ich ein neues Format für die Modelle unterstützen will auch die Vertexbuffer Klasse umbauen müsste obwohl sie eigentlich mit dem Model nichts zu tun hat.

Und genau hier kann ich der Argumentation nicht folgen weil sich das ganze dnan auf noch mehr Funktionen verteilen würde und man nichtmehr sagen kann das das die Modelklasse für alles zuständig ist.

unskilled schrieb:

Dazu kommt noch, dass die Fkt in deinen Augen jz super ist, obwohl du vor paar Tagen noch meintest (als die ersten Kritiken kamen), dass du sie ohnehin überarbeiten willst und sie nicht um sonst auf der Liste der zu überarbeiteten Dateien steht...

Sie wird ja auch überarbeitet, das ganze File Zeug kommt raus und einige einlese Vorgänge fasse ich zusammen. Aber vom Funktionsinhalt, also dem was sie im großen und ganzen tut sehe ich eben keine Probleme. Den Inhaltlich kann ich sagen die Funktion ließt die Datenblöcke für die Modelteile ein und sendet die eingelesenen Daten an die entsprechenden Datenmember.

pumuckl

So, eine erste Überarbeitung meinerseits. Mit einigen Stellen bin ich noch nicht glücklich, aber ich denke man kriegt einen gewissen Eindruck. Obwohl es mir in den Fingern gejuckt hat hab ich drauf verzichtet, Variablennamen zu ändern, z.B. Model -> ModelFile, die in meinen Augen unnötigen m_-Präfixe und die ungarische Notation (die evtl. sogar von einem Framework vorgegeben sein mag).

Die neuen Methoden für ModelPart sind nicht zwingend erforderlich, runden den einen oder anderen Aufruf in meinen Augen aber ab. Wenn ModelPart vom Framework vorgegeben ist, kann man entweder freie Funktionen definieren die ein ModelPart als Argument nehmen oder von ModelPart ableiten (da es ein struct ist sollte das wenig Probleme bereiten).

void getModelPart(ModelPart* modelPart);
void bfModel::ReadModelParts()
{
  for (int i=0; i <m_iNumModelParts; ++i)
  {
    getModelPart(m_pModelParts + i);
  }
}

struct ChunkReader //keine Ahnung was das ständige ReadChunk bringen soll, aber naja...
{
  bfChunk chunk;
  ChunkReader() : chunk() 
  { ZeroMemory(&chunk,sizeof(chunk); }

  void read() 
  { ReadChunk(chunk); }

  int getLastiID()
  { return chunk.iID; }
};

template <typename T> void getVar(T& var);
{
  fread_s(&var, sizeof(var), sizeof(var), 1, Model);
}

void getVertices(ModelPart* modelPart);
void getIndices(Modelpart* modelPart);

// Die Hauptfunktion - reicht um zu verstehen was im Groben passiert //
void getModelPart(ModelPart* modelPart)
{
  static ChunkReader chunkReader;
  chunkReader.read();
  chunkreader.read();
  getVar(modelPart->dVertexFormat);
  chunkreader.read();
  getVar(modelPart->iVertices);
  getVar(modelPart->dVertexSize);
  getVar(modelPart->fSphere);
  getVar(modelPart->MinBox);     //nehme an, dass MinBox vom Typ Box ist, sonst separate getBox() Funktion
  getVar(modelPart->MaxBox);
  getVertices(modelPart);
  chunkReader.read();

  getVar(modelPart->iIndices);
  getIndices(modelPart);

  chunkReader.read();
  if (chunkReader.getLastiID() != 0x4140)
  {
    stepBackOneIndex();
  }
  else
  {
    getVar(modelPart->iModelNumber);
    getVar(modelPart->vKoords);  //nehme an, dass vKoords vom eigenen Typ ist, sonst separate getKoords() Funktion
  }
}

void getVertices(ModelPart* modelPart)
{
  size_t bufferSize = modelPart->getVertexBufferSize();
  std::vector<BYTE> buffer(bufferSize);
  fread_s(&buffer[0], bufferSize, modelPart->dVertexSize, modelPart->iVertices, Model);

  modelPart->initVertexBuffer();  //s.u.
  modelPart->addVerticesToVertexBuffer(&buffer[0]);
  modelPart->updateVertexBuffer();
}

void getIndices(Modelpart* modelPart)
{
  size_t bufferSize = modelPart->getIndexBufferSize();
  std::vector<BYTE> buffer(bufferSize);
  fread_s(&buffer[0], bufferSize, 6, modelPart->iIndices, Model);

  modelPart->initIndexBuffer();
  modelPart->addIndicesToIndexBuffer(&buffer[0]);
  modelPart->updateIndexBuffer();

}

//Zusätzliche ModelPart-Methoden

size_t ModelPart::getVertexBufferSize()
{
  return dVertexSize*iVertices;
}

void ModelPart::initVertexBuffer()
{
  VertexBuffer.Init(getVertexBufferSize(), dVertexSize, dVertexFormat);
}

void ModelPart::addVerticesToVertexBuffer(BYTE* source)
{
  VertexBuffer.AddVertices(iVertices, source);
}

void ModelPart::updateVertexBuffer()
{
  VertexBuffer.Update();
}

void ModelPart::initIdexBuffer()
{
  IndexBuffer.Init(iIndices*6, 6);
}

size_t ModelPart::getIndexBufferSize()
{
  return 6*iIndices;
}
void ModelPart::updateIndexBuffer()
{
  IndexBuffer.Update();
}
void ModelPart::addIndicesToIndexBuffer(BYTE* source)
{
  IndexBuffer.AddIndices(iIndices, source);
}

/edit: eine vergessen:

void stepBackOneIndex()
{
  fseek(Model,-6,SEEK_CUR);
}

Xebov

Interessante Sache, du hast die Funktion total Zerlegt.

Ich gebe dir mal noch die Sachen die aus dem ersten ersten Code von mir nicht ersichtlich waren:

//Das Struct auf dem der ModelPart basiert
struct bfModelPart
{
	DWORD dVertexFormat;
	int iVertices;
	int iIndices;
	DWORD dVertexSize;
	bfIndexBuffer IndexBuffer;
	bfVertexBuffer VertexBuffer;
	bfVector3 MinBox;
	bfVector3 MaxBox;
	float fSphere;
	int iModelNumber;
	bfVector3 vKoords;
};
//Der Chunck Struct
struct bfChunk
{
	unsigned short iID;
	unsigned int iChunkSize;
	int iBytesRead;
};
//Die Relevanten Klassenvariablen
        FILE *Model;
	int m_iNumModelParts;
	bfModelPart *m_pModelParts;//Modeleinzellteile
//Read und SkipChunk
        void ReadChunk(bfChunk &chunk)
	{
		fread_s(&chunk.iID,2,2,1,Model);
		fread_s(&chunk.iChunkSize,4,4,1,Model);
		chunk.iBytesRead=6;
	};
	void SkipChunk(bfChunk &chunk)
	{
		fseek(Model,chunk.iChunkSize-chunk.iBytesRead,SEEK_CUR);
	};

Was es mit dem ReadChunk auf sich hat, die Datei ist Binär und hat einen Kopf unter dem die Größe steht, ReadChunk liest die nächsten 6Bytes aus. Die Funktion kann dann schauen welcher Teil dort steht, das macht es fürs erweiternd er Datei besodners Leicht weil man die Reihenfolge der Daten nur bedingt beachten muß. Die abfrage siehst du ind er Funktion nicht, aber die Zugehörige Mutterfunktion prüft die Daten, die Unterfunktion tut es (noch) nicht. Das ganze ist im Grunde nur Mittel zur Prüfung.