Vorteile beim Programmieren?!

[picaschaf]

Kann mir mal jemand einen Anwendungsfall beim Programmieren erklären bei dem 1:1 auch nur irgendeinen Vorteil hat? Gerade da brauche ich (und alle Entwickler mit denen ich bisher zu tun hatte) Breite und nicht Höhe.

[anonym]

also ich programmiere auf einem hochkant full-hd bildschirm. ist in der breite bissl eng manchmal, aber ich kann auch etwas größere funktionen komplett überblicken, ohne immer sofort scrollen zu müssen.

[Gontah]

picaschaf schrieb:
--------------------------------------------------------------------------------
> Gerade da brauche ich (und alle
> Entwickler mit denen ich bisher zu tun hatte) Breite und nicht Höhe.

Programmiert ihr in LabView? Da sind manchmal 2 Monitore nebeneinander zu eng *lol*

Höhe brauch man, damit die längeren Funktionen auf den Bildschirm passen.

[Suven]

In den allermeisten Sprachen / Anwendungsfällen sind sehr breite/lange Zeilen ein Indiz für einen schlechten Programmierstile.

Ich fände das praktisch um mehr Source-Code zu sehen, oder aber um das Resultat und den Code untereinander anzeigen zu können.

[tbxi]

Idealerweise sollten Funktionen weder zu lang noch 'zu breit' sein.

[Endwickler]

tbxi schrieb:
--------------------------------------------------------------------------------
> Idealerweise sollten Funktionen weder zu lang noch 'zu breit' sein.

Ja, da kommt man schon ins Grübeln, wenn es "syntax error in zeile 630175" heißt.

[Strongground]

Ihr tut ja alle so, als würdet ihr den ganzen Tag selbst entwickeln.
Ich verbringe leider den größten Teil des Tages damit, den schrecklichen (daher "Legacy" genannten) Code anderer zu modifizieren.
Der geht dann meistens über 6-7 Zeilen ohne WordWrapping.

[picaschaf]

8 von 24 Stunden wird entwickelt ;)

Weder noch, eine Funktion soll auf eine Seite passen, die Breite brauche ich nicht wegen der breiten Zeilen, sondern um 3-4 Dateien (bei 80 Zeichen) nebeneinander zu haben.

[Das Original]

> Höhe brauch man, damit die längeren Funktionen auf den Bildschirm passen.

was für schriftgrössen benutzt ihr leutchen denn, um "längere funktionen" nicht mehr in einer zeile zu bekommen?

selbst mit einem halben dutzend 64 bit konstanten und einer kombination aus arithmetik und booleans sollten doch 1920 im normalfall langen.

ich glaube, das einzige, was ich jemals geschrieben habe, was in geneva 9 nicht mehr in eine zeile passte, ist die mehrere schritte umfassende konvertierung von R,G,B values in den l*u*v farbraum.



3 mal bearbeitet, zuletzt am 20.11.14 23:05 durch Das Original.

[RobertFr]

> geneva 9

Also zuallererst: wer kann ganz real mit einer 9pt Schrift programmieren? Das geht doch garnicht. Damit kann man vielleicht Fließtext unkontrolliert heruntertippen... aber doch nicht wirklich mit arbeiten!

Und dann auch noch Geneva? Echt? Dieser Font ist pure Folter: Großbuchstaben werden im Vgl. zu allem Anderen überproportional betont. Alles andere darf man dann raten, weil visuell oft nicht erkennbar ist, wo die Grenzen zwischen Operatoren und Variablen, oder gar Strings liegen.

Kleines Praxisbeispiel, schau Dir einfach mal das in Geneva 9 an: "||Iililil||"

Oder ".._oO0üuöoäa0ÜUÖOÄAOo_.."

Oder alles Andere,.. dieser Font ist pure Folter für die Augen.

[RobertFr]

> In den allermeisten Sprachen / Anwendungsfällen sind sehr breite/lange
> Zeilen ein Indiz für einen schlechten Programmierstile.

Naja, das ist das so ähnlich wie mit der Henne und dem Ei.

Breite Zeilen sind ungern gesehen, weil sie sich mit den üblichen HID so schlecht handhaben lassen.

Und wenn mehrere Programmierer mit dem Source zurechtkommen sollen, dann braucht es einen Konsens, mit dem jeder arbeiten kann.

Breite/Lange Zeilen müssen aber an und für sich nichts schlechtes sein ;-)

[Moe479]

man kann auch innerhalb von klammern nach jedem seperator umbrechen und entsprechend einrücken, wenn man es schlanker möchte, es ist eine reine frage der vereinbarten konventionen, bei einigen sprachen die assoziative übergabe parameter anordnug für funktions/methodenaufrufe erlauben ist das imho sogar pflicht:

z.b.
foo (parameter3=c, parameter1=a, parameter2=b, parameter4=d);

finde ich wesentlich unschöner zum lesen als:

foo (
- > parameter3=c,
- > parameter1=a,
- > parameter2=b,
- > parameter4=d
);



3 mal bearbeitet, zuletzt am 21.11.14 01:29 durch Moe479.

[theonlyone]

RobertFr schrieb:
--------------------------------------------------------------------------------
> > In den allermeisten Sprachen / Anwendungsfällen sind sehr breite/lange
> > Zeilen ein Indiz für einen schlechten Programmierstile.
>
> Naja, das ist das so ähnlich wie mit der Henne und dem Ei.
>
> Breite Zeilen sind ungern gesehen, weil sie sich mit den üblichen HID so
> schlecht handhaben lassen.
>
> Und wenn mehrere Programmierer mit dem Source zurechtkommen sollen, dann
> braucht es einen Konsens, mit dem jeder arbeiten kann.

