Gross- oder Kleinschreibung

[Paul]

Moin,
Tags wie z.B. <img>, <div> etc. werden heutzutage klein geschrieben (früher war's wohl mal anders <DIV>?).
Wenn man Farben nun mit #AA00FF angibt, werden diese Zeichen nun auch klein geschrieben?

Beides funktioniert, klar. Aber nur so um es mal zu wissen.

Paul

[Cheatah]

Hi,

Tags wie z.B. <img>, <div> etc. werden heutzutage klein geschrieben (früher war's wohl mal anders <DIV>?).

in HTML ist die Groß- und Kleinschreibung egal. XHTML erlaubt nur Kleinschreibung. Somit gilt: Klein ist immer richtig, groß nicht. Logische Konsequenz: Immer klein schreiben.

Warum es früher so üblich war, die Großschreibung zu nutzen, ist mir übrigens nie so richtig klar geworden. Das erhöht nicht gerade die Lesbarkeit.

Wenn man Farben nun mit #AA00FF angibt, werden diese Zeichen nun auch klein geschrieben?

In CSS ist (bei allem, was von CSS definiert ist) die Groß- und Kleinschreibung wieder egal. Bei RGB-Farbcodes hat sich eher die Großschreibung eingebürgert. Erstaunlicherweise halte ich es hier für lesbarer, kann dafür aber keinen Grund nennen.

Cheatah

[Paul]

Vielen Dank!

[Gernot Back]

Hallo Cheatah,

»» Tags wie z.B. <img>, <div> etc. werden heutzutage klein geschrieben (früher war's wohl mal anders <DIV>?).

in HTML ist die Groß- und Kleinschreibung egal. XHTML erlaubt nur Kleinschreibung. Somit gilt: Klein ist immer richtig, groß nicht. Logische Konsequenz: Immer klein schreiben.

Für den Quellcode selbst würde ich diese Strategie bejahen, denn dann kann man nichts falsch machen. Wenn wir uns hier aber im Forum miteinander über Quellcode austauschen und dies nicht tun, indem wir ihn als über längere Passagen als Quellcode zitieren, sondern indem wir schnell mal über die Vor- und Nachteile oder den Sinn von z.B. DIV-Elemente/Div-Elementen und TABLE-Elementen/Table-Elementen reden, bevorzuge ich die Versalienschreibweise (also durchgängige Schreibung in Großbuchstaben).

"TABLE-Elemente" wären in meinem Sprachgebrauch auch etwas anderes als "Tabellen-Elemente", denn wenn ich von Letzterem rede, dann meine ich dies als Oberbegriff und schließe deren Nachfahrenselemente (TBODY-, TR-, TD- etc. -Elemente) als Unterbegriffe mit ein.

SELFHTML hat in seiner Doku die Differenzierung, wann es metasprachlich über einzelne Html-Elemente spricht und wann objektsprachlich dadurch geregelt, dass es die metasprachlich verwendeten Begriffe mit dem CODE-Element auszeichnet und diese dann in blauer Schrift erscheinen.

Das ist hier im Forum zwar auch möglich (obwohl es hier gerade umgekehrt dann nicht in blau geschrieben steht), ich fände es aber übertrieben, bei jedem metasprachlichem Gebrauch einzelner Begriffe etwa schon von <table>-Elementen zu sprechen.

Es widerstrebt mir auch, ein zusammengesetztes Nomen mit einem Kleinbuchstaben zu beginnen oder gar mit einer spitzen Klammer.

Gruß Gernot

[Cheatah]

Hi,

Für den Quellcode selbst würde ich diese Strategie bejahen, denn dann kann man nichts falsch machen. Wenn wir uns hier aber im Forum miteinander über Quellcode austauschen und dies nicht tun, indem wir ihn als über längere Passagen als Quellcode zitieren, sondern indem wir schnell mal über die Vor- und Nachteile oder den Sinn von z.B. DIV-Elemente/Div-Elementen und TABLE-Elementen/Table-Elementen reden, bevorzuge ich die Versalienschreibweise (also durchgängige Schreibung in Großbuchstaben).

ich kann das nachvollziehen und werde auch nicht dagegen argumentieren. Meine bevorzugte Schreibweise nennt hier aber ein <div>- oder <table>-Element. Was ich im vorherigen Posting schrieb, bezog sich allerdings auch ausschließlich auf Quell- und nicht auf Fließtext.

"TABLE-Elemente" wären in meinem Sprachgebrauch auch etwas anderes als "Tabellen-Elemente", denn wenn ich von Letzterem rede, dann meine ich dies als Oberbegriff und schließe deren Nachfahrenselemente (TBODY-, TR-, TD- etc. -Elemente) als Unterbegriffe mit ein.

Ganz Deiner Meinung :-)

Das ist hier im Forum zwar auch möglich (obwohl es hier gerade umgekehrt dann nicht in blau geschrieben steht), ich fände es aber übertrieben, bei jedem metasprachlichem Gebrauch einzelner Begriffe etwa schon von <table>-Elementen zu sprechen.

Ich ebenfalls, daher verzichte ich an diesen Stellen auf [code], obwohl ich welchen andeute.

Es widerstrebt mir auch, ein zusammengesetztes Nomen mit einem Kleinbuchstaben zu beginnen oder gar mit einer spitzen Klammer.

Technischer Bezeichner, ich habe da kein Problem mit. Aber: Wir reden hier von Formulierungen innerhalb der Natürlichsprachlichkeit; da genügt es meines Erachtens, wenn die Schreibweise ohne wesentliche Zweifel klar werden lässt, was gemeint ist.

Cheatah

[Peter Pan]

Hi!

» Wenn man Farben nun mit #AA00FF angibt, werden diese Zeichen nun auch klein geschrieben?

In CSS ist (bei allem, was von CSS definiert ist) die Groß- und Kleinschreibung wieder egal. Bei RGB-Farbcodes hat sich eher die Großschreibung eingebürgert. Erstaunlicherweise halte ich es hier für lesbarer, kann dafür aber keinen Grund nennen.

Weil Du z.B. #DEE  nicht als Wort  warnimmst, sondern die Buchstaben einzeln liest?

off:PP

[Gunther]

Moin Paul!

Tags wie z.B. <img>, <div> etc. werden heutzutage klein geschrieben (früher war's wohl mal anders <DIV>?).
Wenn man Farben nun mit #AA00FF angibt, werden diese Zeichen nun auch klein geschrieben?

Beides funktioniert, klar. Aber nur so um es mal zu wissen.

Zum einen kommt es darauf an, ob du HTML oder XHTML verwendest - siehe http://de.selfhtml.org/html/xhtml/unterschiede.htm#kleinschreibung

Farbwerte sollten ja eigentlich nur im CSS vorkommen. Dafür gilt Grammar of CSS 2.1 und die sagt für Farbwerte:
"* There is a constraint on the color that it must
 * have either 3 or 6 hex-digits (i.e., [0-9a-fA-F])
 * after the "#"; e.g., "#000" is OK, but "#abcd" is not."

Gruß Gunther

[Hansi]

Moin, und wie ist das beim Programmieren?
Ich schreibe oft die Funktions-Argumente (Parameter) alle Groß, damit man sie in den -oft langen- Funktionen schneller finden kann, außerdem sieht man sofort wo ein Parameter und wo nur eine Variable zum Einsatz kommt.

Ist das schelchter Programmierstil?

Manche schreiben auch mal gerne den Typen davor, wie "bResult" = boolean oder "sResult" für String, "i" für Int, "f" für Float usw.

Ist das auch heutzutage üblich?

[Steel]

Hi!

In meiner Welt werden ueblicherweise Konstanten gross geschrieben. Eine grossgeschrieben Variable koennte zu Missverstaendnissen fuehren.

[Cheatah]

Hi,

In meiner Welt werden ueblicherweise Konstanten gross geschrieben.

richtig, dies vergaß ich in meinen Ausführungen. Konstanten bestehen ausschließlich aus Großbuchstaben, dem Unterstrich und ggf. Ziffern.

Cheatah

[Der Martin]

Hallo,

Moin, und wie ist das beim Programmieren?
Ich schreibe oft die Funktions-Argumente (Parameter) alle Groß, damit man sie in den -oft langen- Funktionen schneller finden kann, außerdem sieht man sofort wo ein Parameter und wo nur eine Variable zum Einsatz kommt.

das ist aber sehr ungewöhnlich. Steel erwähnte es schon: Großschreibung hat sich als Konvention bei Konstanten durchgesetzt; in manchen Programmierer-Gruppen auch für Typennamen.
Übrigens: Warum machst du Unterschiede zwischen den Parametern einer Funktion und sonstigen Variablen? Innerhalb der Funktion sind die völlig gleichwertig, und ich wüsste nicht, warum ich sie unterscheiden sollte.

Manche schreiben auch mal gerne den Typen davor, wie "bResult" = boolean oder "sResult" für String, "i" für Int, "f" für Float usw.
Ist das auch heutzutage üblich?

Kommt drauf an. Es gibt einige Coding Styles, die das so vorsehen. Besser finde ich aber, Präfixe zu verwenden, die den *Verwendungszweck* einer Variablen im Programm kenntlich machen, anstatt den Typ (der ergibt sich dabei meist aus dem Kontext).

Ach ja: Bei Hexadezimalzahlen haben sich -unabhängig von der Programmier-Umgebung- wohl Großbuchstaben als bevorzugte Schreibweise durchgesetzt.
Und ich stimme Cheatah zu: In diesem Fall ist das sogar besser lesbar, weil wir bei Kleinschreibung intuitiv dazu neigen, Wörter erkennen zu wollen; bei Großschreibung steht für das Unterbewusstsein eher der Buchstabe selbst im Vordergrund. Das ist im übrigen auch der Grund, warum Text in DURCHGEHENDEN GROSSBUCHSTABEN schlechter lesbar ist.

So long,
 Martin

[Hansi]

das ist aber sehr ungewöhnlich. Steel erwähnte es schon: Großschreibung hat sich als Konvention bei Konstanten durchgesetzt; in manchen Programmierer-Gruppen auch für Typennamen.
Übrigens: Warum machst du Unterschiede zwischen den Parametern einer Funktion und sonstigen Variablen? Innerhalb der Funktion sind die völlig gleichwertig, und ich wüsste nicht, warum ich sie unterscheiden sollte.

Ja gleichwertig schon, ich findes es Übersichtshalber besser, so sehe ich sofort wo der Parameter direkt angesprochen wird, und wo es manipuliert wird. Vorallem bei der Fehlersuche habe ich diese "Vorteile" erkannt.

Und ich stimme Cheatah zu: In diesem Fall ist das sogar besser lesbar, weil wir bei Kleinschreibung intuitiv dazu neigen, Wörter erkennen zu wollen; bei Großschreibung steht für das Unterbewusstsein eher der Buchstabe selbst im Vordergrund. Das ist im übrigen auch der Grund, warum Text in DURCHGEHENDEN GROSSBUCHSTABEN schlechter lesbar ist.

Stimmt, geben ich auch 100%ig Recht.

OK, und noch eine Frage an die Profis hier ;)
Wenn Ihr Funktionen schreibt / Variablen definiert, egal welche Sprache, benutzt Ihr deutsche oder englische Bezeichnungen dafür? Irgendwie neige ich mehr und mehr zum englischen, weiß auch nicht warum, ich denke es liegt daran das die Programmiersprachen an sich in englisch sind...

Nur mal so aus Neugier :)

[Der Martin]

Hallo,

Wenn Ihr Funktionen schreibt / Variablen definiert, egal welche Sprache, benutzt Ihr deutsche oder englische Bezeichnungen dafür?

wenn es keine verbindlichen Vorgaben gibt, ziehe ich *immer* die englische Sprache der deutschen vor. Nicht nur bei Programmcode.
Aber ich finde auch deutsche Benamsungen für Variablen und Funktionen in Ordnung - dann aber bitte konsequent! Ein Mischmasch, möglichst noch innerhalb eines Bezeichners, finde ich grausam.

Irgendwie neige ich mehr und mehr zum englischen, weiß auch nicht warum, ich denke es liegt daran das die Programmiersprachen an sich in englisch sind...

Ja, dann ist der Quellcode insgesamt harmonischer zu lesen.

So long,
 Martin

[Cheatah]

Hi,

Wenn Ihr Funktionen schreibt / Variablen definiert, egal welche Sprache, benutzt Ihr deutsche oder englische Bezeichnungen dafür?

Martins Antwort kann ich hier eigentlich nichts hinzufügen. Seine Anmerkung "Nicht nur bei Programmcode" möchte ich aber noch mit "sondern auch bei Kommentaren" konkretisieren. Immer gilt: Wenn es Coding-Guidelines gibt, ist jede Vorliebe hinfällig - es gelten die Guidelines. Wenn ich aber selbst welche festlegen kann:

• Alles auf Englisch.
• lowerCamelCase für Bezeichner aller Art, bis auf
• UpperCamelCase bei Klassen (nicht jedoch damit instanziierten Objekten).
• Um Gottfrieds Willen, auf gar gar gar keinen Fall irgendwelche Prefixes, die Typen oder sonstwas bezeichnen! Prefixes sind Namespaces, sonst nichts.
• Bezeichner müssen sprechend sein, ihre Bedeutung muss für Menschen mindestens in dem Kontext klar werden können, in dem sie gelten.
• Kommentare haben den Zweck, einem Verwender des Codes (egal welche Art der Verwendung) diejenigen Informationen zu geben, die er benötigt, um seine Verwendung durchführen zu können. Insbesondere bedeutet das, dass Kommentare *nicht* dazu dienen, einen Code noch mal in eine andere Sprache zu übersetzen.
• Blöcke werden
    - mit einer öffnenden geschweiften Klammer *in der selben Zeile[1]* begonnen,
    - mit einer schließenden geschweiften Klammer in einer neuen Zeile und genau der Spalte beendet, in der der öffnende Code beginnt,
    - und mit exakt vier Leerzeichen eingerückt. Nicht zwei, nicht drei, nicht fünf[2], nicht Tabulatoren. Vier Leerzeichen. Ausnahmen sind definierbar auf zwei Leerzeichen, wenn übermäßig viele Schachtelungsebenen[3] zu erwarten sind - und mindestens(!) dokumentweit einzuhalten.
• "else" und ähnliche Konstrukte, die zwei Blöcke abtrennen, beginnen *keine* neue Zeile, sofern der Block mehrzeilig ist; ansonsten schon, unter Beibehaltung der Spalte des zugehörigen "if" (oder was immer es war).
• Funktionsklammern werden ohne Leerzeichen an den Funktionsnamen angefügt.
• Zu Sprachkonstrukten wie "if", "for", "switch", "catch" gehörende Klammern werden mit (mindestens[4]) einem Leerzeichen abgetrennt.
• Konstrukte, die üblicherweise einen Block erzeugen, werden auch dann mit geschweiften Klammern notiert, wenn diese nicht zwingend nötig sind. *Niemals* schreibe "if (...) doSomething();".
• Über obige Regeln hinaus werden Kommas, Leerzeichen, Semikola usw. so gesetzt, wie es natürlichsprachlich üblich ist; unter Berücksichtigung einer übersichtlichen Schreibweise. Bei komplexeren Ausdrücken ist mit Leerzeichen und Umbrüchen ggf. anders umzugehen als bei solchen, die man schnell erfassen kann.

Nun ja, und so weiter. Natürlich sind viele Dinge von der Sprache abhängig (geschweifte Klammern in Python? ;-) ), aber obiges ist mehr oder weniger eine Quintessenz des Allgemeingültigen.

