1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Mozillas…

Lesbarkeit?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Lesbarkeit?

    Autor: quantalquetzal 16.07.15 - 09:54

    Ich bin seit vielen Jahren selbstständiger Java Entwickler und weiß, dass "public static void main(String[] args) {}" auch nicht gerade ein Wunder an Ausdruckskraft und Lesbarkeit ist.

    Aber es scheint mir, dass Rust, genauso wie zum Beispiel auch Scala oder andere interessante neuere Sprachen, die Sache nochmal zusätzlich verkomplizieren. Das ist nur so mein Gefühl, aber "fn", "let", "->", "i32", ";", "{}", "_", "::", "vec", "len()" scheinen mir eher dazu geeignet Buchstaben zu sparen als die Lesbarkeit zu erhöhen.

    Dabei gab es in den letzten Jahren mit "fluent interfaces" (zum Beispiel bei Joda-Time), oder durch die Benutzung von Bibliotheken wie Google Guava durchaus das Bestreben die Lesbarkeit und, damit verbunden die Wartbarkeit, Korrektheit und Sicherheit von Programmcode zu erhöhen. Auch der fortwährende Erfolg von Python lässt sich wohl vor allem auf dessen Einfachheit zurückführen.

    Irgendwie scheint es mir, nehmen sich zu wenige neue Sprachen daran ein Vorbild.

  2. Re: Lesbarkeit?

    Autor: minnime 16.07.15 - 10:42

    Das ist mir auch sofort aufgefallen. Dabei kann man nicht mal was gegen "let" oder das Semikolon sagen, das sind halt Sprachmerkmale, wo ich das noch einsehe aber "vec" für vector oder "len" für length. Dabei handelt es sich ja Klassen bzw. Funktionen die Bestandteile der Bibliothek sind oder sein sollten und das darf man doch ausschreiben.

    Überhaupt scheinen C/C++ Programmierer einen Hang zu schwer lesbaren Programmen zu haben. Wenn ich mir mal C Programme ansehen darf sehe ich oft keine sprechenden Variablen, Funktionsparameter die nur aus einem Buchstaben bestehen und natürlich nicht erklärt werden und überhaupt ist man sehr sparsam mit Dokumentation.

  3. Re: Lesbarkeit?

    Autor: ibsi 16.07.15 - 10:47

    Seh ich auch so. Ich komme zwar auch mehr aus dem Java-Bereich, aber Rust ist ... noch hässlicher als C++
    Wer will das denn lesen?

  4. Re: Lesbarkeit?

    Autor: oleid 16.07.15 - 10:50

    Hm, ist wohl eine Sache der Gewohnheit. Also ich finde das gut lesbar.

  5. Re: Lesbarkeit?

    Autor: PiranhA 16.07.15 - 10:52

    Ich habe auch immer das Gefühl, dass Leute bei systemnaher Programmierung eine andere Definition von Lesbarkeit haben. Entsprechend scheint mir Rust ein Sprache von eben solchen Leuten für solche zu sein. Denen ist der Aspekt gelinde gesagt, einfach Wurst. Dort ist der Code auch noch fast wie ein Stein gemeißelt. Außer Bugfixes und Erweiterungen, gibt es kaum Änderungen.

    Auf der anderen Seite fand ich anfangs Lambda-Expressions auch unleserlich. Wenn man sich aber erstmal daran gewöhnt hat, ist es an Eleganz kaum zu überbieten. Jemand, der die Sprache also wirklich intensiv nutzt, wird da einen anderen Blickwinkel drauf haben.

  6. Re: Lesbarkeit?

    Autor: ibsi 16.07.15 - 10:56

    Davon gehe ich auch mal aus.

    Mochte C/C++ allerdings noch nie (also vom rein optischen her).

  7. Re: Lesbarkeit?

    Autor: glurak15 16.07.15 - 11:01

    Nur dann muss man sich Fragen: Warum nicht gleich C++ nutzen?
    Ich finde C++ macht einiges doch sehr Kompliziert und umständlich, was viele Sprachen inzwichen wesentlich besser machen. Weshalb eine Alternative dazu nun wieder auf solche komischen Ausdrücke und definitionen zurückgreift, anstatt auf bewährteres zu setzen, versteh ich nicht.
    Eine Sprache, die den Funktionsumfang von C++ und die Lesbarkeit von Java/C# bietet, wäre wirklich nicht schlecht.

  8. Re: Lesbarkeit?

    Autor: PiranhA 16.07.15 - 11:11

    Also in erster Linie geht es bei Rust ja darum, die Performance von C++ zu haben und Speicher- und Sicherheitsprobleme ohne GC direkt zur Compile-Zeit zu lösen.
    Es geht nicht darum eine populäre Sprache für Einsteiger zu machen. Die Sprache hat einen ganz klaren Einsatzrahmen, wofür sie gedacht ist und so sollte man sie auch bewerten. Es geht nicht darum ein Zwischending zwischen C++ und Java/C# zu schaffen.

  9. Scala rockt (weil funktional-objektorientiert)

    Autor: Dr. WatsON 16.07.15 - 11:12

    quantalquetzal schrieb:
    --------------------------------------------------------------------------------
    > Aber es scheint mir, dass Rust, genauso wie zum Beispiel auch Scala oder
    > andere interessante neuere Sprachen, die Sache nochmal zusätzlich
    > verkomplizieren. Das ist nur so mein Gefühl, aber "fn", "let", "->", "i32",
    > ";", "{}", "_", "::", "vec", "len()" scheinen mir eher dazu geeignet
    > Buchstaben zu sparen als die Lesbarkeit zu erhöhen.

    Scala hat nur marginal andere Syntax, im Vergleich zu Java. Ich verwende beides, aber ebenso C, C++ und gelegentlich Python und Haskell. So viel zu den Sprachen, die ich immer mal wieder verwende und nicht nur für 1-2 kleinere Projekte ausprobiere.

    Die Syntax von Rust finde ich dagegen grausam, weiß nicht genau warum. Aber an Scala habe ich mich sehr schön gewöhnen können.

    Was genau missfällt dir daran? Im Endeffekt programmierst du, sofern du rein objektorientiert bleibst, fast genauso wie in Java. Die Methoden heißen meist sogar recht ähnlich.

    Wenn ich dagegen ein komplett anderes Paradigma einsetze (in Scalas Fall wäre das funktional), dann ändert sich natürlich die Syntax, weil es in diesem Paradigma eben gewisse Standards gibt.

    :: und andere haben ganz spezielle Bedeutungen, (wie etwa auch in Haskell) für Tail-Recursion und andere Features.

    Das heißt aber nicht, dass du nicht objektorientiert arbeiten könntest und dann deine Maps ganz normal mit:

    val map: mutable.HashMap[Int, String] = new mutable.HashMap[Int, String]

    map.put(1, "Blubb)

    befüllen könntest :)

  10. Re: Lesbarkeit?

    Autor: Trockenobst 16.07.15 - 12:27

    glurak15 schrieb:
    --------------------------------------------------------------------------------
    > Eine Sprache, die den Funktionsumfang von C++ und die Lesbarkeit von
    > Java/C# bietet, wäre wirklich nicht schlecht.

    Das Problem ist: daran haben sich schon viele versucht. Man könnte z.B. einfach Java compilieren (oder C#) und den GC entfernen. Dann müsste aber Java/C# Destructoren bekommen (also Möglichkeiten dem new() ein delete() folgen zu lassen). Dies verändert die Sprache total, und das was rauskommt ist meist nicht besonders performant.

    Ein erster Versuch: Die Sprache D: http://dlang.org/
    Leider empfinde ich D als simpleren Syntax-Zucker um die ewigen <*_ptr> Klammerwüsten, die man heute in C++11 benutzt. Optimiertes D mit Speicher und Arrayzugriffen sieht nicht anders aus als C, mit den genau selben Problemen: wenn du nicht weißt was du tust -> Probleme ohne Ende.

    Rust (oder auch Go) versuchen mit mehr oder weniger leerem Arbeitsblatt und einer "inhaltlichen Sauberkeit" die Probleme der Laufzeitsicherheit und Speicherschutz, aber auch die Überverzuckerung von OOP in Sprachen wie Java oder C# entgegenzuwirken. Das Ziel hier sind eben auch schnelle Programme nicht nur sichere. Viele Leute brauchen immer noch nativen Geschwindigkeit von C++ und bleiben bei C/C++/D weil es mit deren anderen "neuen Sprachen" immer trade-offs gibt. Go z.B. hat einen GC drin, und das finden viele einfach nicht akzeptabel.

    Als C++ Hacker (bestenfalls Note 2-) habe ich das eine oder andere mal in Rust gemacht und bin sehr erstaunt wie konsequent sie das Ownership Modell der Variablen verteidigen. Du musst schon auf Code ebene sehr genau wissen was das Lifecycle der Variable ist und wem du sie zur Veränderung "leihen" willst. Und dadurch siehst auch sehr schnell wenn du logische Fehler machst.

    Gerade wenn man 15 Jahre OOP gemacht hat, sind Traits sehr gewöhnungsbedürftig. Wenn du das aber verstanden hast, sind sie weitaus flexibler als Klassen oder Interfaces. Und vor allem: im Compilat extrem schnell.

    Für bestimmte Usecases (in meinem Fall: ein kleines Game) kriege ich das Backend tatsächlich auf Windows+Linux(VM)+Android zum laufen. Und das sagt viel über Qualität des Compiler.Backends aus.

    Natürlich ist Rust nicht perfekt, aber für die V1 der Sprache (vs V14 und V17 von C++) ist das schon ein sehr guter Anfang.

  11. Re: Lesbarkeit?

    Autor: WhyLee 16.07.15 - 15:03

    Mir ist das mit der Lesbarkeit bzw. dessen Nicht-Vorhandensein auch gleich aufgefallen.
    Nebenbei scheint es immer noch grausliche Codingstyles zu geben, die aus der Zeit der 70er-Jahre stammen wo man einen 80-Zeichen Bildschirm mit wenig Zeilen hatte und das seinen Auswirklung auf den damaligen Codingstyle hatte.

    Darum werden Zeilen bei diesen veralteten Codingstyles nach 80 Zeilen umgebrochen und die geschwungene Klammer auf "{" am Schluß der Zeile gemacht um Zeilen zu sparen.

    Das hat jetzt natürlich nichts mit der Programmiersprache zu tun, aber Full-HD mit großen Bildschirmen ist heute ja kein Kostenfaktor mehr.
    Da ist eine Zeile mit 120 Zeichen noch nicht brutal-lang und man hat immer noch Wergzeugleisten/Klassenbäume neben dem Codefenster.

    Wichtig ist wirklich die Wartbarkeit des Codes und da gehört eine gewisse Augenfreundlichkeit dazu, sonst kann ich ja gleich wieder in Maschinencode programmieren.

    if (codestyle < 2000)
    {
    printf("What the f***!\r\n");
    if (codestyle < 1985)
    {
    printf("Kernighan and Ritchie are old grandpas with small monitors, You too?r\n");
    }
    }

    Wenn die Klammer-auf in einer eigenen Zeile ist, ist der Block besser sichtbar und die etwas ländere Textzeile muß ich nicht gleich umbrechen.

    Ich kenne aber Fetischisten, die noch immer in diesem alten Style programmieren - ich glaub da gibts noch viele - meistens auch nicht zugänglich für Argumente jenseits des persönlichen Geschacks.

    Ich glaub die Linux-Kernel-Fritzen sind noch solche Dinosaurier, oder?

  12. Re: Lesbarkeit?

    Autor: Anonymer Nutzer 16.07.15 - 15:08

    WhyLee schrieb:
    --------------------------------------------------------------------------------
    > Ich kenne aber Fetischisten, die noch immer in diesem alten Style
    > programmieren - ich glaub da gibts noch viele - meistens auch nicht
    > zugänglich für Argumente jenseits des persönlichen Geschacks.

    Und zack, machst Du genau das selbe wie die, denen Du es vorwirfst. Für Lesbarkeit von Code gibt es keine Maßeinheit, bis zu einem bestimmten Punkt ist das subjektives Empfinden. Einfach zu behaupten, der Block wäre besser sichtbar, macht aus Deinem persönlichen Geschmack auch keinen Fakt.

    Ich kann die öffnende Klammer am Zeilenende sehr gut lesen, code auch selbst so und widerlege hiermit Deine apodiktische Aussage.

  13. Re: Lesbarkeit?

    Autor: WhyLee 16.07.15 - 15:17

    glurak15 schrieb:
    --------------------------------------------------------------------------------
    > Eine Sprache, die den Funktionsumfang von C++ und die Lesbarkeit von
    > Java/C# bietet, wäre wirklich nicht schlecht.

    Ich programmiere ca. 50/50 auf Embedded-Systemen in C und auf dem PC in C#.
    Von daher kenne ich auch so die übliche Bandbreite.
    Wenn ich dann mal zufällig was in QT mit C++ code, dann fällt mir der Overhead mit dem H-File wieder richtig auf. Das ist etwas was ich in C# schon genieße, daß ich nicht extra ein H-File dazu basteln muß.
    Von daher ist die Time2Market in C# mit Visual Studio nicht so übel.

    Ein anderes Thema ist dann noch die Klassenlibrary, die in C# (.net) schon praktisch ist. genauso wie in java etc. wie da der aktuelle stand in c++ ist kann ich aber nicht sagen. vielleicht gibts da interessante kommentare anderer user hier?

  14. Re: Lesbarkeit?

    Autor: twothe 16.07.15 - 16:21

    Das liegt daran das ein moderner PC 64k Speicher hat, wo auch der Quellcode rein passen muss, und kein PC jemals mehr als 1MB Speicher brauchen wird.

  15. Re: Lesbarkeit?

    Autor: Schrödinger's Katze 16.07.15 - 22:48

    glurak15 schrieb:
    --------------------------------------------------------------------------------
    > Eine Sprache, die den Funktionsumfang von C++ und die Lesbarkeit von
    > Java/C# bietet, wäre wirklich nicht schlecht.

    Und ich dachte C# würde bereits die Lesbarkeit/Einfachheit von Java und den Funktionsumfang von C++ bieten... falsch gedacht.

  16. Re: Lesbarkeit?

    Autor: peter.kleibert 17.07.15 - 10:04

    Absolut richtig, die Schönheit von etwas liegt immer im Auge des Betrachters.

    Ich habe beruflich mit GO und ABAP zu schaffen. Ich bin der Meinung, dass ein sauber geschriebener ABAP-Code von jedem Programmierer, egal welche Sprache gelesen werden kann und dazu noch sehr übersichtlich und schnell lesbar ist. Hier die Gründe:
    - Schleifen, Codeblöcke werden nicht mit irgendwelchen Anonymen ]}) abgeschlossen sondern mit ENDXYZ. Beispielsweise ENDMETHOD, ENDIF, ENDWHILE. Bei Sprachen wie Java verliehrt man da gerne mal den Überblick.
    -Man benutzt meist keine technischen Datentypen, sondern legt eigene Datentypen im Dictionnary an, welche dann auf einen technischen Datentyp verweisen. Diesen muss man noch Beschreibungen hinterlegen. Dadurch hat man nur ganz selten mit Variablen und Datentypen zu schaffen, wo man keinen Schimmer über deren Bedeutung hat
    - mit dem 740er-Release wurden die Inline-Deklarationen eingeführt, welche das Coding erheblich verkürzen und unzählige Variablendeklarationen ersparen

    Mir ist bewusst, dass Go/ABAP/Rust für ganz andere Einsatzfelder erstellt wurden. Trotzdem stellt sich die Frage: Wieso müssen High-Perf-Sprachen so geschrieben sein, dass sie nur "Insider" verstehen? Das erinnert mich immer wieder an die alte Diskussion "Gui vs. Konsole", das sind doch dämlich alte Kleinkriege, wo es nur drum geht, dass einige Leute zum auserwählten Kreis gehören wollen, wenn sig zig-tausend Kommandos auswendig wissen, oder einen Code schreiben können der ohne Vorkenntnisse unlesbar ist.

    Ausserdem hinterfrage ich die Echtzeit-Anforderung von so manchem Projekt. Ich habe mehrfach in meinem Umfeld Projekte erlebt, die bloss aus prestige-Gründen (Die neue Anwendung ist ja soooo wichtig und schlussendlich hat sie niemand verwendet^^) mit der Echtzeit-Anforderung gestellt wurden, obwohl eine sauber programmierte normale Entwicklungslösung mit einer entsprechenden Hochskalierung der Hardware, es genauso getan hätte. Aber das ist halt Management...



    2 mal bearbeitet, zuletzt am 17.07.15 10:08 durch peter.kleibert.

  17. Re: Lesbarkeit?

    Autor: teenriot* 17.07.15 - 10:29

    Ist zwar Offtopic aber dieses Detail finde ich ziemlich wichtig.

    Es gibt auch ein "Zwischending" was allem gerecht wird, Lesbarkeit und Kürze.
    https://de.wikipedia.org/wiki/Einrückungsstil#Variation:_Original_K.26R_.2F_Kernel_.2F_Linux_.2F_UNIX_.2F_Stroustrup

    Alles was die Struktur definiert => neue Zeile
    "laufender Code" (mir fehlt der passende Begriff) => gleiche Zeile



    1 mal bearbeitet, zuletzt am 17.07.15 10:35 durch teenriot*.

  18. Re: Lesbarkeit?

    Autor: PiranhA 17.07.15 - 10:32

    peter.kleibert schrieb:
    --------------------------------------------------------------------------------
    > - Schleifen, Codeblöcke werden nicht mit irgendwelchen Anonymen ]})
    > abgeschlossen sondern mit ENDXYZ. Beispielsweise ENDMETHOD, ENDIF,
    > ENDWHILE. Bei Sprachen wie Java verliehrt man da gerne mal den Überblick.

    *wühäh* Da schauderts mir ja schon beim Lesen. So was finde ich extrem hässlich, weil das viel zu viel Platz einnimmt. Da verliere ich erst recht den Überblick. Ist genauso wie VB.NET. Von den Features fast gleich zu C# aber ungleich schlechter zu lesen, weil das halt aussieht wie ein Fließtext. Das ist viel zu viel Text, als das man das noch gescheit lesen könnte.
    Größere Klammern innerhalb von Methoden sollte man grundsätzlich vermeiden. Wenn eine geschwungene Klammer aus dem sichtbaren Bereich rausgeht, sollte man den Teil vielleicht in eine extra Funktion auslagern bzw. es hilft schon meist die Bedingung umzukehren. Also anstatt einem "if (x != null) { }" macht man ein "if (x == null) return;".

    > -Man benutzt meist keine technischen Datentypen, sondern legt eigene
    > Datentypen im Dictionnary an, welche dann auf einen technischen Datentyp
    > verweisen. Diesen muss man noch Beschreibungen hinterlegen. Dadurch hat man
    > nur ganz selten mit Variablen und Datentypen zu schaffen, wo man keinen
    > Schimmer über deren Bedeutung hat

    Das verstehe ich nicht ganz. Also Objekte, die keine Objekte sind? Wer seine selbstgeschriebenen Klassen nicht auf Anhieb versteht, der muss vielleicht seinen Kollegen mal auf die Finger hauen. Wenn man den Code aufgrund der Komplexität nicht sofort versteht, dann gehört eine gescheite Doku natürlich auch dazu.

    > Ausserdem hinterfrage ich die Echtzeit-Anforderung von so manchem Projekt.
    > Ich habe mehrfach in meinem Umfeld Projekte erlebt, die bloss aus
    > prestige-Gründen (Die neue Anwendung ist ja soooo wichtig und
    > schlussendlich hat sie niemand verwendet^^) mit der Echtzeit-Anforderung
    > gestellt wurden, obwohl eine sauber programmierte normale
    > Entwicklungslösung mit einer entsprechenden Hochskalierung der Hardware, es
    > genauso getan hätte. Aber das ist halt Management...

    Ich weiß ja nicht, ob du jetzt wirklich von Echtzeit-Anforderungen redest, aber wenn es die gibt, dann sind die auch nicht weg zu diskutieren. Alles was auf eingebetteten Systemen läuft, hat meistens Echtzeitanforderungen. Wenn die Software nicht auf solch einem System läuft oder in Echtzeit mit solch einem kommuniziert, dann gibt es idR auch keine Anforderung dafür. Das hat nichts mit Skalierung der Hardware oder Performance zu tun.

  19. Re: Lesbarkeit?

    Autor: Anonymer Nutzer 17.07.15 - 11:18

    PiranhA schrieb:
    --------------------------------------------------------------------------------
    > Also anstatt einem "if (x != null) {
    > }" macht man ein "if (x == null) return;".

    Das sind ja gleich zwei weitere, heiße Eisen auf einmal. Zum ersten: auch Ein-Statement-Ifs gehören m.E. geklammert, einfach, um die Fehleranfälligkeit zu minimieren und weil es konsistenter ist, immer zu klammern. Je einfacher die Regeln, desto einfacher sind sie auch einzuhalten.
    Zweitens sind premature returns umstritten, ich selber ziehe ein zeitiges return jedoch ewig tief verschachteltem Spaghetticode vor. Ist halt alles Ansichtssache.

  20. Re: Lesbarkeit?

    Autor: Anonymer Nutzer 17.07.15 - 11:21

    peter.kleibert schrieb:
    --------------------------------------------------------------------------------
    > - Schleifen, Codeblöcke werden nicht mit irgendwelchen Anonymen ]})
    > abgeschlossen sondern mit ENDXYZ. Beispielsweise ENDMETHOD, ENDIF,
    > ENDWHILE.

    Ich weiß nicht, ob ich der einzige bin, der das so macht, aber ich kommentiere geschlossene Klammern mit "} // if" oder "} // while" aus. Beim Übersetzen / Interpretieren fliegen Kommentare eh raus und in der IDE sind sie dezent hellgrau/-grün. Ich schreibe aber auch keine Betriebssysteme oder Raketensoftware, von daher...

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. CompuGroup Medical SE & Co. KGaA, Koblenz, Saarbrücken
  2. Cohline GmbH, Dillenburg
  3. Horváth & Partners Management Consultants, Stuttgart
  4. ALDI International Services GmbH & Co. oHG, Mülheim an der Ruhr

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Vivo X51 im Test: Vivos gelungener Deutschland-Start hat eine Gimbal-Kamera
Vivo X51 im Test
Vivos gelungener Deutschland-Start hat eine Gimbal-Kamera

