Drehmatrix Kreuzprodukt Vektor

[j4nk3y]

Salve zusammen,

Ich hab Heute an einem kleinen Versuch gearbeitet um einen Vektor um alle 3 Achsen zu drehen, sprich Kreuzprodukt mit den diversen Drehmatritzen. Dafür hab ich eine kleine Funktion geschrieben, welche mir aber ein komisches Ergebnis zurück gibt.

function vectorRotationXYZ($vector, $beta, $gamma, $delta)
{
	$rotation_XYZ = [
	"rotX" => [ "x" => ["x" => 1, 	"y" => 0, 	   "z" => 0 ] ,
		    "y" => ["x" => 0,   "y" => cos($beta), "z" => -sin($beta) ] , 
		    "z" => ["x" => 0, 	"y" => sin($beta), "z" => cos($beta) ]],
	"rotY" => [ "x" => ["x" => cos($gamma),	"y" => 0, "z" => sin($gamma) ] ,
		    "y" => ["x" => 0, 		"y" => 1, "z" => 0 ] , 
		    "z" => ["x" => -sin($gamma),"y" => 0, "z" => cos($gamma) ]],
	"rotZ" => [ "x" => ["x" => cos($delta), "y" => -sin($delta), 	"z" => 0 ] ,
		    "y" => ["x" => sin($delta), "y" => cos($delta), 	"z" => 0 ] , 
		    "z" => ["x" => 0, 		"y" => 0, 		"z" => 1 ]]
	];
	
	$result_vector = ["x" => 0, "y" => 0, "z" => 0];
	
	foreach($rotation_XYZ as $rotation_matrix)
	{
		foreach($rotation_matrix as $row_key => $matrix_row)
		{
			foreach($matrix_row as $multiplicator_key => $multiplicator)
			{
			     $result_vector[$row_key] += $multiplicator * $vector[$multiplicator_key];
			}
		}
	}
	
	return $result_vector;
}

$vector ist ein Array mit x,y,z und beta, gamma, delta, die Winkel der Neigungen der Achsen X, Y, Z. Problem ist nun folgendes, wenn ich einen Vektor habe und diesen durch die Funktion jage, dann wird dieser länger als der Ursprungsvektor und ich sehe nicht an welcher Stelle dies geschieht.

Sieht jemand vielleicht mehr als ich?

Danke und Gruß
Jo

[j4nk3y]

Hey,

Oh man... da fällt es mir wie Schuppen von den Augen... Tut mir leid. (für die 2te und dritte Rotationsmatrix muss der $result_vector verrechnet werden)

Gruß
Jo

[Gunnar Bittersmann]

@@j4nk3y

Ich hab Heute an einem kleinen Versuch gearbeitet um einen Vektor um alle 3 Achsen zu drehen, sprich Kreuzprodukt mit den diversen Drehmatritzen.

Nein. Sprich: Matrixprodukt.

Das Kreuzprodukt ist was ganz anderes.

LLAP 🖖

[j4nk3y]

Guten Morgen Gunnar Bittersmann,

Nein. Sprich: Matrixprodukt.

Das Kreuzprodukt ist was ganz anderes.

Richtig, mein Fehler.

So kleines Update:

function vectorRotationXYZ($vector, $beta, $gamma, $delta)
{
	$rotation_XYZ = [
	"rotX" => [ "x" => ["x" => 1, 		"y" => 0, 		"z" => 0 ] ,
		    "y" => ["x" => 0, 		"y" => cos($beta), 	"z" => -sin($beta) ] , 
		    "z" => ["x" => 0, 		"y" => sin($beta), 	"z" => cos($beta) ]],
	"rotY" => [ "x" => ["x" => cos($gamma), "y" => 0, 		"z" => sin($gamma) ] ,
		    "y" => ["x" => 0, 		"y" => 1, 		"z" => 0 ] , 
		    "z" => ["x" => -sin($gamma),"y" => 0, 		"z" => cos($gamma) ]],
	"rotZ" => [ "x" => ["x" => cos($delta), "y" => -sin($delta), 	"z" => 0 ] ,
		    "y" => ["x" => sin($delta), "y" => cos($delta), 	"z" => 0 ] , 
		    "z" => ["x" => 0, 		"y" => 0, 		"z" => 1 ]]
	];
	
	$result_vector = $vector;
	$interim_result_vector = ["x" => 0, "y" => 0, "z" => 0];
	
	foreach($rotation_XYZ as $matrix => $rotation_matrix)
	{
	  foreach($rotation_matrix as $row_key => $matrix_row)
	  {
	     foreach($matrix_row as $multiplicator_key => $multiplicator)
	     {
	      $interim_result_vector[$row_key] += $multiplicator * $result_vector[$multiplicator_key];
	     }
	  }
	  $result_vector = $interim_result_vector;
	  $interim_result_vector = ["x" => 0, "y" => 0, "z" => 0];
	}
	
	return $result_vector;
}

Ich muss sagen ich finde die Umsetzung sehr Elegant.

Gruß
Jo

[pl]

Eine Anmerkung zum Einrücken:

{
 ...
}