Cheatah

[1] Verdammich noch eins! ;-)
[2] Siehe Monty Python: "Die fünf scheidet völlig aus."
[3] Die Schachtelungsebenen handelsüblich komplexer HTML-Dokumente reichen nicht aus für eine solche Regel. In der Praxis heißt das: Zwei Leerzeichen als Einrückung kommen eigentlich nie vor.
[4] Bei einzeiligen Blöcken können Spalten erzeugt werden, beispielsweise:
if      (...) { ... }
else if (...) { ... }
else          { ... }

[Gunnar Bittersmann]

@@Cheatah:

nuqneH

Wenn ich aber selbst welche festlegen kann:

Bitte nicht für mich. In vielem stimmen wir überein, aber

• Blöcke werden
    - mit einer öffnenden geschweiften Klammer *in der selben Zeile[1]* begonnen,

Argl! Allman-Style!!1elf

- und mit exakt vier Leerzeichen eingerückt. Nicht zwei, nicht drei, nicht fünf[2], nicht Tabulatoren.

Argl! Tabulatoren!!1elf (aus gutem Grund)

Leider sind viele von Leerzeichen infiltriert, dass man in Teams selbst dazu gezwungen wird (und sich damit rumärgern muss). Die Mischung von Leerzeichen und Tabulatoren ist auf keinen Fal ratsam.