Eben, der Konsens ist durchaus der relevante Punkt.

Den egal wie "schlecht" der Code ist, solange die Entwickler alle verstehen was der macht ist der Code zumindest zu benutzen (auch wenn es absolut sinnvoll wäre das ganze zu refactoren).

> Breite/Lange Zeilen müssen aber an und für sich nichts schlechtes sein ;-)

Im Prinzip ist es sehr wohl ein ziemlich starker Indiz für ein paar schlechte Programmier Angewohnheiten.

Thema Höhe hätten wir das Thema das eine Funktion eben NICHT mehr eine atomare Aktion darstellt, sondern viel mehr macht als sie eigentlich soll.
Oder kurz gesagt, die riesen Funktion sollte in mehrere kleinere Funktionen aufgeteilt werden (da es sehr wahrscheinlich ist das Teile davon sowieso nochmal irgendwo verwendet werden).

Gerade wenn die Funktionen per Unit Test abgedeckt werden sieht man doch relativ schnell ob die Funktion schlichtweg zu viel macht, da man viel zu viele Test-Cases braucht für nur 1 Funktion.
Am aller offensichtlichsten sind die Funktionen die mit extrem vielen parametern daher kommen und schlichtweg Funktionalität nicht im Objekt selbst abhandeln, das bläht die aller meisten Funktionen auf und das ist schlichtweg schlechter Stil und unnötig.


Gerade NullPointer sollte es in "sauberem" Code praktisch nie in Chain Calls geben, da jeder Chain call für sich prüfen muss ob "null" überhaupt akzeptiert wird, und wenn ja, muss das eben immer abgefangen werden. Nennt sich letztlich law of demeter und wird sehr oft ignoriert, weil der chain call eben der 1-Zeiler ist und das ganze "sauber" zu machen verlangt mehr Zeilen in mehr Klassen (gerade wenn Code modeliert werden muss, hat das den Effekt das Programmierer dazu zu faul sind und lieber alles in 1 Funktion packen).



Beim Thema Breite ist erstmal genannt das Funktionen lieber großzügig lang benannt sind, damit immer klar ist was die Funktion tut, allein vom namen her.
Kann man einer Funktion keinen sinnvoll kurzen und aussagekräftigen namen geben ist das ein klares Indiz das die Funktion wohl schlichtweg "zu viel" tun will (solche Funktionen, die letztlich nur viele andere Teilfunktionen aufrufen sollten selbst wieder einen klaren Ablauf darstellen, als Beispiel "Pizza backen" wäre der große Aufruf und die Unterfunktionen definieren die Grobschritte , sowas wie "Teig zubereiten" , was wiederrum klar definierte Unterschritte hat etc. etc.) , wird schlichtweg zu wenig gemacht, da hat man dann kryptische Namen und am besten noch Abkürzungen und Missverständnisse sind vorprogrammiert.



Bedeutet, die reine MENGE an Code und Zeilen wird mit gutem Stil (im Sinne von deutlich, aussagekräftige Namen, klare Zustands und Fehlerbehandlung) einfach größer, was aber gerade nicht bedeutet das man 1-Zeiler schreibt die viel zu viel Funktionalität enthalten und eben auch nicht bedeutet das man einzelne riesen Funktionen baut.

*Als richtlinie für die Orientierung kann man durchaus sagen eine Funktion die länger als 80-Zeilen Code enthält und damit nicht mehr auf einen Bildschirm passt, hat klare Schwächen die man sinnvoll refactoren "sollte".
Die Standard Breite vor einem Zeilen-Wrap liegt auch um die 100 Zeichen, braucht man mehr als das, ist man gut getan die Chain calls in lokale Variablen zu stecken und diese mit sinnvollen Namen zu belegen.


So oder so, es wird immer Legacy Code geben und Gründe von Zeitdruck oder schlichtweg unverständnis warum man doch gut beraten ist einen Hochkannt Bildschirm zu benutzen ; aber es bleibt ein sehr klares Zeichen das der Code einfach nicht in einem "ordentlichen" Zustand ist (was nicht bedeutet das er Funktional falsch wäre, nur unnötig komplexer zu lesen).

[picaschaf]

Bzgl. Font, ich benutze Source Sans 10pt. Damit bekomme ich auf meinem externen 23" mit 1920 in der Breite 3 Dateien und auf dem MacBook Display 2 Dateien nebeneinander. Wobei auf dem großen Display die dritte Datei idR. Referenz oder Dokumentation ist.

[timo.seikel]

ich seid alle ganz schön verwöhnt. ich arbeite noch mit einer 3270 Emulation(Großrechner). da sieht man maximal 24 Zeilen vom Code mit einer breite von 80 Stellen. Unabhängig von der Auflösung. :D

[picaschaf]

Ach auch das ist nicht schlimm. Hin und wieder, vorallem unterwegs ohne zweiten Monitor arbeite ich auch gerne mit 10 offenen screen Sessions. Gut, das Terminal bzw. die Emulation gibt mehr her, aber nachdem man einmal, bewusst, mit 80 Zeichen Breite gearbeitet hat, erkennt man, dass das auch heute noch Sinn macht ;)