Welche Programmiersprachen sind genormt?

blue-tec

Na, so hat jeder halt seine Meinung, ich bleibe sogar meist unter den 80 ich finde halt alles was stark drüber ist unübersichtlich:

1. fürs Lesen
2. fürs Arbeiten mit mehreren Fenstern nebeneinander
3. fürs Drucken in Dokumenten oder auf Webseiten

Das mir den Webseiten habe ich hier auch schon gesehen, wo ich dann echt lang nach links scrollen musste um das Ende der Zeile zu sehen, fand ich nicht schön. Ich rede hier natürlich nur von C++.

Aber Geschmäcker sind ja verschieden.

Christoph

mngbd schrieb:

Gregor schrieb:

Ich zeige euch mal ein paar Variablennamen, damit Ihr sehen könnt, zu was das führt...

Andererseits ist call-with-current-continuation auch irgendwie seltsam. Die Diskussion "lange Namen gegen kurze" erinnert mich in letzter Zeit immer an zwei Maler, die streiten, welche Farben schöner sind.

Bei einem Namen wie "call-with-current-continuation" kann ich mir ohne in der Doku nachzuschauen denken, was da ungefähr passieren wird.
Bei einem Namen wie "chsml" aus Gregors Posting fällt mir das in jeder Hinsicht schwieriger.

Ich finde es eindeutig, welches Namensschema ich bevorzugen würde.

tntnet

CSL schrieb:

knivil schrieb:

Anzahl der Zeichen / Anzahl der Zeile, vielleicht Leerzeilen oder so heraus filtern.

Ich meinte jetzt eher nicht manuell, ich wollte schauen was der durchschnitt eines ganzen Projektes ist, die Code Metrics zeigen nur die Zeilen anzahl, aber nicht die länge.

Das geht doch einfach auf der Kommandozeile:

find . -name '*.cpp' -o -name '*.h'|xargs awk 'length($0) > 0 { Z=Z+1; L=L+length($0)} END { print L/Z }'

Ich liebe Unix/Linux mit seiner Shell .

Dravere

blue-tec schrieb:

Aber Geschmäcker sind ja verschieden.

Schriftgrössen und Schriftarten auch

Grüssli

knivil

mngbd schrieb:

Gregor schrieb:

Ich zeige euch mal ein paar Variablennamen, damit Ihr sehen könnt, zu was das führt...

Andererseits ist call-with-current-continuation auch irgendwie seltsam. Die Diskussion "lange Namen gegen kurze" erinnert mich in letzter Zeit immer an zwei Maler, die streiten, welche Farben schöner sind.

Keine Ahnung, warum sie sich fuer den langen Namen entschieden haben. Wenn die Kurzschreibweise nicht verfuegbar ist:

(define call/cc call-with-current-continuation)

Bashar

Gregor schrieb:

Ich arbeite mit altem Fortran-Code. Damals war es so, dass der Code erst in der 7. Spalte anfing und nach der 72. Spalte aufhören musste. Ich zeige euch mal ein paar Variablennamen, damit Ihr sehen könnt, zu was das führt...

Die Variablennamen sind so, weil es eine weitere Regel gibt, die die Länge von Variablennamen begrenzt. Mit der Anzahl der Spalten hat das rein gar nichts zu tun.

Gregor schrieb:

Ich arbeite mit altem Fortran-Code. Damals war es so, dass der Code erst in der 7. Spalte anfing und nach der 72. Spalte aufhören musste. Ich zeige euch mal ein paar Variablennamen, damit Ihr sehen könnt, zu was das führt...
chsml, dagrf,dagrfd,dagrfu,dagrr,dagrrd,dagrru,dagrt,
dagrtd,dagrtu,drdr,dzdfs,dzdr,dzdtr,grf,grfd,grfu,grr,
grrd,grru,grt,grtd,grtu,rdf,rdfd,rdff,rdffd,rdffu,rdfu,
rdr,rdrd,rdrf,rdrfd,rdrfu,rdrrd,rdrru,rdrt,rdrtd,rdrtu,
rdru,rdt,rdtd,rdtf,rdtfd,rdtfu,rdtt,rdttd,rdttu,rdtu,
ro,ro2,rod,rou,rv1,rv2,rv3,rvsin1,sint1,sint2,tant1