Das Vivo X51 hat eine gute Kamera mit starker Bildstabilisierung und eine vorbildlich zurückhaltende Android-Oberfläche. Der Startpreis in Deutschland könnte aber eine Herausforderung für den Hersteller sein.
Ein Test von Tobias Költzsch

  1. Software-Entwicklung Google veröffentlicht Android Studio 4.1
  2. Jetpack Compose Android bekommt neues UI-Framework
  3. Google Android bekommt lokale Sharing-Funktion

Philips-Leuchten-Konfigurator im Test: Die schicke Leuchte aus dem 3D-Drucker
Philips-Leuchten-Konfigurator im Test
Die schicke Leuchte aus dem 3D-Drucker

Signify bietet mit Philips My Creation die Möglichkeit, eigene Leuchten zu kreieren. Diese werden im 3D-Drucker gefertigt - und sind von überraschend guter Qualität. Golem.de hat eine güldene Leuchte entworfen.
Ein Test von Tobias Költzsch

  1. Smarte Leuchten mit Kurzschluss Netzteil-Rückruf bei Philips Hue Outdoor
  2. Signify Neue Lampen, Leuchten und Lightstrips von Philips Hue
  3. Signify Neue Philips-Hue-Produkte vorgestellt

Big Blue Button: Das große blaue Sicherheitsrisiko
Big Blue Button
Das große blaue Sicherheitsrisiko

Kritische Sicherheitslücken, die Golem.de dem Entwickler der Videochat-Software Big Blue Button meldete, sind erst nach Monaten geschlossen worden.
Eine Recherche von Hanno Böck