Qapla'

[suit]

Argl! Allman-Style!!1elf

1TBS :)

»»   - und mit exakt vier Leerzeichen eingerückt. Nicht zwei, nicht drei, nicht fünf[2], nicht Tabulatoren.
Argl! Tabulatoren!!1elf

Tabulatoren allerdings nur am Zeilenanfang, in der Zeilenmitte zur verbesserung der Lesbarkeit mit Leerzeichen (sonst würde das Gebilde bei geänderten Tabulatorbreiten auseinanderfallen).

z.B. als 1TBS:
foo {
qux  = 1;
quux = 2;
}

[Kai345]

[latex]Mae  govannen![/latex]

Argl! Allman-Style!!1elf

1TBS :)

Bäääh. Beides nicht. „else[if]“ gehört auf die Einrückebene des zugehörigen „if“, verd... nochmal! *g*

if (...) {
   .....
   .....
}
else {
   .....
   .....
}

Tabulatoren allerdings nur am Zeilenanfang, in der Zeilenmitte zur verbesserung der Lesbarkeit mit Leerzeichen (sonst würde das Gebilde bei geänderten Tabulatorbreiten auseinanderfallen).

Genau so.

Keine führenden Leerzeichen, nur Tab. Einrücktiefe = 3. Läßt sich (IMO) wesentlich besser lesen als 2 oder 4.