So ein Blödsinn als wenn Zeichebreite von ca. 80 etwas mit der Bezeichnerlänge in C++ zu tun hat, worum es hier ja geht. *ankopfklatsch

muemmel

Hi Dravere,

Dravere schrieb:

Ehm, ist das nicht einfach nur eine Richtlinie? Eine Richtlinie ist wohl was anderes als eine Normierung.

ja sicher. Ich hatte es extra als Positivbeispiel angegeben, dass es nur eine Richtlinie ist und keine Norm. Das erweitert die persöhnliche Freiheit.

Programmierstile sind in erster Linie eine Gewöhnungsfrage. Das Argument "Ich komme aus C, daher verwende ich in allen Programmiersprachen den C Stil" halte ich für sehr verkehrt.

Keine Bange, ich will nicht überall C-Stil reinbringen. Aber Regelungen die ich selbst als "unsauber" empfinde werde ich mir nicht zu eigen machen. Und da gibt es eben für mich Grundsätze, wie z.B. dass bei mir um einen logischen Ausdruck Klammern gehören. Auch wenn Stilrichtlinien das an bestimmten Stellen als Falsch ansehen. Genauso stört es mich, daß in Pascal/Delphi Proceduren und Funktionen ohne Argumente keine Klammern haben. In C... ist das wesentlich konsequenter gelöst. Was eine Funktion ist hat Klammern und wenn keine Argumente gebraucht werden bleiben sie leer. Aber auf einem Delphi-Papierausdruck sieht man an der reinen Syntax nie, ob etwas eine Variable oder Funktion ist.

Oder eben dass bei mir vor und hinter jeder Klammer und Doppelpunkten ein Leerzeichen zu stehen hat. Dem Compiler ists sowieso schnurz wie es aussieht, solange die Syntax eingehalten wird. Aber ein Quelltext ist nun mal kein Brief an Herrn Compiler und auch nicht in erster Linie für andere, sondern der der am meisten mit meinen Quellen arbeitet bin ich selbst. Und ich lege da sehr viel Wert drauf, dass ich die einzelnen Teile eines Ausdrucks auch ohne Brille gut separiert habe.

Es lohnt sich durchaus für alle Programmiersprachen, sich einen anderen Stil anzugewöhnen, bzw. einfach einigermasen der Richtlinie der Sprache zu folgen. Das hilft beim Umschalten bei der Denkweise, wie man programmieren muss. Anderes Werkzeug, andere Handhabung.

Da ist schon was wahres dran. Da baut man dem Gehirn quasi eine Eselsbrücke. Das halte ich ja auch so. Auch wen ich derzeit überwiegend (leider) in Delphi arbeite (muss).

Aber bestimmte Dinge, wie das "80-Zeichen-Dogma" sehe ich einfach nicht mehr ein. Klar, Bandwürmer programmiere ich auch nicht. Aber wenn ein Ausdruck länger ist als die 80 Zeichen, dann breche ich den nicht extra künstlich um (es sei denn es dient der besseren Verständlichkeit) und Funktionsaufrufe die durch die aktuellen Parameter länger werden bleiben bie mir generell in einer Zeile. Gerade bei OOP kommen da doch schnell mal recht lange Ausdrücke zusammen.

Auch Zeilenendkommentare stehen bei mir meist nicht direkt am Quelltext, sondern alle säuberlich untereinander ab Position 80 oder 100.
Sicher entspricht das nciht den Programmierrichtlinien, aber ich hasse es, wenn ich in den Kommentaren suchen muss, ob da auch ein bisschen Quelltext dazwischen versteckt ist.

