Stilfrage: mehrere Aufrufe oder "Umweg" über Array

[paedubucher]

An die Stilisten unter den Programmierer: Welches Codeschnipsel (hier in Java) bevorzugt ihr?

Entweder:

Code: Alles auswählen

foo.baz("a");
foo.baz("b");
foo.baz("c");

Oder:

Code: Alles auswählen

String[] values = new String[]{"a", "b", "c"};
for (String v : values) {
    foo.baz(v);
}

Die abzuarbeitenden Parameter sind fix vorgegeben (also immer "a", "b" und "c"), könnten sich aber dereinst wieder ändern, d.h. mehr oder weniger werden.

Zusatzfragen: Vi(m) oder Emacs? Tabs oder Spaces? Öffnende geschweifte Klammer auf die gleiche oder auf die nächste Zeile?

[novalix]

In Common Lisp würde ich für so eine Aufgabe eine der Map-Funktionen verwenden. So etwa:

Code: Alles auswählen

(mapcar #'baz '(a b c))

[seep]

An die Stilisten unter den Programmierer: Welches Codeschnipsel (hier in Java) bevorzugt ihr?

Den der kürzer und verständlicher ist, im Beispiel also den ersten Code.

Natürlich emacs, Tabs, geschweifte Klammer in die nächste Zeile. Und der Atari ST war immer besser als der Amiga!!1!elf!

[inne]

Deine zweite Variante ist zur ersten wie viel mal mehr aufwändiger in "Rechenschritten/Speicheroperationen", Sprungmarken und Speicherverbrauch/Programmgröße und ab wann rentiert sich das gegenüber der ersten

Öffnende geschweifte Klammer auf die gleiche oder auf die nächste Zeile?

Wenn ich dann fertig bin, lasse ich gerne tidy, perltidy drüberlaufen.
Bei Python stellt sich die Frage ja imo nicht und viele andere Sprachen oder für Shell-Skrtipe kenne ich so was was wei tidy nicht. Hätte es aber gerne. Android-Studio (Java) hat was eigenes um den Code strukturieren zu lassen.

In C hatte ich mal die Lust sowas zu schreiben:

Code: Alles auswählen

int main (argc, argv)
	int argc;
	char **argv;
{

[inne]

Ich bin wahrlich kein Perl-Crack aber:

Code: Alles auswählen

$ cat benckmark.pl
#/usr/bin/perl

use Benchmark qw(:all);

my $count = 10000000;

sub f() {;}

cmpthese(
    $count,
    {
        "1" => sub {

              f;
              f;
              f;
        },

        "2" => sub {

              my @list = (undef,undef,undef);
              for (@list) {
                            f;
              }
        },
    }
);

Code: Alles auswählen

$ perl benckmark.pl
       Rate    2    1
2 1186240/s   -- -65%
1 3424658/s 189%   --

[inne]

Die abzuarbeitenden Parameter sind fix vorgegeben (also immer "a", "b" und "c"), könnten sich aber dereinst wieder ändern, d.h. mehr oder weniger werden.

Was mir auch noch einfällt. Im Diff auf Git o.ä. schaut die erste Variante i.d.R. auch übersichtlicher aus. Wobei man da mit Farbe viel rausholen kann^^

[paedubucher]

Danke für all die Rückmeldungen!

Performance mag wohl eine Rolle spielen, ich frage mich aber, ob das gegenüber der Ausführungsgeschwindigkeit von foo.baz() signifikant sein mag. Ich tippe eher auf nein; man stelle sich vor, dass foo.baz() z.B. eine E-Mail versendet oder eine grosse Berechnung anstösst.

Einfachheit ist auch ein Punkt: ich sehe beim ersten Codefragment sofort, was passiert.

Bei der Erweiterbarkeit halte ich aber den zweiten Code für besser. Erstens könnte das Array von einer anderen Funktion/Methode erstellt werden. Zweitens muss man sich folgendes vorstellen:

Code: Alles auswählen

foo.baz("a");
foo.baz("b");
foo.baz("c");
foo.baz("d");
foo.baz("e");
foo.baz("f");
foo.baz("g");
foo.baz("h");
foo.baz("i");

Im Vergleich zu:

Code: Alles auswählen

String[] values = new String[]{"a", "b", "c", "d", "f", "g", "h", "i"};
for (String v : values) {
    foo.baz(v);
}

Nun ist die zweite Variante schlanker. Und je nachdem, ob vor- und nachher noch etwas in dieser Methode passiert, dürfte sie bei einer grossen Anzahl von Werten besser auf einen Bildschirm passen.

Dann hatten wir noch das SCM-Argument, wobei bei ersterem Code Änderungen einfach zu erkennen (und wohl auch zu mergen) sind. Das leuchtet mir ein.

@seep: Emacs, Tabs und geschweifte Klammern auf der nächsten Zeile? Na von dir lasse ich mir gar nichts sagen!

[Meillo]

Einfachheit ist auch ein Punkt: ich sehe beim ersten Codefragment sofort, was passiert.

Bei deinem ersten Post ist die erste Variante klar lesbarer. Man erinnere sich nur immer wieder an den Telefontest!

Haettest du diese umfangreichere Form des gleichen Beispiels nicht schon selbst gebracht, dann haette ich sie angefuehrt:

Bei der Erweiterbarkeit halte ich aber den zweiten Code für besser. Erstens könnte das Array von einer anderen Funktion/Methode erstellt werden. Zweitens muss man sich folgendes vorstellen:

Code: Alles auswählen

foo.baz("a");
foo.baz("b");
foo.baz("c");
foo.baz("d");
foo.baz("e");
foo.baz("f");
foo.baz("g");
foo.baz("h");
foo.baz("i");

Im Vergleich zu:

Code: Alles auswählen

String[] values = new String[]{"a", "b", "c", "d", "f", "g", "h", "i"};
for (String v : values) {
    foo.baz(v);
}

Nun ist die zweite Variante schlanker. [...]

Dieses Wort ``nun'' ist fuer mich das entscheidende. Ich glaube, man muss sich immer wieder aktiv vom Wasserfalldenken verabschieden: Es geht nicht um die Frage, ob die Variante eins oder zwei absolut besser ist, sondern darum, dass im ersten Post die Variante eins besser ist und im letzten Post die Variante zwei. Der Wechsel von erster zu zweiter im Laufe des Wachstums des Codes, das ist fuer mich der Kern von Codepflege. Man sollte sich beim Lesen von Code stets fragen ob er so wie er ist (noch) gut ist oder besser umgebaut werden sollte. Mit vielen kleinen Schrittchen (waehrend des Lesens!) pflegt man seine Codebasis, IMO.

Was man sich allerdings schon fragen kann -- wie du es auch tust -- ist, ob es in einem konkreten Fall schon zu Beginn abzusehen ist, dass die Liste gewiss bald wachsen wird ... oder dass die Liste von extern dynamisch eingelesen werden koennte, was die zweite Variante nahelegt bzw. erfordert.

Natuerlich ist das hier ein konstruiertes Beispiel (was halt schlecht ist, und darum schaetze ich es, dass Kernighan und Co. in ihren Buechern immer realen Code besprechen). Wenn es tatsaechlich um die Werte `a' bis `i' gehen wuerde, dann sollte man die generieren lassen, weil dann sichergestellt ist, dass kein Buchstabe vergessen oder vertauscht wird.

Vielleicht nochmal generell: So stupider Code wie die Variante 1 finde ich nicht grundsaetzlich schlecht, denn er ist sofort verstaendlich. Sein Problem ist die Schwaeche bei der Sichtbarkeit von Vollstaendigkeit und Reihenfolge. Das ist in Variante 2 besser, dafuer leidet diese unter der groesseren Anfaelligkeit von Codefehlern. Es ist wie immer ein Abwaegen verschiedener Ziele, die man als Programmierer anstrebt. Generelle Antworten gibt es auf diese Fragen selten ... jedenfalls keine guten generellen Antworten.

[Lord_Carlos]

Mhh, funktioniert AddAll mit einem array?

String[] values = new String[]{"a", "b", "c", "d", "f", "g", "h", "i"};
foo.addAll(values)

Bin mir gerade nicht sicher.

List<String> places = Arrays.asList("A", "B", "C");
Das waere mein favorite.

Edit: Noch besser: Collections.addAll(myArrayList, 'A', 'B', 'C', 'D');

Edit2: Je nachdem wie gross die Liste wird, wuerde ich das generieren der Liste in eine eigene Metode stecken.
So ala
foo.addAll(getBuchstabenList());

Und weiter unten:
private list<Strings> getBuchstabenList() { ... }
Jeder der das liest sieht dann das es eine Metode gibt die eine Buchstaben liste generiert. Wie die genau funktioniert kann in dem Augenblick erstmal egal sein. Hat den vorteil das man nicht gleich von sowas haeslichem wie {"a", "b", "c", "d", "f", "g", "h", "i"}; abgelenkt wird.

[shoening]

Hi,

ich würde auch eine der Varianten mit Array.asList verwenden.

Zu den anderen Stilfragen kann ich nur Checkstyle empfehlen (und dann die sun_checks.xml benutzen) - also:

Einrücken mit 4 Spaces
öffnende Klammer in die gleiche Zeile

Ciao
Stefan

[paedubucher]

Einfachheit ist auch ein Punkt: ich sehe beim ersten Codefragment sofort, was passiert.

Bei deinem ersten Post ist die erste Variante klar lesbarer. Man erinnere sich nur immer wieder an den Telefontest!

Was ist denn der Telefontest?

Bei der Erweiterbarkeit halte ich aber den zweiten Code für besser. Erstens könnte das Array von einer anderen Funktion/Methode erstellt werden.
[...]
Dieses Wort ``nun'' ist fuer mich das entscheidende. Ich glaube, man muss sich immer wieder aktiv vom Wasserfalldenken verabschieden: Es geht nicht um die Frage, ob die Variante eins oder zwei absolut besser ist, sondern darum, dass im ersten Post die Variante eins besser ist und im letzten Post die Variante zwei. Der Wechsel von erster zu zweiter im Laufe des Wachstums des Codes, das ist fuer mich der Kern von Codepflege. Man sollte sich beim Lesen von Code stets fragen ob er so wie er ist (noch) gut ist oder besser umgebaut werden sollte. Mit vielen kleinen Schrittchen (waehrend des Lesens!) pflegt man seine Codebasis, IMO.

Der Code, an den ich bei meinem Beispiel ursprünglich dachte, und der mir mittlerweile nicht mehr zur Verfügung steht, war tatsächlich einer, der stets gewachsen ist.

Natuerlich ist das hier ein konstruiertes Beispiel (was halt schlecht ist, und darum schaetze ich es, dass Kernighan und Co. in ihren Buechern immer realen Code besprechen). Wenn es tatsaechlich um die Werte `a' bis `i' gehen wuerde, dann sollte man die generieren lassen, weil dann sichergestellt ist, dass kein Buchstabe vergessen oder vertauscht wird.

Ja, konstruierte Beispiele führen oft dazu, dass man alles mögliche hineininterpretieren kann, wozu denn der Code gebraucht werden könnte. In diesem Fall ging es um hart codierten E-Mail-Versand nach Kriterien, die nur von einem Programm (also nicht per statische Liste) bewältigt werden konnte. Da kamen mit der Zeit mehr E-Mail-Adressen bzw. E-Mail-Verteiler dazu.

[Meillo]

Einfachheit ist auch ein Punkt: ich sehe beim ersten Codefragment sofort, was passiert.

Bei deinem ersten Post ist die erste Variante klar lesbarer. Man erinnere sich nur immer wieder an den Telefontest!

Was ist denn der Telefontest?

Ein Verstaendlichkeitstest fuer Code, beschrieben in ``The Elements of Programming Style'' von Kernighan und Plauger. Siehe z.B.: http://www.robelle.com/smugbook/program.html

[paedubucher]

Bei deinem ersten Post ist die erste Variante klar lesbarer. Man erinnere sich nur immer wieder an den Telefontest!

Was ist denn der Telefontest?

Ein Verstaendlichkeitstest fuer Code, beschrieben in ``The Elements of Programming Style'' von Kernighan und Plauger. Siehe z.B.: http://www.robelle.com/smugbook/program.html

"Use the telephone test for readability. If someone could understand your code when read aloud over the telephone, it's clear enough. If not, then it needs rewriting."

Wie muss ich mir das vorstellen: Soll da der Code Zeichen für Zeichen gelesen werden, z.B. "if items open bracket index closing bracket equals five", oder wird er sinngemäss wiedergegeben, z.B. "check if the item with the given index is five"? Beim ersten dürfte das wohl eine Stufe zu tief sein, um überhaupt von "Verständnis" reden zu können.

[Meillo]

"Use the telephone test for readability. If someone could understand your code when read aloud over the telephone, it's clear enough. If not, then it needs rewriting."

Wie muss ich mir das vorstellen: Soll da der Code Zeichen für Zeichen gelesen werden, z.B. "if items open bracket index closing bracket equals five", oder wird er sinngemäss wiedergegeben, z.B. "check if the item with the given index is five"? Beim ersten dürfte das wohl eine Stufe zu tief sein, um überhaupt von "Verständnis" reden zu können.

Keine Logik erzaehlen, sondern *vorlesen* ... wie eine mathematische Formel. eqn(1) kennt man ja heutzutage nicht mehr, aber so wie man dort Formeln aufschreibt: https://en.wikipedia.org/wiki/Eqn#Syntax_examples

In deinem Fall also fuer ``foo.baz("a");'' z.B.: ``foo Punkt baz, runde Klammer auf, String a, runde Klammer zu, Strichpunkt'', oder ``Aufruf von foo Punkt baz mit Argument String a, Strichpunkt''.


Treten wir doch mal einen Schritt zurueck: Du stellst hier zwei Gegensaetze hin; sollte unser Ziel als Programmierer denn nicht sein, dass wir diese in Deckung bringen. Also das waere das Ideal, dass das was wir vorlesen der logischen Beschreibung entspricht! (Je nach Syntax der verwendeten Sprache kann man dem unterschiedlich nahe kommen.)

Wenn dein Sinn ist: ``check if the item with the given index is five'', dann sollte dein Code doch idealerweise etwa so aussehen: ``if (itemWithIndex("a") == 5) {...}''. Und schon eruebrigt sich deine Frage grossteils.


Noch ein Schritt weiter waere es dann aber im Code nicht technische Details (z.B. Index) zu beschreiben sondern inhaltliche Bedeutung (z.B. Vorname). Dann liest sich der Code naemlich schon fast wie die fachliche Dokumentation! Natuerlich, das ist ein Ideal, aber man muss schliesslich wissen (und sich immer wieder vergegenwaertigen!) was man anstrebt.