[linux-l] Re: groovy

[Oliver Bandel]

On Sun, Aug 27, 2006 at 04:55:05PM +0200, Steffen Dettmer wrote:
> * Oliver Bandel wrote on Sun, Aug 27, 2006 at 11:23 +0200:
> > Naja, Source Code Size-Optimierung ist doch eigentlich, was man immer machen
> > sollte! 
> 
> Nee. :)
> 

Doch... wenn man es in dem Sinne versteht, wie ich es gemeint habe.
Aber dafür habe ich mich wohl zu unklar ausgedrückt... Mist verdammter.  ;-(


> > Zumindest, was die Teile im Code angeht, die keine Kommentare sind.
> > D.E.K. sagte ja, man solle nie mehr als eine Seite Code pro Funktion
> > haben, so daß es immer übersichtlich ist und man weder Scroll-Arien am
> > Schirm, noch Endlospapier beim Ausdruck braucht. Recht hat er da.
> 
> Das zwingt noch lange nicht nach wenigen Funktionen. Und Funktionen
> sollten auch nicht nur Einzeiler sein, bringt auch nicht Übersicht (wenn
> ich rekursiv tags durchgehe und am Ende feststelle: aha, es ruft update
> auf oder so :-)).

Wenn die Funktionen Einzeiler sind und dennoch erledigen, was sie sollen
und wenn das auch sehr viel ist, was die Erledigen, dann sind Einzeiler ideal! :)

Statt 10000 Lines Of Code nur noch vier oder fünf Einzeiler, fertig! :)

Aber vielleicht meinst Du es ja so, daß man statt 5 Funktionen a 40 Zeilen
eher 80 Einzeiler schreibt.... das kann in der Tat unübersichtlich werden ;-)
So hatte ich das aber nicht gemeint.

Wenn man aber in einer Zeile ausdrücken kann, wofür man sonst
wesenlich mehr braucht, und wenn der Code dennoch gut lesbar ist,
dann ziehe ich den Einzeiler selbstverständlich vor.

Ich habe aber auch schon javacode gesehen, da sind dann 40 Dateien,
in denen nur vielleicht 4 bis 12 Zeilen Code stehen.

Dann ist das IMHO eine Design-Schwäche.

Dann ist das keine verteilt ablaufende Software, sondern eine, bei
der die Funktionalität fein verteilt ist.... Aerosol sozusagen...
...beinahe schon Feinstaub.

Auch nicht so toll.



> 
> > Und wenn eine Sprache zu extreme lange Konstrukte erzwingt, und
> > Funktionen, die über viele viele Seiten gehen (weil ggf. die
> > Deklarationen schon fast eine Seite einnehmen), dann sollte man IMHO
> > die Programmiersprache wechseln. :)
> 
> naja sicher. Aber ob man das "int" vor der Deklaration von "i" weglassen
> darf oder ob man "int x_start" oder so nennt, liegt auch weniger an der
> Sprache.

Was meinst Du?
Es liegt nicht an der Sprache, ob man "int" weg lasen kann?

Worauf willst Du hinaus?




> 
> > Man will ja hinterher den eigenen Code noch verstehen. (Sollte man
> > IMHO wollen;-))
> 
> Eben. Source Code muss für Lesbarkeit optimiert werden

Ja, so habe ich das gemeint.

Der wird aber nicht lesbar durch Aufblähen.

Sinnvoll gewählte Namen, übersichtliches Code-Layout,
gute ergänzende Kommentare.


> (es sei denn, man
> braucht wirklich mal performance oder so, dann muss man halt mehr
> Kommentare schreiben).

Mehr Performance erhält man sicherlich nicht durch unsinnig gewählte
Namen oder Unsinnig lange Funktionen.
Und Hand-Optimierug ist oftmals Optimierung auf einen speziellen
Compiler hin; und das ist bis auf wenige Ausnahmefälle Unsinn.



> 
> Ich finde es immer schick, wenn man dem Code "ansieht", dass er richtig
> ist.

Ja, klar, finde ich auch.


> 
> > Und so Sachen wie HTML/XML sind bei kleineren/einzelnen Sachen noch
> > HANDhabbar; 
> 
> Naja, XML ist aber nicht für Menschen gemacht.

Wir meinen das selbe, denke ich.
Immerhin ist es i.A. Klartext, wenn man XML nutzt, und daher *auch*
für Menschen gemacht. Man muss da im Normalfalle keinen Hexeditor
anwerfen, sondern kann auch mal den Text-Editor nehmen.



> Es ist vermutlich für
> Webserverfreunde und Java gemacht. Wenn ich als einziges Werkzeug HTTP
> habe, sieht jedes Problem wie ein Textdokument aus. Oder sowas. 
> Da man eh immer Tools zu Verarbeitung braucht, hätte man mal lieber
> ASN.1 nehmen sollen, aber das ist ja praxisbewährt, uncool und ohne
> Hype. Ausserdem sind DER und Freunde auch noch effizient, ihh ;)

Aha, und ASN.1 ist dann also für menschliche leser gemacht, ja?

...tse...


Gruß,
   Oliver