Das sind alles Gewohnheiten, die sicher jeder anders sieht, aber da mein Quelltext in erster Linie ein Brief an mich selber ist, schreibe ich ihn halt so, wie er für mich am übersichtlichsten ist (und bei Bedarf für andere zumindest mit vertretbarem Aufwand lesbar ).

Gruß Mümmel

Es ist ja erwiesen das eine zu lange Zeichenbreite nicht gut zu lesen ist, da braucht man gar nicht darüber diskutieren und hat auch nix mit persönlichen Geschmack zu tun. Warum es außerdem noch gut ist nicht zu lange Zeilen zu produzieren wurde hier auch schon dargelegt, und es kamen keine wirklichen Gegenargumente.

Für das Lesen sind lange Zeilen einfach nicht gut, das ist wissenschaftlich erwiesen fertig aus, so ist es und so wird es auch bleiben.

ipsec

Natürlich sind sehr lange Zeilen schlecht, aber 80 zeichen ist meiner Meinung nach einfach zu wenig.
Beispiel aus einem meiner Projekte (zwar C#, ist ja aber egal):

return new ManagementClass(scope, new ManagementPath(classname), new ObjectGetOptions());

Ich hab ja nun wahrlich nicht zu lange Variablennamen verwendet, auch sind Bezeichner wie ManagementClass nicht voll qualifiziert (mit angegebenen Namensraum), trotzdem ist diese Zeile schon über 80 Zeichen lang. Dann steht sie natürlich in einer Funktion in einer Klasse in einem Namensraum, macht also nochmal 3 Einrückungsebenen á 4 Leerzeichen.
Trotzdem passt diese Zeile sehr gut auf meinen Bildschirm und kommt mir alles andere als zu lang vor.

Hätte ich jetzt ein strenges 80-Zeichen-Limit, sehe das so aus:

return new ManagementClass(scope, new ManagementPath(classname),
    new ObjectGetOptions());

und da stört mich der künstliche Umbruch im Lesefluss wesentlich mehr, als die 20 Zeichen zu viel.

Das in Zeitschriften und Zeitungen sehr schmale Spalten benutzt werden, hat übrigens den Grund, das der geübte Leser dann häufig die gesamte Wortgruppe auf der Zeile komplett erfassen kann und somit die horizontale Augenbewegung beim Lesen gänzlich entfällt. Da Programmiersprachen keine natürlichen Sprachen sind, trifft das da aber nicht zu.

Wenn dann schon so

return new ManagementClass(scope, 
                           new ManagementPath(classname),
                           new ObjectGetOptions());

und alles is schön..

ipsec

asdfasdf schrieb:

Wenn dann schon so

return new ManagementClass(scope, 
                           new ManagementPath(classname),
                           new ObjectGetOptions());

und alles is schön..

Gut, sieht etwas besser aus, aber wozu? Übersichtlicher als alles in eine Zeile finde ich das persönlich nicht. Das kommt mir eher so vor, als würde man krampfhaft versuchen, eine Zeilenbeschränkung einzuhalten.

Versteht mich nicht falsch: zu lang darf die zeile auch nicht sein. Sowas wie

CreateWindowEx(NULL, "MyWindowClassName", "Meine Application V1.0", WS_OVERLAPPEDWINDOW | WS_VISIBLE, 50, 50, SCR_WIDTH, SCR_HEIGHT, NULL, NULL, hInstance, NULL);

ist zu lang. Zumal die einzelnen Parameter nicht deutlich werden. Hier ist für jeden Parameter eine Zeile mit passendem Kommentar übersichtlicher.

Aber nur 80 Zeichen pro Zeile ist mir zu wenig. Ich denke eine m.E. sinnvolle Grenze liegt bei etwa 120 Zeichen. Das aber auch nicht dogmatisch. Wenn eine Zeile aus zwingenen Gründen mal länger sein muss und andere Möglichkeiten nicht zur Übersicht beitragen, dann muss sie eben mal länger sein. Und auf jeden Fall sollte man keine Zeilen umbrechen, weil sie z.B. 121 oder 122 Zeichen lang sind.

berniebutt

Gregor schrieb:

...
chsml, dagrf,dagrfd,dagrfu,dagrr,dagrrd,dagrru,dagrt,
dagrtd,dagrtu,drdr,dzdfs,dzdr,dzdtr,grf,grfd,grfu,grr,
grrd,grru,grt,grtd,grtu,rdf,rdfd,rdff,rdffd,rdffu,rdfu,
rdr,rdrd,rdrf,rdrfd,rdrfu,rdrrd,rdrru,rdrt,rdrtd,rdrtu,
rdru,rdt,rdtd,rdtf,rdtfd,rdtfu,rdtt,rdttd,rdttu,rdtu,
ro,ro2,rod,rou,rv1,rv2,rv3,rvsin1,sint1,sint2,tant1
[/code]
Alles klar? Die 80-Spalten-Regel ist IMHO rein geschichtlich zu begründen und die sollte man sich auch nicht schön reden. IMHO sollte man heutzutage Zeilen so lang schreiben, wie man sie braucht, so lange es halbwegs im Rahmen bleibt. Starre Regeln sind in dem Zusammenhang kontraproduktiv und führen zu schlechtem Code, weil man deshalb an anderen Stellen Abstriche macht.

Die 80-Spalten unter FORTRAN kamen von dem üblichen Eingabemedium der Lochkarten, da war nur Platz für 80 Zeichen pro Lochkarte. Man konnte Code aber beliebig auf Folgezeilen aufteilen. War alles sehr gut durchdacht und Folgezeilen hat man selten gebraucht!

Den mitgeteilten Schrott wegen der Bezeichner kannst du vergessen. Gut, die Namensgebung war oft auf 8 signifikante Zeichen begrenzt. Doch auch damit konnte man gut leben.

Mit der Standardisierung und der Normung des Sprachumfangs hat das nun rein gar nichts zu tun. Dies war auch unter FORTRAN bereits hervorragend gelöst. Standards sind und bleiben gut. Ohne diese setze ich keinen Compiler ein. Ich will mich darauf verlassen, dass morgen alles so läuft wie ich es heute gelöst habe. :p

knivil

Ich habe mal gesucht ob, z.B. Haskell standardisiert ist. Es gibt zwar ein Komitee und einen offiziellen Report zur Sprache, aber kein ISO, ECMA oder ANSI.

Was ist also Standard? Muss immer eine Organisation dahinter stehen, bevor es als "Standard" akzeptiert wird?

berniebutt

knivil schrieb:

Was ist also Standard? Muss immer eine Organisation dahinter stehen, bevor es als "Standard" akzeptiert wird?

Nein, das regeln die Programmierer weltweit schon selbst. Man nimmt einfach das, worauf man sich möglichst überall und lange sicher verlassen kann! Programmierung ist kein Selbstzweck, sondern ein Hilfsmittel zur Lösung konkreter IT-Aufgaben. Wenn diese Hilfmittel gut sind, nehme ich sie und vergesse die anderen.

Zeus

knivil schrieb:

Ich habe mal gesucht ob, z.B. Haskell standardisiert ist. Es gibt zwar ein Komitee und einen offiziellen Report zur Sprache, aber kein ISO, ECMA oder ANSI.

Was ist also Standard? Muss immer eine Organisation dahinter stehen, bevor es als "Standard" akzeptiert wird?

Wenns eine akzeptierete Instanze gibst, reicht es, meistens durch den Macher unterstützt. Bei Java ist es die JCP.org.

knivil

Also kann man davon ausgehen, das (fast) alle Sprachen standardisiert sind. (Was diese Diskussion irgendwie ..)

Dravere

muemmel schrieb:

Keine Bange, ich will nicht überall C-Stil reinbringen.

muemmel schrieb:

In C... ist das wesentlich konsequenter gelöst.

Ehm ... ok

muemmel schrieb:

Gerade bei OOP kommen da doch schnell mal recht lange Ausdrücke zusammen.

Das musst du mir mal erklären. OOP sollte meiner Meinung nach gerade das Gegenteil bewirken. Die Funktionalität ist in kleine Teile in die Objekte gekapselt. Funktionsaufrufe sollten zum Beispiel deswegen deutlich kürzer werden, weil man nicht alles an das Objekt übergeben muss, schliesslich hat es selber einen Status.

muemmel schrieb:

Auch Zeilenendkommentare stehen bei mir meist nicht direkt am Quelltext, sondern alle säuberlich untereinander ab Position 80 oder 100.

Ich habe meistens gar keine Kommentare in den Funktionen drin. Alles über die Funktion steht vor der Funktion als Kommentarblock. Da ich die Funktionen kurz halte, ist dies auch kein Problem.

muemmel schrieb:

Das sind alles Gewohnheiten, die sicher jeder anders sieht, aber da mein Quelltext in erster Linie ein Brief an mich selber ist, schreibe ich ihn halt so, wie er für mich am übersichtlichsten ist (und bei Bedarf für andere zumindest mit vertretbarem Aufwand lesbar ).

Meiner Meinung nach sollte man Quellcode immer so schreiben, dass er für andere lesbar ist. Dadurch wird er nämlich automatisch auch für dich lesbar, denn du bist nicht irgendwas anderes als die anderen. Oder bist du kein Mensch? Dann bitte ich vielmals um Entschuldigung

ipsec schrieb:

Natürlich sind sehr lange Zeilen schlecht, aber 80 zeichen ist meiner Meinung nach einfach zu wenig.
Beispiel aus einem meiner Projekte (zwar C#, ist ja aber egal):
return new ManagementClass(scope, new ManagementPath(classname), new ObjectGetOptions());

Wie ich schon mal gesagt habe, bin ich auch kein Verfechter der strikten 80 Zeichen Breite, aber dein Code kann man übersichtlicher machen. Und zwar nicht nur wegen der Breite, sondern auch wegen der Verschachtelung.

var managementPath = new ManagementPath(classname);
var objectGetOptions = new ObjectGetOptions();

return new ManagementClass(scope, managementPath, objectGetOptions);

80 Zeichen Breite unterschritten und diese ineinander Verschachtelung auseinander genommen. Mit solchen Zwischenergebnissen kann man oft die Lesbarkeit erhöhen und zudem ganz nebenbei die Zeilenbreite reduzieren

TypoTipps schrieb:

Für das Lesen sind lange Zeilen einfach nicht gut, das ist wissenschaftlich erwiesen fertig aus, so ist es und so wird es auch bleiben.

Und wenn du das noch mit Quellen untermauern würdest, hätte der Beitrag fast noch einen Sinn ergeben.

Grüssli

Dravere

knivil schrieb:

Also kann man davon ausgehen, das (fast) alle Sprachen standardisiert sind. (Was diese Diskussion irgendwie ..)

*hüstel*

Dravere schrieb:

Ehm, um mal eines klar zu machen:
Standard ist ungleich offizielle Normierung.

Der Threadersteller wollte irgendwie alles offiziell normieren, zumindest gingen seine Argumente darauf hinaus.

Grüssli

knivil

Ja, ich habe nicht alles gelesen. Ich frage mich gerade, wie man von Normierung von Sprachen auf Anzahl der Zeichen in einer Zeile kommt? Aber: Ich sehe keinen Unterschied zwischen Standard und Normierung.

@Davere: Ich habe mir deinen Post nachtraeglich durchgelesen. Dort gehen de facto Standard und Standard an sich Hand in Hand. Einen Unterschied zur Normierung oder Norm sehe ich trotzdem nicht, wenn sich einfach nur genuegend Leute einig sind. Wenn du magst kannst du antworten, aber irgendwie mag ich nicht ganz so gerne darueber diskutieren, wohl weil sich der OP einfach nur wegen was auskotzen wollte.

zumindest gingen seine Argumente darauf hinaus

Ich habe keine Argumentationsstruktur oder Argumente erkannt.