Welche Programmiersprachen sind genormt?

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.

Dravere

knivil schrieb:

Aber: Ich sehe keinen Unterschied zwischen Standard und Normierung.

Ich habe meinen Beitrag auch nochmals durchgelesen, ich denke, es kommt noch nicht so gut heraus. Habe viel zu wenig strikt zwischen den Begriffen Normierung und Standard unterschieden. Zwar gemeint, aber nicht geschrieben
Ist der Wikipedia Artikel zur Normierung vielleicht verständlicher?
http://de.wikipedia.org/wiki/Normung

knivil schrieb:

Dort gehen de facto Standard und Standard an sich Hand in Hand.

Standard und defacto Standard sollen auch Hand in Hand gehen. Der Unterschied besteht zur Normierung. ISO macht Normierungen; eine Spezifikation, an welche sich alle halten, ist einfach "nur" ein Standard.

Grüssli

Artchi

Defacto Standard ist meistens Industriestandard. Z.B. sind MS-Windows und Word-Doc-Format unbestreitbar ein Industriestandard. Nur halt keine Standards.

muemmel

Hi Dravere,

Dravere schrieb:

Ehm ... ok

ich sehe das nicht unbedingt als C-Fanatismus an, wenn ich es für mich als Grundlage ansehe, daß ein in sich abgeschlossener logischer Ausdruck in Klammern gehört.

Das musst du mir mal erklären. OOP sollte meiner Meinung nach gerade das Gegenteil bewirken.

nicht unbedingt bei der VCL.

DatamoduleXYZ->Tabelle123FeldABC->AsInteger = DatamoduleABC->Tabelle321FeldXYZ->AsInteger + IntEditNummer->Asinteger;

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.

Bei eigenen Komponenten kommentiere ich da lieber ein wenig mehr, speziell was nicht unbedingt direkt ersichtlich ist, weil es z.B. aus Eigenheiten von Basisklassen resultiert. Außerdem hat der Kommentar da ein wenig qualitätssichernde Funktion. Wenn der logisch und zum Quelltext passend ist hab ich eine höhere Sicherheit daß es OK ist.

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

Nun, mein Vorgesetzter aus meiner Zeit bei VEB-Gleichschritt war da teilweise anderer Meinung was das Menschsein bei mir anbelangt.
Wenn ich ehrlich bin hab ich aber gemerkt, daß ich ne ganze menge an Gewohnheiten noch aus der Zeit mit rübergenommen habe, als ich mir noch nicht richtig dessen bewust war, daß ich eigentlich eine Brille tragen müsste.
Dazu zählt eben auch, daß ich es hasse, wenn Funktionsnamen und erster Argumentnamen und eventuell noch umschließender Funktionsname in einem Aufruf eine einzige zusammengehörende Zeichenkette ist, die nur durch spillrige ( getrennt ist.

Gruss Mümmel

*john 0

Anonymous schrieb:

Hallo,
mich würde mal interessieren welche Programmiersprachen denn so genormt sind alla ISO etc..

Eine nicht vollständige Liste von normierten Programmiersprachen

Ada (ISO/IEC 8652)
C (ISO/IEC 9899)
C++ (INCITS/ISO/IEC 14822)
Cobol (INCITS/ISO/IEC 1989)
Fortran (ISO/IEC 1539-1 bis -3)
Modula-II (ISO/IEC 10514-1 bis -3)
Pascal (INCITS/ISO/IEC 7185)
Prolog (INCITS/ISO/IEC 13211-1 bis -2)
Smalltalk (ANSI INCITS 319)
SQL (ISO/IEC 9075-1 bis -14)

Zeus

Anonymous schrieb:

Hallo,
mich würde mal interessieren welche Programmiersprachen denn so genormt sind alla ISO etc..

Haben wir nun den Funcoder aus dem Board getrieben, weil wir keine blinde Norminierungsfanboys sind? o.o

Nein, das war nicht der Grund. Aber du hast ihn indirekt genannt, ich war nie dafür alles zu normieren und habe das oft genug geschrieben aber das hat keinen interessiert, genauso wenig hat keiner begriffen worum es mir eigentlich ging oder ihr konntet mein Beispiel nicht auf das Programmieren übertragen und das sollte man schon erwarten können, egal wie blöd das Beispiel gewählt ist.

Was soll ich in einem Forum wo mich viele missverstehen, es ist mir ehrlich gesagt zu anstrengend alles immer wieder und immer wieder zu erklären. Und das war ein einfaches Thema.

Entweder konntet oder wolltet ihr nicht verstehen, in beiden Fällen ist das keine Grundlage für eine Kommunikation.

Also macht es schön.

knivil

Klar, wir sind das Problem.