Die Klammern stehen zwar schön untereinander und manifestieren so ihre Zusammengehörikeit. Nicht gut ersichtlich jedoch ist, was bzw. welche Zeile zur öffnenden Klammer gehört (function, foreach, if, while...).

Genau dieses Problem löst der Stil nach Java/Sun:

function asdf(){
 ...
}

Und so auch einst in SELHTML kommuniziert. Von allen Einrückungsstils finde ich Java/Sun als denjenigen der am Besten lesbar ist.

Schönes Wochenende!

[j4nk3y]

Hey,

Genau dieses Problem löst der Stil nach Java/Sun:

function asdf(){
 ...
}

Und so auch einst in SELHTML kommuniziert. Von allen Einrückungsstils finde ich Java/Sun als denjenigen der am Besten lesbar ist.

So mach ich es auch wenn ich Javascript schreibe, PHP schreibe ich bis jetzt noch so wie oben. Ich hab mich noch nicht entscheiden was ich besser finde.

Gruß
Jo

[pl]

Entscheide Dich ;)

Java/Sun auch für PHP ;)

Vor allem bei der Suche korrespondierender Klammern -- was jeder Editor unterstützt -- ist der Stil Java/Sun sehr hilfreich.

Schöne Grüße ;)

[Gunnar Bittersmann]

@@pl

Entscheide Dich ;)

Java/Sun auch für PHP ;)

Allman-Stil auch für PHP. Wie auch für JavaScript und CSS.

Vor allem bei der Suche korrespondierender Klammern -- was jeder Editor unterstützt -- ist der Stil Java/Sun sehr hilfreich.

Bei Allman-Stil muss man da nicht lange suchen. Außerdem ist das Aufblinken der zugehörigen Klammer im Editor von Einrückungsstil völlig unabhängig; hier also kein Argument.

LLAP 🖖

[Gunnar Bittersmann]

@@pl

Eine Anmerkung zum Einrücken:

{
 ...
}

Die Klammern stehen zwar schön untereinander und manifestieren so ihre Zusammengehörikeit. Nicht gut ersichtlich jedoch ist, was bzw. welche Zeile zur öffnenden Klammer gehört (function, foreach, if, while...).