Cü,

Kai

[suit]

Keine führenden Leerzeichen, nur Tab. Einrücktiefe = 3. Läßt sich (IMO) wesentlich besser lesen als 2 oder 4.

Ich tendiere zu 2 - aber daraum ja Tabulatoren, da kann mans nach Geschmack einstellen. Wenn du drei willst:  gerne.

[dedlfix]

Hi!

[...] gehört auf die Einrückebene des zugehörigen [...], verd... nochmal! *g*

Solange du nicht von Python sprichst, gibt es kein "gehört so".

Lo!

[Tim Tepaße]

Hallo Cheatah,

• "else" und ähnliche Konstrukte, die zwei Blöcke abtrennen, beginnen *keine* neue Zeile, sofern der Block mehrzeilig ist; ansonsten schon, unter Beibehaltung  unter Beibehaltung der Spalte des zugehörigen "if" (oder was immer es war).

Das ist etwas umständlich formuliert; meinst Du

if (foo) {
    bar();
} else {
    baz();
}

... im Vergleich zu was?

(geschweifte Klammern in Python? ;-) )

pybraces ;)

(Und hey, Dictionariesm demnächst auch als comprehensions und set literals!)

Tim

[ChrisB]

Hi,

• "else" und ähnliche Konstrukte, die zwei Blöcke abtrennen, beginnen *keine* neue Zeile, sofern der Block mehrzeilig ist; ansonsten schon, unter Beibehaltung  unter Beibehaltung der Spalte des zugehörigen "if" (oder was immer es war).

Das ist etwas umständlich formuliert; meinst Du

if (foo) {
    bar();
} else {
    baz();
}

... im Vergleich zu was?

Na zu

if (foo) {
    bar();
}
else {
    baz();
}

MfG ChrisB