Doch, auch das ist sehr gut ersichtlich: Die öffnende Klammer { steht genau unter dem Schlüsselwort.

Wie im Beispiel:

	foreach($rotation_XYZ as $matrix => $rotation_matrix)
	{
	  foreach($rotation_matrix as $row_key => $matrix_row)
	  {
	     foreach($matrix_row as $multiplicator_key => $multiplicator)
	     {
	      $interim_result_vector[$row_key] += $multiplicator * $result_vector[$multiplicator_key];
	     }
	  }
	  $result_vector = $interim_result_vector;
	  $interim_result_vector = ["x" => 0, "y" => 0, "z" => 0];
	}

Wenn die öffnende Klammer { in einer eigenen Zeile steht, wird außerdem die Lesbarkeit dadurch verbessert, dass zwischen dem Schleifenkopf / der Bedingung / [wie heißt das bei Funktionsdeklarationen?] und dem Block Leerraum ist.

Das nennt sich Allman-Stil (in der englischen Wikipedia) und ist mein bevorzugter Coding-Stil – in an C-Syntax angelehnte Programmiersprachen wie auch in CSS.

Von allen Einrückungsstils finde ich Java/Sun als denjenigen der am Besten lesbar ist.

Ich nicht. Weil man nicht zu räumliche Zuordnung von { zu } hat und weil der Code so aneinandergeklatscht ist.

LLAP 🖖

[pl]

Doch, auch das ist sehr gut ersichtlich: Die öffnende Klammer { steht genau unter dem Schlüsselwort.

Genau das ist das Problem:

while
   {

 }

Wie Du sehen kannst, steht die öffnende Klammer genau unter dem Schlüsselwort. Aber genau ist eben nicht genau weil es bei while 5 Möglichkeiten gibt, eine Klammer darunter zu platzieren.

MfG

[Gunnar Bittersmann]

@@pl

while
   {

 }

Wie Du sehen kannst, steht die öffnende Klammer genau unter dem Schlüsselwort. Aber genau ist eben nicht genau weil es bei while 5 Möglichkeiten gibt, eine Klammer darunter zu platzieren.

Du schreibst Unsinn. Die öffnende Klammer { steht natürlich vorne – unter dem w. Genau wie die schließenden Klammer } auch.

LLAP 🖖

[Matthias Apsel]

Hallo pl,

while
   {

 }

Wie Du sehen kannst, steht die öffnende Klammer genau unter dem Schlüsselwort. Aber genau ist eben nicht genau weil es bei while 5 Möglichkeiten gibt, eine Klammer darunter zu platzieren.

Du weißt genau, dass „genau unter dem Schlüsselwort“ genau unter dem ersten Zeichen des Schlüsselwortes meint.

Aber, da der Gunnar auch immer sehr auf sprachliche Ungenauigkeiten achtet, darfst du das natürlich auch tun.

Im Übrigen bin ich sicher, dass es keine wirklich sachlichen Argumente für oder wider bestimmter etablierter Einrückungsstile gibt.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Im Übrigen bin ich sicher, dass es keine wirklich sachlichen Argumente für oder wider bestimmter etablierter Einrückungsstile gibt.

Nicht? Ich würde „öffnende und schließende Klammer untereinander“ und „bessere Lesbarkeit durch Leerraum“ schon sachliche Argumente nennen.

Dafür, die schließende Klammer hintendranzuklatschen, fällt mir aber kein Argument ein – außer „Ha’m wa immer schon so gemacht“ und „Machen andere auch so“; aber das sind eher keine sachlichen Argumente.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Im Übrigen bin ich sicher, dass es keine wirklich sachlichen Argumente für oder wider bestimmter etablierter Einrückungsstile gibt.

Nicht? Ich würde „öffnende und schließende Klammer untereinander“ und „bessere Lesbarkeit durch Leerraum“ schon sachliche Argumente nennen.

Ich in dem Fall Geschmackssache und persönliche Vorlieben.

Bis demnächst
Matthias

[Orlok]

Hallo Gunnar

Dafür, die schließende Klammer hintendranzuklatschen, fällt mir aber kein Argument ein

Mir schon. Für mich transportiert die öffnende Klammer am Zeilenende eine wichtige Information, nämlich dass der von ihr eingeleitete Block mit dem Code vor der Klammer inhaltlich verknüpft ist.

{
  console.log(message);
}

Schreibe ich die öffnende Klammer hingegen wie in dem Beispiel oben in die nächste Zeile, dann könnte das ohne Ansicht der darüberstehenden Zeilen, je nach dem um welche Sprache es sich handelt, auch ein eigenständiges Block Statement sein.

function print (message) {

Die öffnende Klammer am Zeilenende zeigt mir auf den ersten Blick, dass die Anweisung in der nächsten Zeile fortgesetzt wird, sprich, die einzelnen syntaktischen Elemente in einem Zusammenhang stehen.

Ich würde „öffnende und schließende Klammer untereinander“ und „bessere Lesbarkeit durch Leerraum“ schon sachliche Argumente nennen.

Würde ich auch. Die Frage ist eben, wieviel Gewicht man ihnen beimisst.

Dass öffnende und schließende Klammer untereinander stehen finde ich durchaus ästhetisch, aber es verschlechtert – zumindest für mich – aus dem oben genannten Grund die Lesbarkeit.

Und was den Leerraum angeht, könnte man bei Bedarf den Inhalt des Blocks auch einfach in Leerzeilen einbetten. Da ist die entsprechende Positionierung der Klammer also keine notwendige Voraussetzung für das Erreichen des Ziels.

Letztlich ist die Frage, welche Variante besser lesbar ist, meiner Ansicht nach nicht allgemeingültig zu beantworten, da die Wahrnehmung von Mensch zu Mensch verschieden ist. Worin ich im Übrigen auch kein Problem sehe, sondern eine Bereicherung.

Gruß,

Orlok

[Gunnar Bittersmann]

@@Orlok

Dafür, die schließende Klammer hintendranzuklatschen, fällt mir aber kein Argument ein

Mir schon. Für mich transportiert die öffnende Klammer am Zeilenende eine wichtige Information, nämlich dass der von ihr eingeleitete Block mit dem Code vor der Klammer inhaltlich verknüpft ist.

Das ist mal ein Argument, das sich von „machen doch alle™️ so“ abhebt.

Wenngleich die Verknüpfung für mich auch die öffnende Klammer in einer eigenen Zeile übernimmt:

foo

bar
{
  baz
}

quz

Zwischen foo und bar ist nur Leeraum; sie sind nicht verknüpft.

bar und baz werden durch { verknüpft.

baz und quz sind nicht verknüpft, weil nach } wieder trennender Leerraum kommt.

Das muss nicht immer so sein; so ist bspw. der ELSE-Zweig mit der IF-Abfrage verknüpft:

IF irgendwie
{
  mach was
}
ELSE
{
  mach was anderes
}

Dass öffnende und schließende Klammer untereinander stehen finde ich durchaus ästhetisch, aber es verschlechtert – zumindest für mich – aus dem oben genannten Grund die Lesbarkeit.

Und was den Leerraum angeht, könnte man bei Bedarf den Inhalt des Blocks auch einfach in Leerzeilen einbetten.

Dann hat man aber gerade eben eine Trennung, wo man leine haben will. Ich finde { als Bindeglied in der Zwischenzeile da besser als eine Klammer irgendwo am Zeilenende.

LLAP 🖖

[Emil S]

Hallo Matthias Apsel,

Im Übrigen bin ich sicher, dass es keine wirklich sachlichen Argumente für oder wider bestimmter etablierter Einrückungsstile gibt.

Doch! Die gibt es! Siehe z.B. Wikipedia. Es gibt sachliche Argumente und alle Stile haben Vorteile und Nachteile. Aus den sachlichen Argumenten lässt sich aber nicht bestimmen welcher der einzige richtige Stil ist.

Emil

[Matthias Apsel]

Hallo Emil S,

Doch! Die gibt es! Siehe z.B. Wikipedia. Es gibt sachliche Argumente und alle Stile haben Vorteile und Nachteile. Aus den sachlichen Argumenten lässt sich aber nicht bestimmen welcher der einzige richtige Stil ist.

Genau so.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Emil S

Doch! Die gibt es! Siehe z.B. Wikipedia.

Wobei es dort auch Scheinargumente gibt: „Als nachteilig wird von manchen Programmierern angesehen, dass dieser [Allman]-Stil einen hohen Zeilenverbrauch hat.“ Warum sollte nachteilig sein? Sind wir denn 1984, wo nur 24 Zeilen auf den Bildschirm passen?

Wenn man eine Funktion nicht in ihrer Gesamtheit auf dem Schirm hat (no pun intended), ist das sicher schlechter Stil. Aber nicht schlechter Einrückungsstil, sondern schlechter Programmierstil: die Funktion ist zu lang, sie macht zu viel.

Und natürlich sind wir „1984“, aber das ist ein anderes Thema.

LLAP 🖖

[TS]

Hello Gunnar,

Wobei es dort auch Scheinargumente gibt: „Als nachteilig wird von manchen Programmierern angesehen, dass dieser [Allman]-Stil einen hohen Zeilenverbrauch hat.“ Warum sollte nachteilig sein? Sind wir denn 1984, wo nur 24 Zeilen auf den Bildschirm passen?

Der Allman-Style nebst expliziter Formulierung ist das einzig Wahre ;-P

Wenn man eine Funktion nicht in ihrer Gesamtheit auf dem Schirm hat (no pun intended), ist das sicher schlechter Stil. Aber nicht schlechter Einrückungsstil, sondern schlechter Programmierstil: die Funktion ist zu lang, sie macht zu viel.

Und natürlich sind wir „1984“, aber das ist ein anderes Thema.

Das kann man wohl genauso schlecht sehen wie OderGut.

Liebe Grüße
Tom S.

[Emil S]

@@Gunnar Bittermann

Doch! Die gibt es! Siehe z.B. Wikipedia.

Wobei es dort auch Scheinargumente gibt: „Als nachteilig wird von manchen Programmierern angesehen, dass dieser [Allman]-Stil einen hohen Zeilenverbrauch hat.“ Warum sollte nachteilig sein? Sind wir denn 1984, wo nur 24 Zeilen auf den Bildschirm passen?

1. ist das kein Scheinargument. Man sieht sachlich das der Stil mehr Zeilen als andere andere verbraucht. 2. sagt Wikipedia das das manche Programmierer so sehen und nicht alle und man unterschiedlicher Meinung sein kann. Falsch istdas aber nicht. 3. siehe unten

Wenn man eine Funktion nicht in ihrer Gesamtheit auf dem Schirm hat (no pun intended), ist das sicher schlechter Stil. Aber nicht schlechter Einrückungsstil, sondern schlechter Programmierstil: die Funktion ist zu lang, sie macht zu viel.

Das ist quatsch so wie du das da schreibst. Das würde heißen die gleiche Funktion je nachdem was fürn Bildschirm ich hab einmal gut ist und einmal nicht. Wir sind im Jahr 2017! Da gibt es nicht nur eine Bildschirmgrösse. Und Monitore kann man hoch und quer stellen. Bist du auch einer von denen die immer px benutzen? Ich versteh das nicht. Eine Funktion muss 1. gut lesbar sein und das auch andere die Funktion verstehen. 2. muss eine Funktion genau eine Aufgabe machen. Egal wie lang die ist. Außer man kann die Funktion in Unteraufgaben aufteilen.

Emil

[TS]

Hello Emil,

wo sind deine Detektive?

Wenn man eine Funktion nicht in ihrer Gesamtheit auf dem Schirm hat (no pun intended), ist das sicher schlechter Stil. Aber nicht schlechter Einrückungsstil, sondern schlechter Programmierstil: die Funktion ist zu lang, sie macht zu viel.

Das ist quatsch so wie du das da schreibst. Das würde heißen die gleiche Funktion je nachdem was fürn Bildschirm ich hab einmal gut ist und einmal nicht. Wir sind im Jahr 2017! Da gibt es nicht nur eine Bildschirmgrösse. Und Monitore kann man hoch und quer stellen. Bist du auch einer von denen die immer px benutzen? Ich versteh das nicht. Eine Funktion muss 1. gut lesbar sein und das auch andere die Funktion verstehen. 2. muss eine Funktion genau eine Aufgabe machen. Egal wie lang die ist. Außer man kann die Funktion in Unteraufgaben aufteilen.

Wir (ich zumindest) wollen hier mal annehmen, dass Gunnar das nicht wörtlich gemeint hat. Selbstverständlich kann eine Funktion, selbst (oder gerade?) in Assembler programmierte, mehrere Bildschirmseiten beanspruchen. Sie sollte aber immer so klar verständlich geschrieben sein, dass man sie lesen kann, wie ein Buch. Das war nämlich der Schritt von "Goto" zu strukturierter Programmierung. Und ja! Auch in MASM ging das schon, dass man rechtzeitig "SUBs" definiert hat, anstatt Spaghetti zu programmieren.

Kommentare sollten nicht dafür benötigt werden, welche Syntaxauflösung der Programmierer erwartet hat, sondern welche Eingangsparameter zu welchen Ausgaben der Funktionen und Methoden führen sollen.

Wenn man nun aber noch eine kryptrische Kurzsschreibweise verwendet, dann muss man als Programmierer genaugenommen die Funktion auch nochmal im PseudoCode + Klartext erläutern. Da versende ich doch lieber den expliziten Stil umd Allman für die Formatierung. Dann kann ich mir nämlich 60-80% der Kommentare sparen.

Dass die notwwendigen Kommentare trotzdem auch beim "Ich-bin-der-Größte-Kurzschreibstil" nicht enthalten sind, führt in gut geführten IT-Teams regelmäßig zur Entlassung des "Cracks", oder aber zur Einstellung bei der Diesel-Gate-AG oder der NSA...

Liebe Grüße
Tom S.

[Klawischnigg]

Hi there,

Wenn man eine Funktion nicht in ihrer Gesamtheit auf dem Schirm hat (no pun intended), ist das sicher schlechter Stil. Aber nicht schlechter Einrückungsstil, sondern schlechter Programmierstil: die Funktion ist zu lang, sie macht zu viel.

Sorry Gunnar, aber das ist mit die bescheuertste Behauptung, die ich je in diesem Zusammenhang gelesen habe. Die "Länge" einer Funktion ergibt sich einfach aus Umfang ihrer nötigen Operationen (um nicht sagen zu müssen, die Länge einer Funktion ergibt sich aus ihrer Funktion;) und nicht aus den Vorstellungen von Herrn Bittersmann. Wenn Du schon meinst, Haltungsnoten für's Programmieren verteilen zu müssen, dann bitte nicht auf die B-Note vergessen.

Form follows auch hier Function - ich stell mir grad vor, wie sich jemand, der auf diese absurde Behauptung etwas gibt, den Kopf zerbricht, weil er plötzlich bemerkt, daß in seinem Programm zwar alles funktioniert, aber der Herr Bittersmann gesagt hat, daß Funktionen ja nie so lang sein dürfen wie die, die er gerade in seinem funktionierenden Programm fabriziert hat - und mir wird schlecht dabei...

[Rolf b]

Bevor Du weiter rumrotzt, lies Dir mal "Clean Code" von Robert Martin durch.

Die Maxime heißt "Do just one thing", und das ist keine Frage der schönen Optik, sondern von Wiederverwendbarkeit und Testbarkeit. Die Methode von Jo verletzt das trotz ihrer Kürze bereits ziemlich - was zu einem enormen Performance-Impact führt. Sie implementiert drei Dinge:

1. Generieren von Rotationsmatrizen um die X-, Y- und Z-Achse. Dafür sollte man 3 eigene Funktionen bereitstellen
2. Berechnen des Produkts von zwei Matrizen - eigene Funktion, bitte.
3. Berechnen des Produkts von einer Matrix mit einem Vektor. Sollte eine eigene Funktion sein, oder man fasst den Vektor als 3x1 Matrix auf und verwendet die Funktion aus Nr. 2.

D.h. man baut Helper wie build_rotX, build_rotY, build_rotZ, mat_multiply und linear_transform und benutzt sie so:

$rxy = mat_multiply(build_rotX($beta), build_rotY($gamma));
$rxyz = mat_multiply($rxy, build_rotZ($delta));

$vRot = linear_transform($rxyz, $vec);

und spätestens jetzt merkt man, dass die Berechnung von $rxyz unabhängig ist von der linearen Transformation von $vec, d.h. wenn man nicht nur einen Vektor transformieren will, sondern hundert, kann man durch diese Aufteilung enorm Zeit sparen.

Ein Tipp noch: Matrizen können außer Rotation auch noch Skalieren und Scheren. Und wenn deine Transformationsmatrizen vierdimensional sind, können sie auch noch verschieben! Allerdings hast Du dann doppelten Rechenaufwand (16 Koeffizienten statt 9, und jeder Koeffizient berechnet sich aus 4 statt 3 Produkten).

Rolf

[Klawischnigg]

Hi there,

Bevor Du weiter rumrotzt, lies Dir mal "Clean Code" von Robert Martin durch.

Erstens ersuche ich Dich um eine andere Ausdrucksweise und zweitens werden aus groben Verallgemeinerungen auch bei Fragen des Programmierstils keine in Stein gemeisselten Wahrheiten, auch und besonders ungeachtet dessen, was irgendjemand darüber geschrieben haben mag.

Für den Programmierer ist es im worst case letztlich doppelt egal, ob er sich in einer Funktion verliert oder in einer Unzahl von Funktionen. Vor allem aber ist das Thema viel zu komplex und vielschichtig, um mit einem scheinbar pädagogisch wertvollem, in Wahrheit aber nur plakativem "...die Funktion ist viel zu lang..." abgehandelt werden zu können…

[Christian Kruse]

Hallo Klawischnigg,

Bevor Du weiter rumrotzt, lies Dir mal "Clean Code" von Robert Martin durch.

Erstens ersuche ich Dich um eine andere Ausdrucksweise

Wie man in den Wald hinein ruft…

und zweitens werden aus groben Verallgemeinerungen auch bei Fragen des Programmierstils keine in Stein gemeisselten Wahrheiten, auch und besonders ungeachtet dessen, was irgendjemand darüber geschrieben haben mag.

Das ist zwar prinzipiell richtig, aber in diesem Fall nicht zutreffend. Ist eine Funktion zu lang, hat man unzureichend und/oder schlecht modularisiert.

Für den Programmierer ist es im worst case letztlich doppelt egal, ob er sich in einer Funktion verliert oder in einer Unzahl von Funktionen.

Der Umkehrschluss ist unzulässig. Nur weil lange Funktionen schlechter Code sind heisst das nicht, dass alle kurzen Funktionen guter Code sind.

Vor allem aber ist das Thema viel zu komplex und vielschichtig, um mit einem scheinbar pädagogisch wertvollem, in Wahrheit aber nur plakativem "...die Funktion ist viel zu lang..." abgehandelt werden zu können…

Gut, dass Gunnar das nicht getan hat. Der hat nämlich nur gesagt, dass eine zu lange Funktion schlechter Stil ist. Und da stimme ich ihm 100% zu, und deine Argumentation „das ist zu simpel, die Wirklichkeit ist komplexer” zieht nicht: es ist ja gerade die Aufgabe eines Entwickler, die Wirklichkeit in handliche Stücke herunter zu brechen.

Du bist aber herzlich eingeladen, ein Beispiel zu liefern, bei dem du der Meinung bist, die Funktion habe so groß zu sein.

LG,
CK

[Klawischnigg]

Hi there,

Wie man in den Wald hinein ruft…

Aha? Und was bitte hab' ich in den Wald gerufen? Hab' ich einen Fehler gemacht, weil ich die Meinung des Herrn Bittersmann kritisiert habe? Ein crimen laesae maiestatis? Kein Wunder, daß sich in diesem Forum nur mehr die immer wieder gleichen Leute herumtreiben.

Du bist aber herzlich eingeladen, ein Beispiel zu liefern, bei dem du der Meinung bist, die Funktion habe so groß zu sein.

Dafür kann es kein Beispiel geben. Der Ansatz, die Größe oder Länge einer Funktion vorgeben zu wollen, ist bereits falsch...

[Christian Kruse]

Hallo Klawischnigg,

Wie man in den Wald hinein ruft…

Aha? Und was bitte hab' ich in den Wald gerufen?

Lies dir doch dein Posting an Gunnar nochmal genau durch.

Hab' ich einen Fehler gemacht, weil ich die Meinung des Herrn Bittersmann kritisiert habe?

Nö, das darfst du gerne tun, das tue ich oft genug auch. Ich sehe so viele Sachen anders als er.

Du bist aber herzlich eingeladen, ein Beispiel zu liefern, bei dem du der Meinung bist, die Funktion habe so groß zu sein.

Dafür kann es kein Beispiel geben.

Sag ich ja…

Der Ansatz, die Größe oder Länge einer Funktion vorgeben zu wollen, ist bereits falsch...

Das sehen die meisten anderen Entwickler nicht so wie du. Das geht sogar soweit, dass Style Guides eine Maximal-Länge von Funktionen vorschreiben.

LG,
CK

[Rolf b]

Für den "Rotz" werde ich mich nicht entschuldigen, deine Ausdrucksweise gegenüber Gunnar war genau das.

Abgesehen davon hast Du natürlich nicht ganz unrecht, ob eine Funktion "zu lang" ist, wird nicht von ihrem Platzverbrauch auf dem Bildschirm bestimmt. "Passt nicht auf den Bildschirm" ist aber schon ein Smell, der einen nachdenken lassen sollte, ob man vielleicht zu viel an einer Stelle macht.

Deswegen habe ich ja auch Jos Funktion seziert - sie passt locker auf einen Bildschirm, ist aber trotzdem zu lang (=bündelt zu viele Funktionen) und kann mehrfach entkernt werden.

Andere Funktionen sind vielleicht 200 Zeilen lang, aber es ist sinnlos sie aufzuteilen, weil möglicherweise viele Datenfelder zu bewegen sind und eine Menge Zuweisungen durchgeführt werden müssen (wobei man dann natürlich gleich wieder schnuppern und sich fragen sollte, ob das verarbeitete Objekt gut designed ist).

Für den Programmierer ist es im worst case letztlich doppelt egal, ob er sich in einer Funktion verliert oder in einer Unzahl von Funktionen.

Nein, hier muss ich widersprechen. Es ist nicht egal. Einen algorithmisch komplizierten Trümmerhaufen von 200 Zeilen wirst Du im Normalfall nicht unittesten können. Er macht auch viel Mühe, ihn zu verstehen. Sowas schreit eher nach einer eigenen Klasse mit mehreren kleinen Methoden. DIESE kannst Du dann separat testen und kommst viel besser klar. Und wer die Hauptfunktion liest, die den Rest orchestriert, kann bei gut gewählten Namen der aufgerufenen Funktionen gleich sehen was sie tun und kann das Thema Top-Down aufnehmen.

"Form follows function", hast Du gesagt - aber was ist hier "function"? Es ist die korrekte Arbeitsweise des Programms, die Wartbarkeit, und die Testbarkeit. Die Form für gute Testbarkeit sind kleine, überschaubare Funktionen, die genau eine Sache tun.

Das einzige Gegenargument ist, dass gerade PHP viel Overhead für einen Funktionsaufruf hat. Das ist in PHP 7 schneller geworden, aber die Differenz zwischen inline code und einem Funktionsaufruf ist immer noch signifikant. Aber - wenn jemand Dinge baut, die performancekritisch sind, dann muss man fragen ob PHP die richtige Sprache für den Anwendungszweck ist (oder die ZEND Engine die geeignete Ausführungsumgebung). Wenn man eine sauber aufgeteilte Realisierung hat und dann durch Profiling feststellt, dass der Overhead für den Aufruf einer Funktion der Bottleneck ist, DANN kann man in NACHHINEIN eine Funktion inline verschieben. Sowas sollte man nicht vorher tun.

Rolf

[Christian Kruse]

Hallo Rolf,

Wenn man eine sauber aufgeteilte Realisierung hat und dann durch Profiling feststellt, dass der Overhead für den Aufruf einer Funktion der Bottleneck ist, DANN kann man in NACHHINEIN eine Funktion inline verschieben. Sowas sollte man nicht vorher tun.

Und das ist dann immer noch schlechter Stil. Dass man manchmal bewusst auf guten Stil verzichten muss, das hat ja keiner bestritten.

LG,
CK

[Klawischnigg]

Für den "Rotz" werde ich mich nicht entschuldigen,

Eh net, wenn's Dir so besser geht...

deine Ausdrucksweise gegenüber Gunnar war genau das.

Echt? Bist Du sein Beschützer? Und was genau hätte ich dem armen Gunnar angetan, daß Dich Deine Kinderstube so leicht vergessen lässt?

Zur Sache selbst denke ich ist alles gesagt worden. Es hat ja niemand bestritten, daß Lesbarkeit und Überschaubarkeit von Code wichtige Kriterien sind, aber deshalb vorgeben zu wollen, wie lange eine Funktion zu sein hat, ist einfach unnötige Beckmesserei…

[pl]

Du weißt genau, dass „genau unter dem Schlüsselwort“ genau unter dem ersten Zeichen des Schlüsselwortes meint.

Ich könnte es als Annahme treffen. Hab jedoch die Erfahrung gemacht, dass es in der Praxis meistens nicht so gehandhabt wird, oh Schreck:

while
  {
  i++;
  a = b;
  c = a * i;
  a += i;
  if (a == 33)
    {
    printf("Mist, das wollte keiner\n");
    }
  }

Und nun soll einer auf den ersten Blick sehen, dass die Klammer ganz unten nicht zu dem if gehört!?

Indes: Mit der Platzierung der öffnenden Klammer in derselben Zeile nach dem Schlüsselwort ist eine eindeutige Zuordnung ja gegeben. Die öffnende Klammer auf einer neuen Zeile hingegen macht den Code auch nicht besser lesbar.

[Reinhard]

Hey,

Das nennt sich Allman-Stil (in der englischen Wikipedia) und ist mein bevorzugter Coding-Stil – in an C-Syntax angelehnte Programmiersprachen wie auch in CSS.

Der Allman-Stil ist auch mein Favorit. Nur sind die Funktionen dabei mein Sorgenkind:

let a = function ()
{
    // do some stuff
};

[0, 1, 2].reduce((r, num) =>
{
    return r + num;
}
, 0);
// oder gar so?
[0, 1, 2].reduce((r, num) =>
{
    return r + num;
}, 0);
// oder eher so?
[0, 1, 2].reduce((r, num) =>
{
    return r + num;
}
 , 0);

{ unter eine Variablendeklaration? Ungewohnt, aber damit kann man sich ja noch anfreunden.
Das 2. Beispiel aber sieht doch alles andere als hübsch aus. Oder für welche Variante bist du?

Da ich gerade dabei bin mich in ESLint einzuarbeiten, suche ich nach einer Möglichkeit, Funktionen von "brace-style": ["error", "allman"] auszuschließen (und wenn wir schon dabei sind class gleich mit). Weiß hier jemand, ob sich da was machen lässt?

Reinhard

[mermshaus]

Ich finde dort diese Möglichkeiten „korrekt“, wenn es Allman-Style sein soll:

[0, 1, 2].reduce((r, num) => { return r + num; }, 0);


[0, 1, 2].reduce(
    (r, num) => { return r + num; },
    0
);


[0, 1, 2].reduce(
    (r, num) =>
    {
        return r + num;
    },
    0
);


[0, 1, 2].reduce(
    (
        r,
        num
    ) =>
    {
        return r + num;
    },
    0
);

Im One-True-Brace-Style genauso, nur eben bei den beiden letzten Beispielen ohne den Zeilenumbruch vor der öffnenden geschweiften Klammer.

[pl]

Moin,

Stil ist keine Frage der persönlichen Ansicht sondern immer eine Frage der Teamarbeit.

MfG

[mermshaus]

Stil ist keine Frage der persönlichen Ansicht sondern immer eine Frage der Teamarbeit.

Was möchtest du damit im Kontext hier aussagen?

[Gunnar Bittersmann]

@@mermshaus

Stil ist keine Frage der persönlichen Ansicht sondern immer eine Frage der Teamarbeit.

Was möchtest du damit im Kontext hier aussagen?

Vermutlich, dass „Ha’m wa immer schon so gemacht“ und „Machen andere auch so“ doch sinnvolle Argumente wären. 😱

LLAP 🖖

[Rolf b]

Nee. Dass viele Wege nach Rom führen, aber in einem Team möglichst alle den gleichen Weg nehmen sollten. Sprich: Coding Guidelines einhalten sollten. Sonst ist das Erzeugnis nachher schrecklich zu lesen.

[mermshaus]

Mag sein, aber wo ist der Zusammenhang? Reinhard hat gefragt, wie Gunnar (bzw. eben immer implizit auch andere Mitleser) den Code in einem konkreten Beispiel formatieren würde. Darauf habe ich mit konkreten Beispielen geantwortet, wie ich es machen würde. (Am Rande: Ein Coding-Standard regelt auch nicht jedes Detail.) Als Direktantwort auf meinen Post dann der Einzeiler von pl:

Stil ist keine Frage der persönlichen Ansicht sondern immer eine Frage der Teamarbeit.

Und ich frage mich nun, ob ich das als Kritik an meiner Antwort verstehen muss. Denn, mit Verlaub, für mich klingt es so, als würde mir ein falsches Beharren auf einer persönlichen Meinung vorgeworfen, die eine Zusammenarbeit im Team gewissermaßen untergraben würde.

Sollte das von pl so gemeint sein, würde ich das im Kontext für eine völlig aus der Luft gegriffene Unterstellung halten, die ich weit von mir weisen würde.

PS: Sorry, ich sage mit keiner Silbe, dass ich gegen das Einhalten von Coding-Standards bin. Nach der gleichen „Logik“ könnte man auch aus jedem für Beispiele gewählten Klassennamen einen „Mangel an Teamfähigkeit“ ableiten, weil der Name und eine etwaige Namespace-Struktur selbstverständlich im Team zu besprechen wären. Das ist doch komplett absurd.

[Rolf b]

Ich glaube, du hast jetzt was arg in den falschen Hals bekommen. Es sei denn, ihr beiden habt eine lange und streitvolle Vergangenheit und du siehst darin einen Grund, von PL grundsätzlich erstmal persönliche Angriffe zu vermuten. Davon weiß ich dann aber nichts, dafür bin ich hier zu neu.

PLs Beitrag habe ich lediglich als Hinweis darauf gelesen, dass Individualbetrachtungen zurückstehen müssen, wenn ein Team von Programmierern einheitliche Codingstandards einhalten sollte. Der eine bevorzugt "1TBS" a.k.a. K&R, der andere Allman, ein dritter Horstmann, und Whitesmith haben wir hier im Thread auch schon gesehen.

Als persönlichen Angriff auf Dich habe ich das nicht gelesen. Eher als Beitrag im PL-Stil: knapp, und das, was ihm gerade zum Thema in den Sinn kommt. Was dann gelegentlich kontextfrei aussieht. Übrigens bin ich keine Sockenpuppe von PL, falls das jemand vermutet, auch wenn wir den gleichen Vornamen haben 😉

Nach deiner Rückfrage, was das hiermit zu tun hätte, hat Gunnar eine wie ich finde ziemlich unfaire Antwort gegeben, weil sie den Team-Aspekt zu sturem Beharren auf Altem verdreht. Nur darauf habe ich geantwortet.

Rolf

[Gunnar Bittersmann]

@@Rolf b

hat Gunnar eine wie ich finde ziemlich unfaire Antwort gegeben, weil sie den Team-Aspekt zu sturem Beharren auf Altem verdreht.

Unfair finde ich meine Antwort nicht; vielleicht etwas knapp.

Sicher spielt der Team-Aspekt eine Rolle. Womöglich aber eine unrühmliche. Wenn sich jeder einzelne im Team auf „machen andere im Team auch so“ bezieht, kann keine sinnvolle Diskussion zustandekommen und der Status quo wird festzementiert.

Man kann sich aber auch im Team zusammensetzen und gemeinsam überlegen, was denn sinnvolle Coding-Richtlinien für dieses Team wären. Ohne „was machen denn andere Teams?“. Dann kann auch Allman-Stil bei rauskommen. Und Tabs zum Einrücken.

LLAP 🖖

[Reinhard]

Hey,

[0, 1, 2].reduce((r, num) => { return r + num; }, 0);


[0, 1, 2].reduce(
    (r, num) => { return r + num; },
    0
);

Ja, bei Single-Line-Functions ist die Sache eindeutig.

[0, 1, 2].reduce(
    (r, num) =>
    {
        return r + num;
    },
    0
);

Bei Multi-Line-Functions ist das wohl am saubersten.

Mit 1tbs nur für Funktionen könnte man das genauso klar aber kompakter schreiben:

[0, 1, 2].reduce((r, num) => {
    return r + num;
}, 0);

Reinhard