Coderichtlinien bewerten

[Severin Kacianka]

Hallo liebes Forum,

ich habe für die interne Verwendung in einem kleinem Team (4-6 Menschen) Coderichtlinien für XHTML, CSS und PHP verfasst. Da dies mein erster Versuch ist soetwas zu schreiben würde ich mich freuen, wenn ihr sie euch einmal ansehen und eure Meinung dazu abgeben könnt:

http://imst3.uni-klu.ac.at/severin/imst_coderichtlinien.html

Mein Ziel war es möglichst einfache und praxisnahe Hilfestellungen für "sauberes" Webdesign zu geben. Diese Richtlinien werden vor allem von Leuten gelesen werden, die sich noch nie mit validem oder barrierefreiem Webdesign beschäftigt haben.

Liebe Grüße und danke für eure Zeit,
Severin

[Olaf Schneider]

Hallo Severin,

nur kurze Anmerkungen:

color: #fff; könntest Du in color: #FFF; ändern und auch darauf hinweisen, dass Hexwerte großgeschrieben werden (quasi Konstanten).

Bei h1{ fehlt ein Space.

Zu den Kommentaren würde ich mir entweder überlegen, die Blöcke mit /* statt mit /** beginnen zu lassen oder aber JavaDoc bzw. phpDoc zu benutzen.

Sehr wertvoll finde ich die Falsch- und die Richtigbeispiele. Manche finden es einfacher, diese Beispiele zu vergleichen und damit ein Richtig intutiv zu erfassen als alle Erklärungen genau lesen zu müssen.

Meine 2 Øre,
Olaf

[Severin Kacianka]

Hallo Olaf,

color: #fff; könntest Du in color: #FFF; ändern und auch darauf hinweisen, dass Hexwerte großgeschrieben werden (quasi Konstanten).

an das habe ich noch nicht gedacht. Wäre aber eigendlich logisch, obwohl ich wetten kann, dass dies nicht konstant eingehalten wird. Es ist halt doch ein Mehraufwand die Shift-Taste zu drücken :-) Trotzdem werde ich es in den Beispielen anpassen.

Bei h1{ fehlt ein Space.

Danke.

Zu den Kommentaren würde ich mir entweder überlegen, die Blöcke mit /* statt mit /** beginnen zu lassen oder aber JavaDoc bzw. phpDoc zu benutzen.

Das ist konsitenter, ja. Auch wenn ich (JavaDoc-sei-dank) schon fast automatisch immer /** tippe.

Gruß,
Severin

[Olaf Schneider]

Hallo Severin,

nur zur Info:

bei css benutze ich auch Jens’ Styleguide und bin damit super zufrieden. Gerade durch die alfabetische Sortierung finde ich alles sofort.

bei php favorisiere ich Tabs statt Space (nur) zum Einrücken, da so jeder seine persönlichen optischen Vorlieben beibehalten kann. Ausserdem: Wenn im Code mehr als fünf, sechs Einrückungen stehen ist dieser wahrscheinlich nicht mehr hinreichend modular.

Gruß Olaf

[Ingo Turski]

Hi,

color: #fff; könntest Du in color: #FFF; ändern und auch darauf hinweisen, dass Hexwerte großgeschrieben werden (quasi Konstanten).

an das habe ich noch nicht gedacht. Wäre aber eigendlich logisch, obwohl ich wetten kann, dass dies nicht konstant eingehalten wird. Es ist halt doch ein Mehraufwand die Shift-Taste zu drücken :-) Trotzdem werde ich es in den Beispielen anpassen.

warum?
Ich finde es weder logisch noch sinnvoll. Im Gegenteil schreibe ich Hexwerte stets klein.
Und es ist AFAIK sogar üblicher un auch der CSS-Validator wandelt Hexwerte in Kleinbuchstaben um.

freundliche Grüße
Ingo

[Severin Kacianka]

Hallo,

warum?
Ich finde es weder logisch noch sinnvoll. Im Gegenteil schreibe ich Hexwerte stets klein.

Gibt es einen offiziellen Standard für Hexzahlen? Auf Wikipedia werden sie zum Beispiel überall groß geschrieben.
Ich glaube ich werde das mit den Hexzahlen einfach freistellen.

Gruß,
Severin

[Ingo Turski]

Hi,

Gibt es einen offiziellen Standard für Hexzahlen?

nein.
Selbst beim W3C wird mal Groß- und mal Kleinschreibung verwendet, siehe http://www.w3.org/TR/CSS21/syndata.html#value-def-color:
In der Grafik und dem Beispiel darunter klein, in der zusätzlichen Erläuterung darunter dann groß.

Ich sehe das eher pragmatisch: warum die Shift-Taste bemühen?
Und um das dann zu vereinheitlichen, würde ich schon die Kleinschreibweise zumindest empfehlen.

Ein wenig finde ich die Kleinschreibweise auch übersichtlicher - die Kleinbuchstaben kontrastieren besser zu den Ziffern und mehrere Großbuchstaben hintereinander sind etwas schlechter lesbar, weshalb dies nach den WAI auch (in Überschriften z.B.) vermieden weeden soll.

freundliche Grüße
Ingo

[Ingo Turski]

Hi,

Diese Richtlinien werden vor allem von Leuten gelesen werden, die sich noch nie mit validem oder barrierefreiem Webdesign beschäftigt haben.
Aber HTML- und CSS-Kenntnisse haben sie schon, oder?

Mir ist übrigens aufgefallen, dass auch Du <h7> erfunden hast.

"Alle Attribute sollen, der Lesbarkeit halber alphabetisch angegeben werden."
finde ich Blödsinn und das erinnert mich an Tastaturen mit alphabetisch angeordneten Tasten.
Warum sollten zusammengehörige Eigenschaften wie height und width aufgrund des Alphabets durch margin und padding getrennt werden?

Tabulatoren mag ich persönlich nicht, auch wenn Dein Argument natürlich nicht ganz von der Hand zu weisen ist. Ich finde sie einfach unpraktisch und bevorzuge doppelte Spaces: die sind gerade noch ausreichend zu unterscheiden und übertreiben es nicht bei mehrfacher Verschachtelung.

Wozu /** als Kommentareinleitung?

freundliche Grüße
Ingo

[seth]

gudn tach!

Tabulatoren mag ich persönlich nicht, auch wenn Dein Argument natürlich nicht ganz von der Hand zu weisen ist. Ich finde sie einfach unpraktisch und bevorzuge doppelte Spaces: die sind gerade noch ausreichend zu unterscheiden und übertreiben es nicht bei mehrfacher Verschachtelung.

welches argument meinst du? ich habe nur das folgende argument gefunden.

"Man sollte immer die Tabulatortaste zum Einrücken verwenden. So kann sich jeder selbst einstellen wie lang ein Tabulator ist. Attribute sind immer unter doppelte Anführungszeichen zu setzen."

und dieses erklaert doch, dass etwaige "uebertreibung bei mehrfacher verschachtelung" im ermessen des jeweiligen autoren liegt.
wenn man in seinem lieblingseditor die tabs auf zwei stellt, hat man doch quasi zwei spaces und es badarf keiner konversion.
wenn aber z.b. 2 spaces vorgegeben sind und man lieber mit 4 arbeitet, dann muss man ein dokument erst umformatieren und nach dem bearbeiten wieder zurueckformatieren.

prost
seth

[Severin Kacianka]

Hallo,

Mir ist übrigens aufgefallen, dass auch Du <h7> erfunden hast.

*rot werd* Uh-Ah ;-(

"Alle Attribute sollen, der Lesbarkeit halber alphabetisch angegeben werden."
finde ich Blödsinn und das erinnert mich an Tastaturen mit alphabetisch angeordneten Tasten.
Warum sollten zusammengehörige Eigenschaften wie height und width aufgrund des Alphabets durch margin und padding getrennt werden?

Da könntest du irgendwie recht haben. Das sollte ich mir noch einmal überlegen. Obwohl es vielleicht doch hilfreich ist, wenn man weis wo man nach einem Attribut suchen muss (ist es gesetzt, oder nicht).

Tabulatoren mag ich persönlich nicht, auch wenn Dein Argument natürlich nicht ganz von der Hand zu weisen ist.

Ich weiß, da gibt es Religionskriege (wie auch bei wie/wo klammern). Ein bisschen habe ich mich damit beschäftigt, und ich bin zu dem Schluss gekommen, dass es so wohl am einfachsten ist. Sonst fürchte ich, dass der eine mal mit zwei Leerzeichen und der andere mit vier einrückt. Das scheint mir noch problematischer, als alles was Tabs anrichten können.

Gruß,
Severin

[seth]

gudn tach!

Tabulatoren mag ich persönlich nicht, auch wenn Dein Argument natürlich nicht ganz von der Hand zu weisen ist.

Ich weiß, da gibt es Religionskriege (wie auch bei wie/wo klammern). Ein bisschen habe ich mich damit beschäftigt, und ich bin zu dem Schluss gekommen, dass es so wohl am einfachsten ist.

vor allem ist es auch ein weg, der die wenigsten probleme mit sich fuehrt. wenn tatsaechlich jemand mit tabulatoren nicht arbeiten kann/will, kann er ja ein dokument temporaer umformatieren.

Sonst fürchte ich, dass der eine mal mit zwei Leerzeichen und der andere mit vier einrückt. Das scheint mir noch problematischer, als alles was Tabs anrichten können.

es geht. wenn sowas innerhalb einer datei auftaucht, kann man dennoch z.b. mittels astyle wieder klarheit schaffen.

prost
seth

[Ingo Turski]

Hi,

Warum sollten zusammengehörige Eigenschaften wie height und width aufgrund des Alphabets durch margin und padding getrennt werden?

Da könntest du irgendwie recht haben. Das sollte ich mir noch einmal überlegen. Obwohl es vielleicht doch hilfreich ist, wenn man weis wo man nach einem Attribut suchen muss (ist es gesetzt, oder nicht).

Hierfür bietet sich an, _Empfehlungen_ auszusprechen.
Ein Vorschlag könne sein, sowohl die Selektoren, als auch die Eigenschaften möglichst nach einer Logik von außen nach innen bzw. vom Allgemeinen zum Speziellen anzuordnen. Hierzu könntest Du ein paar Beispiele angeben, die die Übersichtlichkeit dokumentieren,
also: html -> body -> Elemente zur Seitenaufteilung -> Überschriften -> Absätze ...
und: position|float|clear -> width,height -> margin,padding -> border -> color,background ...

Tabulatoren mag ich persönlich nicht, auch wenn Dein Argument natürlich nicht ganz von der Hand zu weisen ist.

Ich weiß, da gibt es Religionskriege (wie auch bei wie/wo klammern). Ein bisschen habe ich mich damit beschäftigt, und ich bin zu dem Schluss gekommen, dass es so wohl am einfachsten ist. Sonst fürchte ich, dass der eine mal mit zwei Leerzeichen und der andere mit vier einrückt. Das scheint mir noch problematischer, als alles was Tabs anrichten können.

Es ist natürlich sinnvoll, vorzuschreiben wie eingerückt werden soll. Und ich sehe wie gesagt auch die Vorteile von Tabulatoren, die vielleicht auch die Nachteile überwiegen. Ich persönlich bevorzuge allerdings halt exakt zwei Spaces - aus Gewohnheit und weil mir das zur Unterscheidung ausreicht und ich bei vier Leerstellen viel zu oft mit der Zeilenlänge (relativ große Auflösung und auch große Schrift) nicht hinkomme und der Code dann äußerst unübersichtlich wird.

freundliche Grüße
Ingo

[Kalle_B]

Hi, 1ngo,

"Alle Attribute sollen, der Lesbarkeit halber alphabetisch angegeben werden."
finde ich Blödsinn und das erinnert mich an Tastaturen mit alphabetisch angeordneten Tasten.
Warum sollten zusammengehörige Eigenschaften wie height und width aufgrund des Alphabets durch margin und padding getrennt werden?

(alphabetisch) nicht so sehr wegen der LESBARKEIT, sondern zum WIEDERFINDEN ist es gut. Manche CSS- Datei ist lang. Willst du die Struktur des Dokuments in der CSS- Datei abbilden?

body {..}
h1   {..}
h2   {..}
p    {..}
img  {..}
form {..}
input{..}
...

ist für mich total durcheinander. Wenn du weisst, wo bei dir form und input hingehört, ist es gut. Aber die Richtlinie soll ja für Neulinge gelten, die ihren Code austauschen.

Innerhalb eines Tags (und das meinst du wahrscheinlich mit Attribut) könnte man von aussen (Rand) nach innen (Schriftfarbe) arbeiten, mache ich auch:

.li {
  margin-left: 10%;
  width:       50%;
  float:       left;
  padding ...
}

aber besonders logisch ist das nicht. Ich ertappe mich dabei, dass ich alle paar Wochen eine andere "Logik" entdecke. Allerdings sind DIESE Einträge überschaubar.

Kalle

[Markus]

Hallo,

in deiner Richtlinie schreibst du
"Veraltete Tags wie <b>,<i>,<font> dürfen nicht mehr verwendet werden".
SELFHTML mit der Seite http://de.selfhtml.org/html/text/physisch.htm#elemente zeigt allerdings, dass <b> und <i> nichtmal als deprecated eingestuft wurden. Ist es deine persönliche Meinnung? Oder findest du es "einfacher" jedesmal einen <span> mit Klassenangabe hinzuschreiben?

Viele Grüße,
Markus

[Severin Kacianka]

Hallo Markus,

"Veraltete Tags wie <b>,<i>,<font> dürfen nicht mehr verwendet werden".
SELFHTML mit der Seite http://de.selfhtml.org/html/text/physisch.htm#elemente zeigt allerdings, dass <b> und <i> nichtmal als deprecated eingestuft wurden. Ist es deine persönliche Meinnung? Oder findest du es "einfacher" jedesmal einen <span> mit Klassenangabe hinzuschreiben?

Ich geb zu jetzt etwas verwirrt zu sein. Bis jetzt habe ich mir eingebildet, dass man besser "logische" Tags wie <em>,<strong> etc. verwenden und "grafischen" Tags wie <b>,<i> etc. vermeiden soll. Dass man <font> gar nicht mehr verwenden darf, davon war ich sogar ganz überzeugt. Ich werde mich aber im Laufe des langen Wochenendes noch einmal schlau machen.

Gruß,
Severin

[Ashura]

Hallo Severin.

Ich geb zu jetzt etwas verwirrt zu sein.

Dafür gibt es keinen Grund.

Bis jetzt habe ich mir eingebildet, dass man besser "logische" Tags wie <em>,<strong> etc. verwenden und "grafischen" Tags wie <b>,<i> etc. vermeiden soll.

Was ja auch absolut dem Idealzustand entgegenstrebend ist. Der Sinn und Zweck dahinter ist einfach, Inhalte eine passende _strukturelle_ Form zu geben. Elemente wie <i>, <b> und <font> haben strukturell einen Aussagewert gleich null, sind also mit <span> vergleichbar. Sie wurden einzig und allein zu gestalterischen Zwecken geschaffen, widersprechen also schon allein in ihrer Existenz dem eigentlichen Ansinnen von HTML. (Siehe hierzu auch meine Signatur.)

Einen schönen Mittwoch noch.

Gruß, Ashura

[Markus]

Hallo,

Elemente wie <i>, <b> [...] haben strukturell einen Aussagewert gleich null [...]

Quelle? ;-)

im Grunde strukturieren sie attributierten Text in Form kursiver oder fetter Schreibweise. Die Struktur besagt, dass es sich um den enthaltenen Text um kursive oder fette ( ;-) ) Schreibweise des Textes handelt.

Viele Grüße,
Markus

[Ashura]

Hallo Markus

Elemente wie <i>, <b> [...] haben strukturell einen Aussagewert gleich null [...]

Quelle? ;-)

Meinung.

im Grunde strukturieren sie attributierten Text in Form kursiver oder fetter Schreibweise.

Das ist ein Widerspruch an sich: eine Struktur ist gänzlich unabhängig von ihre Darstellung. Sie gibt ihrem Inhalt lediglich eine mehr oder weniger adäquate Form.

Die Struktur besagt, dass es sich um den enthaltenen Text um kursive oder fette ( ;-) ) Schreibweise des Textes handelt.

Nein, die Darstellung besagt dies. Strukturell wird rein gar nichts ausgesagt.

Einen schönen Donnerstag noch.

Gruß, Ashura

[Thorsten L.]

Hallo Ashura,

Was ja auch absolut dem Idealzustand entgegenstrebend ist. Der Sinn und Zweck dahinter ist einfach, Inhalte eine passende _strukturelle_ Form zu geben. Elemente wie <i>, <b> und <font> haben strukturell einen Aussagewert gleich null, sind also mit <span> vergleichbar. Sie wurden einzig und allein zu gestalterischen Zwecken geschaffen, widersprechen also schon allein in ihrer Existenz dem eigentlichen Ansinnen von HTML. (Siehe hierzu auch meine Signatur.)

Wie würdest du dann fettgeschriebenen Text auszeichnen?

Mfg
Thorsten

[Ashura]

Hallo Thorsten.

Wie würdest du dann fettgeschriebenen Text auszeichnen?

Gar nicht, da ich diesen Aspekt einzig und allein per CSS regele.

Einen schönen Donnerstag noch.

Gruß, Ashura

[MudGuard]

Hi,

Hallo Thorsten.

Wie würdest du dann fettgeschriebenen Text auszeichnen?

Gar nicht, da ich diesen Aspekt einzig und allein per CSS regele.

Ausnahme: es handelt sich um eine Seite über Typographie - dort kann "fett" oder "kursiv" durchaus auch mal strukturell bedeutsam sein ;-)

cu,
Andreas

[Thorsten]

Hallo,

Gar nicht, da ich diesen Aspekt einzig und allein per CSS regele.

welches Tag würdest du verwenden, welches du mit CSS formatierst um fettgeschriebenen Text im Browser darzustellen? Es geht nicht um einen kompletten ABsatz, sondern um meinetwegen zwei Wörter in einem Abschnitt.

Danke im Voraus.

Gruß,
Thorsten

[Vinzenz Mai]

Hallo Thorsten,

welches Tag würdest du verwenden, welches du mit CSS formatierst um fettgeschriebenen Text im Browser darzustellen? Es geht nicht um einen kompletten ABsatz, sondern um meinetwegen zwei Wörter in einem Abschnitt.

aus welchem Grund werden diese zwei Wörter fettgeschrieben?

a) [ ] weil sie betont werden sollen,
b) [ ] weil sie besonders betont werden sollen,
c) [ ] weil sie den Einsatz von Fettschrift demonstrieren sollen,
d) [ ] ein anderer Grund: ______________________

Mein Lösungsvorschlag:

a) <em>
b) <strong>
c) <b>
d) von dem speziellen anderen Grund abhängig :-)

Freundliche Grüße

Vinzenz

[Ashura]

Hallo Thorsten.

welches Tag würdest du verwenden, welches du mit CSS formatierst um fettgeschriebenen Text im Browser darzustellen? Es geht nicht um einen kompletten ABsatz, sondern um meinetwegen zwei Wörter in einem Abschnitt.

Vinzenz hat meine Antwort bereits vorweg genommen, nur mit dem Unterschied, dass ich keinerlei Elemente zur Vermittlung von Darstellung mehr verwende.
Ich habe <b> und Konsorten gänzlich aus meinem Sprachgebrauch verbannt.

In diesem Sinne wird es auch nie mein Ansinnen sein, einen Text fettgedruckt darzustellen, sondern höchstens ihn hervorzuheben. Wie diese Hervorhebung letztendlich aussieht, wird auf einer anderen Ebene festgelegt. CSS eben.

Einen schönen Donnerstag noch.

Gruß, Ashura

[Richard Rüfenacht]

Hallo Ashura!

Ich habe <b> und Konsorten gänzlich aus meinem Sprachgebrauch verbannt.
In diesem Sinne wird es auch nie mein Ansinnen sein, einen Text fettgedruckt darzustellen, sondern höchstens ihn hervorzuheben. Wie diese Hervorhebung letztendlich aussieht, wird auf einer anderen Ebene festgelegt. CSS eben.

Was du sagst, ist selbstverständlich völlig richtig. Du überschätzt aber bei weitem die Fähigkeit der meisten Menschen zum abstrakten Denken. Wenn du sagst, in einem Text solle ein bestimmtes Wort hervorgehoben werden, wird sofort gefragt: "Was meinst du mit hervorheben, meinst du fett?" Es wird immer sofort an eine konkrete Form des Hervorhebens gedacht.

Es ist diese Denkweise, die das Trennen von Struktur und Darstellung so schwierig macht. Ich bestreite den immer wieder betonten Primat von Struktur und semantischem Markup ganz wehement. Das führt nur zum Cheatah-Dilemma. Entscheidend ist, was auf dem Bildschirm zu sehen ist. Und das ist nicht der Code. Der Code ist lediglich dazu da, diese Darstellung zu ermöglichen. Dass sauberer Code dies sicherer macht und gerade deshalb wichtig ist, ist für mich einfach selbstverständlich.

Beste Grüsse
Richard

[Ashura]

Hallo Richard.

Du überschätzt aber bei weitem die Fähigkeit der meisten Menschen zum abstrakten Denken.

Hm, ich meine eigentlich dies nicht zu tun. Ich bin mir bewusst, dass ich in manchen Belangen weitaus besser zu abstraktem Denken fähig bin, als die Menschen meiner Umgebung.

Wenn du sagst, in einem Text solle ein bestimmtes Wort hervorgehoben werden, wird sofort gefragt: "Was meinst du mit hervorheben, meinst du fett?" Es wird immer sofort an eine konkrete Form des Hervorhebens gedacht.

Dies zu erklären kann in der Tat recht schwierig ausfallen und dürfte meist mit einem „Und wozu nun das Ganze?“ quittiert werden.
Doch so lange es Windmühlen gibt, erkläre ich gerne immer und immer wieder, wie ich mir den Idealzustand vorstelle und was man tun kann, um wenigstens die richtige Richtung einzuschlagen.
Und dass ein fettgedruckter Text nicht nur die einzige Möglichkeit ist,etwas hervorzuheben, dürfte den meisten bekannt sein. Dass dieser optische Aspekt bei der Strukturierung aber überhaupt keine Rolle spielt, dagegen schon eher weniger.

Es ist diese Denkweise, die das Trennen von Struktur und Darstellung so schwierig macht.

… und uns hier beinahe täglich zu Erklärungen dazu bewegt.

Entscheidend ist, was auf dem Bildschirm zu sehen ist. Und das ist nicht der Code.

Aber sein Resultat. Ohne Grundlage kein Resultat, je sauberer ersteres desto sauberer zweiteres. Aber dir brauche ich das ja nicht zu erklären.

Einen schönen Freitag noch.

Gruß, Ashura

[Richard Rüfenacht]

Hallo Ashura!

Wenn du sagst, in einem Text solle ein bestimmtes Wort hervorgehoben werden, wird sofort gefragt: "Was meinst du mit hervorheben, meinst du fett?" Es wird immer sofort an eine konkrete Form des Hervorhebens gedacht.
Dies zu erklären kann in der Tat recht schwierig ausfallen und dürfte meist mit einem „Und wozu nun das Ganze?“ quittiert werden.

Schwierig zu erklären ist es möglicherweise, weil dabei ein paar Sprachregelungen unklar sind. In der Alltagssprache ist es beispielsweise schwer verständlich, warum eine Überschrift nichts mit Darstellung zu tun haben soll.

Doch so lange es Windmühlen gibt, erkläre ich gerne immer und immer wieder, wie ich mir den Idealzustand vorstelle und was man tun kann, um wenigstens die richtige Richtung einzuschlagen.

War der Kampf gegen Windmühlen nicht irgendwie aussichtslos? ;-)

Es ist diese Denkweise, die das Trennen von Struktur und Darstellung so schwierig macht.
… und uns hier beinahe täglich zu Erklärungen dazu bewegt.

Mich beeindruckt, die freundliche Art und Kompetenz mit der du das machst. Wie wäre es mit einem Artikel, damit nicht immer alles wiederholt werden muss?

Entscheidend ist, was auf dem Bildschirm zu sehen ist. Und das ist nicht der Code.
Aber sein Resultat. Ohne Grundlage kein Resultat, je sauberer ersteres desto sauberer zweiteres.

Ich habe dazu eine zwiespältige Einstellung. Sauberer und valider Code führen keineswegs automatisch zu einer korrekten Darstellung und für eine valide site zahlt niemand auch nur einen Cent zusätzlich. Für mich sind websites ein neuartiges, hoch interaktives Kommunikationsmedium. Die Orientierung am Code befördert ein Umdenken, darin sehe ich den entscheidenden Punkt. Vereinfacht ausgedrückt: weg vom abgebildeten Prospekt, hin zu einer eigenständigen Informationsvermittlung.

Beste Grüsse
Richard

[Ashura]

Hallo Richard.

In der Alltagssprache ist es beispielsweise schwer verständlich, warum eine Überschrift nichts mit Darstellung zu tun haben soll.

Hm, ich hatte hier bisher den Eindruck, dass der richtige Gedanke durchaus bereits vorhanden ist. Eine Überschrift wird entweder als Zusammenfassung des untergeordneten Textes oder als Eyecatcher angesehen. Bei ersterem ist die tatsächliche Darstellung zweitrangig.

War der Kampf gegen Windmühlen nicht irgendwie aussichtslos? ;-)

Ich kämpfe ja nicht *gegen* die Windmühlen, sondern zeige ihnen meiner Meinung nach bessere Wege auf, um zum Ziel zu kommen.

Es ist diese Denkweise, die das Trennen von Struktur und Darstellung so schwierig macht.

… und uns hier beinahe täglich zu Erklärungen dazu bewegt.

Mich beeindruckt, die freundliche Art und Kompetenz mit der du das machst. Wie wäre es mit einem Artikel, damit nicht immer alles wiederholt werden muss?

Ich denke hin und wieder darüber nach, aber bisher nichts Konkretes.

Wenn, dann dürfte der Artikel nicht in trockenen Worten heruntergepredigt, sondern müsste anschaulich gestaltet werden. Und zwar genau so, dass der interessierte Leser von sich aus sagt, dass die einzelnen Schritte zur Trennung von Struktur und Darstellung in seinen Augen wirklich sinnvoll sind. Jegliche Fragen müssen im Artikel sofort beantwortet werden, denn Argumentationslücken auftauchen, wird das gesamte Vorhaben wackelig.

Sauberer und valider Code führen keineswegs automatisch zu einer korrekten Darstellung und für eine valide site zahlt niemand auch nur einen Cent zusätzlich.

Ja, ich habe mich unpräzise ausgedrückt. Ich wollte zum Ausdruck bringen, dass ein sauberes Grundgerüst weitaus bessere Möglichkeiten bietet, eine anspruchsvolle Fassade zu halten. Dass hier der Faktor „Browser und ihre Fähigkeiten“ noch eine gravierende Rolle spielt ist sehr lästig, aber leider nicht zu ändern.

Und sowohl validen (hintergründig) als auch strukturell sinnvollen (vordergründig) Code zu erstellen, stellt für mich eine Selbstverständlichkeit dar. Ob ich dies dementsprechend auch nicht anrechnen würde, wenn ich gewerblich aktiv wäre, weiß ich nicht.

Für mich sind websites ein neuartiges, hoch interaktives Kommunikationsmedium. Die Orientierung am Code befördert ein Umdenken, darin sehe ich den entscheidenden Punkt. Vereinfacht ausgedrückt: weg vom abgebildeten Prospekt, hin zu einer eigenständigen Informationsvermittlung.

Und zu einer unglaublich flexiblen, plattformübergreifenden und barrierearmen noch dazu. Wenn man sie nur lässt.

Beste Grüsse
Richard

Danke, ebenfalls.

Und einen schönen Samstag noch.

Gruß, Ashura

[Severin Kacianka]

Hallo,

Entscheidend ist, was auf dem Bildschirm zu sehen ist. Und das ist nicht der Code.

Wenn es sich um einen Bildschirm handelt. Wenn ich etwas betonen will, betone ich es, wenn ich etwas hervorheben will tue ich das. <em> ist "darstellungsneutral". Der Tag sagt nicht "ich bin kursiv", sondern "mein Inhalt ist wichtig". Ein ScreenReader kann so einen Text "betont" lesen. Einen Text "kursiv" zu lesen,  ist eher schwer vorstellbar.

Natürlich kann man sagen <i> und <em> tun genau das selbe, sie tragen aber eine andere Botschaft (Semantik). Wahrscheinlich behandeln ScreenReader <i> und <em> genau gleich, es ist aber eigendlich falsch <i> zu betonen, da er Text ja "nur" kurisv machen soll.

Gruß,
Severin

[Richard Rüfenacht]

Hallo Severin!

Wenn es sich um einen Bildschirm handelt. Wenn ich etwas betonen will, betone ich es, wenn ich etwas hervorheben will tue ich das. <em> ist "darstellungsneutral". Der Tag sagt nicht "ich bin kursiv", sondern "mein Inhalt ist wichtig". Ein ScreenReader kann so einen Text "betont" lesen. Einen Text "kursiv" zu lesen,  ist eher schwer vorstellbar.
Natürlich kann man sagen <i> und <em> tun genau das selbe, sie tragen aber eine andere Botschaft (Semantik). Wahrscheinlich behandeln ScreenReader <i> und <em> genau gleich, es ist aber eigendlich falsch <i> zu betonen, da er Text ja "nur" kurisv machen soll.

Das sehe ich alles genau so. Ich bezog mich ausschliesslich auf Ashuras Antwort auf die Frage wie fetter Text dargestellte werden soll. Dabei stimme ich sowohl Ashura als auch dir voll zu. Es ging mir lediglich um den Hinweis, dass es erfahrungsgemäss recht schwierig ist, jemandem der gewohnt ist <b> oder <i> zu verwenden, zu erklären, dass dies über CSS gelöst werden sollte. Grundsätzlich sollten diese Tags im HTML-Code nicht mehr vor kommen, das gilt aber auch für <em>.

Beste Grüsse
Richard

[Christoph G.]

Hallo.

Fettschrieb (gibt's das Wort?) dient ja meist der besonderen Hervorhebung bzw. Betonung einer Aussage - die korrekte Auszeichnung wäre damit <em> oder <strong>

Gruß
 Christoph

[Kalle_B]

Hallo Severin,

gute Idee, nicht zu umfangreich und mit Humor.

Ich arbeite zwar allein, aber eine sinnvolle Gliederung erleichtert die Fehlersuche und die Einarbeitung, wenn man nach zwei Jahren und 50 anderen Baustellen mal wieder dran muss.

Zum SQL-Code würde ich vorschlagen, die Kommentare mit in den SQL- String zu nehmen. Bei einem evtl. Fehler wird der angezeigt und es ist sofort klar, welcher SQL jetzt gerade muckt:

$q = "
#~~~~~~~~~~~~~~~~~~~~~

AUSSTELLER POSITIONEN SEIT 30.5.06 WUENSCHE GRUPPENBEREINIGT

#~~~~~~~~~~~~~~~~~~~~~
SELECT
 per1.adr_art
,per1.nname
,per1.vname
,per1.anreise_vortag
,per1.tag_1
,per1.tag_2
,per1.bezeichnung
,per1.kurzname
,per1.adr_unt
,per1.ort
,per1.email
,per1.anzahl_mails
,per1.fuhrparkgroesse
,per1.id
,per1.tel

,count(DISTINCT kon1.gruppen_id)    kon_anz_grp
,count(DISTINCT kon2.gruppen_id)    kon_gebu_grp

,count(DISTINCT kon3.besucher_id)   kon_anz_einzel
,count(DISTINCT kon4.besucher_id)   kon_gebu_einzel

FROM      ".$db[0]['personen']." AS per1

WUENSCHE VON BESUCHERGRUPPEN

LEFT JOIN ".$db[0]['kontakte']." AS kon1
ON        kon1.aussteller_id=per1.id AND ( kon1.prio_1=1 OR kon1.prio_2=1 ) AND kon1.gruppen_id>0

TERMINE VON BESUCHERGRUPPEN

LEFT JOIN ".$db[0]['kontakte']." AS kon2
ON        kon2.id=kon1.id AND kon2.slot_nr>0 AND kon1.gruppen_id>0

WUENSCHE VON EINZELBESUCHERN

LEFT JOIN ".$db[0]['kontakte']." AS kon3
ON        kon3.aussteller_id=per1.id AND ( kon3.prio_1=1 OR kon3.prio_2=1 ) AND kon3.gruppen_id=0

TERMINE VON EINZELBESUCHERN

LEFT JOIN ".$db[0]['kontakte']." AS kon4
ON        kon4.id=kon3.id AND kon4.slot_nr>0 AND kon4.gruppen_id=0

WHERE     per1.owner=".$owner." AND per1.adr_kz=1 AND per1.loe_kz=0 ".$such."
#ROUP BY  per1.bezeichnung, per1.adr_unt
GROUP BY  per1.kurzname, per1.adr_unt
";
  $res = mysql_query( $q, $conn_id ); zeigSqlFehler( $q, $conn_id );

Kalle

[Severin Kacianka]

Hallo Kalle,

gute Idee, nicht zu umfangreich und mit Humor.

Danke :-)

Zum SQL-Code würde ich vorschlagen, die Kommentare mit in den SQL- String zu nehmen. Bei einem evtl. Fehler wird der angezeigt und es ist sofort klar, welcher SQL jetzt gerade muckt:

Das ist eine sehr gute Ideen, ich werde mir in Ruhe überlegen, wie ich diese am besten erkläre.

Gruß,
Severin

[Vinzenz Mai]

Hallo Severin,

ich habe für die interne Verwendung in einem kleinem Team (4-6 Menschen) Coderichtlinien für XHTML, CSS und PHP verfasst.
http://imst3.uni-klu.ac.at/severin/imst_coderichtlinien.html

Du solltest mit dieser Anleitung _zwei_ Ziele umsetzen:

Mein Ziel war es möglichst einfache und praxisnahe Hilfestellungen für "sauberes" Webdesign zu geben.

Das ist das erste Ziel, dabei gefällt mir, dass Du den Schwerpunkt auf "möglichst einfach und praxisnah" setzt.

Diese Richtlinien werden vor allem von Leuten gelesen werden, die sich noch nie mit validem oder barrierefreiem Webdesign beschäftigt haben.

Und genau aus diesem Grund sollte sich _Dein_ Dokument an _Deine_ eigenen Coderichtlinien halten, um Deine Richtlinien vorbildlich zu demonstrieren. Bitte überprüfe deswegen Dein eigenes Dokument auf die Einhaltung Deiner Vorgaben. Schau' Dir z.B. die unlogische Verwendung von <br /> im Punkt 0.2 an. Ich weiß nicht, warum Du Deinen Namen und E-Mailadresse in eine eigene Zeile gesetzt hast. <br /> solltest Du hier einfach weglassen oder wenn Du eine eigene Zeile haben willst, durch angemessenere Auszeichnung ersetzen.

Deine Einleitung könnte positiver ausfallen. Fällt Dir wirklich nichts ein, warum Coderichtlinien sinnvoll sind. Grundsätzlich bin ich der Meinung, dass sauber strukturierter Code schöner aussieht, lesbarer und verständlicher ist als Kraut-und-Rüben-Code, der sich nicht an _ein_ Schema hält. Dies gilt auch dann, wenn es sich nicht um meine persönlichen Präferenzen handelt. Voraussetzung sind selbstredend ordentliche Richtlinien - und Deine sind durchaus ein guter Ansatz. Hass ist für mich jedenfalls überhaupt kein guter Grund, eine Coderichtlinie zu beachten, bewirkt eher das Gegenteil. Vielleicht ergibt sich in der Diskussion noch der eine oder andere positive Ansatz.

Absatz 1.1: Gleiches Schema, viel Negatives. Schreib' es um, schreib' es positiv. Deine neutralste Formulierung könnte statt dessen lauten:

"Tags sind klein zu schreiben, Attributwerte grundsätzlich in Anführungszeichen (welche eigentlich) einzuschließen. Ist es eine Einführung in XHTML? Nein. Willst Du auch nicht. Gib' dem Absatz eine neue, passendere Überschrift.

Im Gegensatz zu Ingo gefällt mir, dass Du Tabulatoren zum Einrücken vorschreibst - und keine Leerzeichen. Der verwendete Editor sollte das richtig darstellen. Mir sind nämlich zwei Leerzeichen zu wenig für eine Einrückungsebene, ich verwende vier Zeichen. Tabulatoren ermöglichen es jedem Teammitglied die Anzeige an die eigene Präferenz anzupassen. Dennoch gibt es ein Problem dabei, dass Du nicht aus den Augen verlieren solltest. Code wird gelegentlich auch ausgedruckt. Das Korrekturlesen von Ausdrucken ist einfacher als am Bildschirm. Coderichtlinien könnten darauf Rücksicht nehmen.

Wie Ingo halte ich es für sinnvoller, CSS-Eigenschaften nicht in alphabetischer Reihenfolge aufzuführen, sondern korrespondierende Eigenschaften zusammenzuhalten.

Bei PHP hast Du ja herzlich wenig geschrieben. Ich persönlich finde es sehr gut, wenn Operatoren (im Normalfall) durch ein Leerzeichen vom Operanden getrennt sind. Ich halte dies _insbesondere_ beim Punkt als Verkettungsoperator für sinnvoll. Nicht sinnvoll ist dies _meiner Meinung nach_ beim Inkrement- und Dekrementoperator.

Deine SQL-Richtlinien sind hingegen eine einzige Katastrophe. SQL-Statements durchzunummerieren ist genauso unsinnig wie die Verwendung von Variablen der Form a1, a2, a3, a4 bis a378 für alle Variablen einer Funktion oder einer Klasse. Was soll das? Gib' dem Kind einen sinnvollen Namen. Wenn mehr als ein Statement gebraucht wird, wenn mehr als eine Datenbankverbindung benötigt wird, benenne sie so, dass Du aus dem Namen erkennst, um welche es sich handelt. Nein, ich bin _nicht_ der Meinung dass

$con
    $sql
    $query
    $result

grundsätzlich gute Namen sind. Diese sollten sich an Deine anderen Vorgaben handeln. Du könntest hier eventuell mit Präfixen arbeiten.

Die Formatierung Deiner SQL-Statements ist ebenfalls verbesserungswürdig. Bitte schau' Dir im Archiv einige meiner Beiträge zum Thema Datenbanken an. Dann wirst Du sehen, was _ich_ für eine einigermassen angemessene Form halte (soweit mir die Eingabe hier in der Textarea nicht zu aufwendig ist). Es fehlen strukturierende Leerzeichen, strukturierende Zeilenumbrüche und damit strukturierende Einrückungen.

Dein Statement selbst im Beispiel wird übrigens wegen Syntaxfehler scheitern. Lass Dir das Ergebnis mit

echo $sql;

anzeigen. Du wirst sehen, dass meine Empfehlungen Deine Fehler verhindern.

Sieh' bitte mein Posting als konstruktive Kritik. Du hast einen guten ersten Ansatz, auf dem Du aufbauen kannst.

Freundliche Grüße

Vinzenz

[seth]

gudn tach!

Im Gegensatz zu Ingo gefällt mir, dass Du Tabulatoren zum Einrücken vorschreibst - und keine Leerzeichen. Der verwendete Editor sollte das richtig darstellen. Mir sind nämlich zwei Leerzeichen zu wenig für eine Einrückungsebene, ich verwende vier Zeichen.

hihi, https://forum.selfhtml.org/?t=130464&m=843337...

Dennoch gibt es ein Problem dabei, dass Du nicht aus den Augen verlieren solltest. Code wird gelegentlich auch ausgedruckt.

das ist kein problem, dafuer gibt's viiiele tools, z.b. code2html, astyle, vim oder einfach sed.

Ich persönlich finde es sehr gut, wenn Operatoren (im Normalfall) durch ein Leerzeichen vom Operanden getrennt sind. Ich halte dies _insbesondere_ beim Punkt als Verkettungsoperator für sinnvoll.

gibt's da auch 'nen praktischen grund fuer oder ist das bloss dein geschmack?

prost
seth

[Vinzenz Mai]

Hallo seth,

Im Gegensatz zu Ingo gefällt mir, dass Du Tabulatoren zum Einrücken vorschreibst - und keine Leerzeichen. Der verwendete Editor sollte das richtig darstellen. Mir sind nämlich zwei Leerzeichen zu wenig für eine Einrückungsebene, ich verwende vier Zeichen.

hihi, https://forum.selfhtml.org/?t=130464&m=843337...

Du kennst mich *g*

das ist kein problem, dafuer gibt's viiiele tools, z.b. code2html, astyle, vim oder einfach sed.

;-) Für erstere Aufgabe übrigens auch.

Ich persönlich finde es sehr gut, wenn Operatoren (im Normalfall) durch ein Leerzeichen vom Operanden getrennt sind. Ich halte dies _insbesondere_ beim Punkt als Verkettungsoperator für sinnvoll.

gibt's da auch 'nen praktischen grund fuer oder ist das bloss dein geschmack?

Das ist meine persönliche Sehschwäche, deswegen benötige ich ja auch eine Tabulatoreinstellung von vier Zeichen. Das ist sicher Geschmackssache. Wenn ich z.B. Verkettungen der Form

$bla = $foo.$bar;

sehe, kapituliere ich in vielen Fällen gleich. Nur wenn mich das Problem sehr interessiert, schaue ich mir den Code in meinem Editor näher an, nachdem ich den Code für mich lesbar umformatiert habe. Oftmals finde ich den Fehler bereits beim Umformatieren ...

Freundliche Grüße

Vinzenz

[seth]

gudn tach!

Nur wenn mich das Problem sehr interessiert, schaue ich mir den Code in meinem Editor näher an, nachdem ich den Code für mich lesbar umformatiert habe. Oftmals finde ich den Fehler bereits beim Umformatieren ...

du formatierst von hand um? oder wie ist das zu verstehen?

prost
seth

[Vinzenz Mai]

Hallo seth,

Nur wenn mich das Problem sehr interessiert, schaue ich mir den Code in meinem Editor näher an, nachdem ich den Code für mich lesbar umformatiert habe. Oftmals finde ich den Fehler bereits beim Umformatieren ...

du formatierst von hand um?

ja :-) Entsprechend geringer Codeumfang vorausgesetzt.

oder wie ist das zu verstehen?

Genau so. Die Methode hat sich für mich als durchaus effektiv erwiesen, da es von  mir verlangt, den Code sehr intensiv zu lesen. Sonst passiert mir das, wobei ich mich selbst immer mal wieder ertappe: Ich lese, was ich lesen will - und nicht das, was da steht. In https://forum.selfhtml.org/?t=130464&m=843413 hab' ich mal wieder das gefährliche Volk der Varibalen erwähnt, daneben noch etliche Fehler begangen, die mir in der Vorschau entgangen sind. [1]

Freundliche Grüße

Vinzenz

[1] Nein, ich nutze nicht die Rechtschreibprüfung :-)

[Severin Kacianka]

Hallo Vinzenz,

Und genau aus diesem Grund sollte sich _Dein_ Dokument an _Deine_ eigenen Coderichtlinien halten, um Deine Richtlinien vorbildlich zu demonstrieren. Bitte überprüfe deswegen Dein eigenes Dokument auf die Einhaltung Deiner Vorgaben. Schau' Dir z.B. die unlogische Verwendung von <br /> im Punkt 0.2 an. Ich weiß nicht, warum Du Deinen Namen und E-Mailadresse in eine eigene Zeile gesetzt hast. <br /> solltest Du hier einfach weglassen oder wenn Du eine eigene Zeile haben willst, durch angemessenere Auszeichnung ersetzen.

Das <br /> _nach_ Name und E-Mail ist da noch eher unnötig, das davor finde ich aber so passend wie selten. Ich will nichts anderes erreichen, als dass mein Name nicht in der selben Zeile wie der vorherige Satz ist. Wie soll ich soetwas auszeichenen? Es ist kein Absatz. Ein Absatz ist (IMHO) länger als ein paar Worte (oder der einzige Satz unter einer Überschrift) und ist vom verhergehenden Absatz getrennt. Das trifft nicht zu. Für mich gehört mein Name und E-Mail sematisch zu diesem einen Absatz.
In einer eigenen Zeile will ich es haben, damit man meinen Namen einfach leichter finden kann.

Deine Einleitung könnte positiver ausfallen. Fällt Dir wirklich nichts ein, warum Coderichtlinien sinnvoll sind.

Diese negative Art zu schreiben, ist meine Art Liebe zu zeigen. Ich halte nichts davon etwas in den Himmel zu loben, sonder nimm den Kritikern lieber  humorvoll den Wind aus den Segeln.
Wenn ich Coderichtlinien nicht für sinnvoll halten würde, hätte ich wohl kaum dieses Dokument geschrieben und alle im Team davon überzeugt es zu versuchen.

"Tags sind klein zu schreiben, Attributwerte grundsätzlich in Anführungszeichen (welche eigentlich) einzuschließen. Ist es eine Einführung in XHTML? Nein. Willst Du auch nicht. Gib' dem Absatz eine neue, passendere Überschrift.

Doch es ist eine Art Crashkurs. Die Zielgruppe hat noch nie XHTML geschrieben oder gesehen und ich möchte sie ein wenig darauf vorbreiten. Es wird so oder so noch jede Menge persöhnliche Überzeugungsarbeit nötig sein.

Bei PHP hast Du ja herzlich wenig geschrieben.

Weil ich noch nicht so ganz weiß, was alles unklar werden könnte. Ich habe versucht alle möglichen Probleme schon jetzt abzudecken, werde die Richtlinien aber wohl noch laufend erweitern müssen. In PHP gibt es wenig Erfahrungen in unserer Zusammenarbeit. Bis jetzt war immer jeder nur für "seinen" Teil zuständig, und musste sich oft lang in das "Revier" des anderen einlesen.

Nicht sinnvoll ist dies _meiner Meinung nach_ beim Inkrement- und Dekrementoperator.

Ich auch nicht, ich muss diesen noch ausnehmen.

SQL-Statements durchzunummerieren ist genauso unsinnig wie die Verwendung von Variablen der Form a1, a2, a3, a4 bis a378 für alle Variablen einer Funktion oder einer Klasse.

Jaein. Wenn es in der Regel nicht mehr als eine Abfrage pro Programm gibt bleibt es so einfach. Es ist einfacher die Anweisung zu geben "Schau in $sql nach" als "schau in $ja_wie_hies_sie_nochmal nach".

Selbiges gilt auch für $con,$result und $query. Sie werden in diesem Projekt eine eindeutige Sematik haben.

Die Formatierung Deiner SQL-Statements ist ebenfalls verbesserungswürdig.

Ich werde nach deinen Postings suchen.

Dein Statement selbst im Beispiel wird übrigens wegen Syntaxfehler scheitern.

Danke.

Sieh' bitte mein Posting als konstruktive Kritik. Du hast einen guten ersten Ansatz, auf dem Du aufbauen kannst.

Danke :-)

Gruß,
Severin

[Vinzenz Mai]

Hallo

In einer eigenen Zeile will ich es haben, damit man meinen Namen einfach leichter finden kann.

Mich persönlich hat es durchaus gestört. Ich habe mein Browserfenster kleiner und größer gemacht, es war immer in einer eigenen Zeile - ohne dass ich dafür einen bestimmten Grund sah. In Deinem Satz fehlt übrigens auch die Interpunktion.

<address> wäre geeignet, zwänge Dich jedoch dazu, zwei <p>-Elemente zu verwenden. Meiner Meinung nach wäre dies die passendere Lösung und ein gutes Beispiel für den sinnvollen Einsatz dieses Elementes. *g*

Deine Einleitung könnte positiver ausfallen. Fällt Dir wirklich nichts ein, warum Coderichtlinien sinnvoll sind.

Diese negative Art zu schreiben, ist meine Art Liebe zu zeigen. Ich halte nichts davon etwas in den Himmel zu loben, sonder nimm den Kritikern lieber  humorvoll den Wind aus den Segeln.

Ich habe kein Problem damit, Schwachstellen klar und deutlich anzusprechen, dennoch bin ich ein grundsätzlicher Anhänger einer positiven Darstellung. Mir stößt Dein Stil unangenehm auf. Ich wäre durch Deine Einleitung negativ gegenüber dem Rest eingestellt. Ich wäre motiviert, Dich bei Fehlern und Inkonsistenzen zu ertappen. Bei mir hätte Dein Dokument sein sehr sinnvolles Ziel verfehlt, was schade wäre. Wer mit dem Herzen dabei ist, wer von einer Sache überzeugt ist, dem fällt es leicht, solche Richtlinien zu befolgen und konsequent einzuhalten. Wenn Dein Stil das bei Deiner Zielgruppe dieses Ziel erreicht, dann ist das in Ordnung.

Nicht sinnvoll ist dies _meiner Meinung nach_ beim Inkrement- und Dekrementoperator.

Ich auch nicht, ich muss diesen noch ausnehmen.

Dann hat mein Beitrag bereits etwas bewirkt *freu*

SQL-Statements durchzunummerieren ist genauso unsinnig wie die Verwendung von Variablen der Form a1, a2, a3, a4 bis a378 für alle Variablen einer Funktion oder einer Klasse.

Jaein. Wenn es in der Regel nicht mehr als eine Abfrage pro Programm gibt bleibt es so einfach.

Nein. Auch dann nicht:

"Wenn eine Funktion nur eine Varibale benötigt, dann muss diese $var heißen."

Wäre dies Deiner Meinung nach sinnvoll? Bestimmt nicht. Warum bei Datenbankzugriffen. Du widersprichst Dir selbst:

<zitat>Variablen müssen sinnvoll benannt werden</zitat>

Es ist einfacher die Anweisung zu geben "Schau in $sql nach" als "schau in $ja_wie_hies_sie_nochmal nach".

Wie kommst Du auf diese seltsame Idee?

<zitat>Variablen müssen sinnvoll benannt werden</zitat>

Und das sollte auch für diese Gruppe gelten. Möglicherweise möchtest Du spezielle Präfixe für diese Variablen vorschreiben?

Die Formatierung Deiner SQL-Statements ist ebenfalls verbesserungswürdig.

Ich werde nach deinen Postings suchen.

Das ist eine gute Idee :-)

Dein Statement selbst im Beispiel wird übrigens wegen Syntaxfehler scheitern.

Danke.

Inzwischen nicht mehr wegen Whitespaces, nur noch (möglicherweise) wegen eines Feldnamens, aber sei bitte konsequent.

<zitat>
$sql = 'SELECT t.vorname,t.nachname,v.datum ';
// Die betroffenen Tabellen
$sql.= ' FROM teilnehmer t, veranstaltung v ';
// Zuerst die Joins und dann alle weitern Bedingungen
$sql.= ' WHERE t.id=v.teilnehmer ';
$sql.= ' AND v.name LIKE 'M%'';
</zitat>

Fragen:
    Warum trennst Du die Feldnamen nicht durch Leerzeichen?
    Warum gönnst Du Feldnamen und Tabellennamen nicht eigene Zeilen?
    Warum verwendest Du keine explizite JOIN-Syntax?
    Warum trennst Du nicht Operator und Operand?

Ich ändere schrittweise:

$sqlBenutzerDaten = 'SELECT' . "\n"
    . '    t.vorname,' . "\n"
    . '    t.nachname,' . "\n"
    . '    v.datum' . "\n"
    . '-- Die betroffenen Tabellen' . "\n"
    . 'FROM teilnehmer t' . "\n"
    . '-- Zuerst die Joins' . "\n"
    . 'INNER JOIN veranstaltung v' . "\n"
    . '    ON t.id = v.teilnehmer  -- Überdenke die Spaltennamen :-)' . "\n"
    . 'WHERE vname LIKE 'M%'     -- Ich mag keine Backslashitis' . "\n";

oder vielleicht auch (mit Verstoß gegen Deine Regeln)

$sqlBenutzerDaten =
'SELECT
    t.vorname,       -- hier mit Tabulator :-)
    t.nachname,      -- auch der Kommentar mit Tabulator eingerückt
    v.datum          -- außer hier im Antwortfenster ;-)
    FROM teilnehmer t
    INNER JOIN veranstaltung v       -- Zuerst die Joins
        ON t.id = v.teilnehmer       -- Trenne Operatoren und Operanden ;-)
    WHERE t.vorname LIKE 'V%'      -- Wenn es unbedingt sein muss :-(
                                     -- Fällt Dir meine Korrektur auf?
        AND t.nachname LIKE 'M%'   -- Aber ist das wirklich lesbar?';

Lesbarer Code ist wartbarer Code und damit effizienter als unlesbarer Code, der das gleiche macht. Fehler in SQL-Statements zu finden, ist oftmals mühsam, oft fehlt nur ein Whitespace, manchmal nur ein einfaches Anführungszeichen.

Wende daher auf generierte Statements vergleichbare Regeln an wie auf geschriebenen Code.

Freundliche Grüße

Vinzenz

[Severin Kacianka]

Hallo Vinzenz,

<address> wäre geeignet, zwänge Dich jedoch dazu, zwei <p>-Elemente zu verwenden. Meiner Meinung nach wäre dies die passendere Lösung und ein gutes Beispiel für den sinnvollen Einsatz dieses Elementes. *g*

Da hast du recht :-) Ich habe diesen Tag leider nicht bewusst in Erinnerung gehabt.

Was die Benennung der Variablen und die formatierung der SQL-Anfragen betrifft muss ich mir noch Zeit nehmen und alles in Ruhe durchdenken.
Du hast sicherlich Recht, aber auf der anderen Seite ist die Folge $sql=>$query=>$result allen bekannt und ich weiß nicht, ob ich es noch komplizierter machen will.

Gruß,
Severin

[Jens Müller]

Hallo Severin und Vinzenz,

Im Gegensatz zu Ingo gefällt mir, dass Du Tabulatoren zum
Einrücken vorschreibst - und keine Leerzeichen. Der verwendete
Editor sollte das richtig darstellen. Mir sind nämlich zwei
Leerzeichen zu wenig für eine Einrückungsebene, ich verwende
vier Zeichen.

Ich persoenlich mag die Einrueckung per Tab gar nicht, wenn
man sich an die Vorgabe haelt, dass eine Zeile maximal 72 - 85
Zeichen breit sein sollte, dann verschwenden Tabs zu viel Platz.

In der Regel, wenn ich etwas schreibe, halte ich mich grob an
de Richtlinien von Perl style und PHP Pear. 4 Leerzeichen als Einrueckung u.s.w.

Wobei, ich ein wenig diese Regeln umgehe und bei Klammern
schon einmal meinen eigenen Standard einhalte.

  
sub doSomething  
    {  
    /* Funktionsnutzlast */  
    }  
  
my @arrayNutzlast =  
    (  
    "Treibstoff",  
    "Sattelit",  
    "RV",  
    "Pesonen"  
    );  

Ich mache es, weil mir es intuitiv lesbarer erscheint. Man erfasst
sofort wo etwas anfaengt, und wo es aufhoert. (Is halt der
Mathematiker in mir ;)

Tabulatoren ermöglichen es jedem Teammitglied die Anzeige
an die eigene Präferenz anzupassen.

Das mag stimmen, wobei ich immer ein wenig den Verdacht habe,
dass viele Neu Autoren Tabs als Mittel einsetzen, um den "Klau"
desm Quelltextes zu unterbinden.

Ausserdem, wie viele kennen die Moelicheiten Ihrer Software nicht.
Es werden die Standardeinstellungen verwendet, einfach weil es so
eingestellt ist.

Severin, wenn du die Moeglichkeit hast, dann  finde ich es besser
ein kleines Script zu schreiben welches immer 4 Leerzeichen durch
ein Tabzeichen ersetzt.
Ausserdem, solltest du beides zulassen. Sowohl Tabs, als auch
Leerzeichen zur Einrueckung.

gruesse aus'm ruhrpott
  jens mueller

[seth]

gudn tach!

Ich persoenlich mag die Einrueckung per Tab gar nicht, wenn
man sich an die Vorgabe haelt, dass eine Zeile maximal 72 - 85
Zeichen breit sein sollte, dann verschwenden Tabs zu viel Platz.

ein tab verwendet soviel speicherplatz wie genau ein leerzeichen.
die (allein sichtbare) einruecktiefe legt man in seinem editor selbst fest.

In der Regel, wenn ich etwas schreibe, halte ich mich grob an
de Richtlinien von Perl style und PHP Pear. 4 Leerzeichen als Einrueckung u.s.w.

perl redet ausdruecklich von 4-column-indent, was die benutzung von tabs nicht verbietet.

abgesehn davon steht passend im perl-manual
"Larry has his reasons for each of these things, but he doesn't claim that everyone else's mind works the same as his does."

Wobei, ich ein wenig diese Regeln umgehe

eben.

und bei Klammern
schon einmal meinen eigenen Standard einhalte.

sub doSomething
    {
    /* Funktionsnutzlast */
    }

> [...]  
> Ich mache es, weil mir es intuitiv lesbarer erscheint. Man erfasst  
> sofort wo etwas anfaengt, und wo es aufhoert. (Is halt der  
> Mathematiker in mir ;)  
  
das hat mit mathematiker-sein nix zu tun, denn ich schreibe  
  
~~~perl
  
sub doSomething{  
  /* Funktionsnutzlast */  
}

und erfasse sofort, wo was anfaengt und wo es aufhoert, wie im uebrigen auch nahezu jeder andere, der nach einem (egal welchem, hauptsache irgendeinem) standard formatiert.

Tabulatoren ermöglichen es jedem Teammitglied die Anzeige
an die eigene Präferenz anzupassen.

Das mag stimmen, wobei ich immer ein wenig den Verdacht habe,
dass viele Neu Autoren Tabs als Mittel einsetzen, um den "Klau"
desm Quelltextes zu unterbinden.

ich verstehe diese aussage nicht und halte sie dennoch fuer totalen kaese als argument gegen tabs.

Ausserdem, wie viele kennen die Moelicheiten Ihrer Software nicht.

weisst du denn, dass du bei deinem editor die tab-einrueck-tiefe aendern kannst? ;-)

Es werden die Standardeinstellungen verwendet, einfach weil es so
eingestellt ist.

wer das macht, ist doof. gutes beispiel sind wohl browser. aber texteditoren sollte man seinem geschmack anpassen. wenn man noch keinen geschmack hat, ist eben eine vorgabe wie die von Severin der oktroyierte geschmack, dem man den editor anpassen muss, um gescheit arbeiten zu koennen.

Severin, wenn du die Moeglichkeit hast, dann  finde ich es besser
ein kleines Script zu schreiben welches immer 4 Leerzeichen durch
ein Tabzeichen ersetzt.

es wurde schon mehrmals im thread fertige tools dafuer genannt, die tab-hasser benutzen koennen, um den gegebenen quellcode fuer die zeit ihres editierens umzuformatieren.

Ausserdem, solltest du beides zulassen. Sowohl Tabs, als auch
Leerzeichen zur Einrueckung.

das resultat waere, dass _jeder_ vor dem editieren ein dokument durch astyle (oder etwas aehnliches) jagen muesste.
ich will nicht bestreiten, dass das auch seine vorteile haette.

prost
seth

[molily]

Hallo,

Das mag stimmen, wobei ich immer ein wenig den Verdacht habe,
dass viele Neu Autoren Tabs als Mittel einsetzen, um den "Klau"
desm Quelltextes zu unterbinden.

ich verstehe diese aussage nicht und halte sie dennoch fuer totalen kaese als argument gegen tabs.

Hehe, ich frage mich auch, wie das funktionieren soll. Fünfhundert Tabs jeder Zeile voranstellen in der Hoffnung, der Editor hat keine Umbruchfunktion und der gesamte Code ist rechts aus dem Bild geschoben? ;)

Mathias

[seth]

gudn tach!

[...] eure Meinung dazu abgeben könnt:

an sich schon ganz gut, aber schon der erste absatz ist grauenhaft zu lesen. wenn kein eiserner gegner des generischen maskulinums bist, waere es imho geschickt dieses zu verwenden, das wuerde das lesen und das schreiben enorm vereinfachen.

wenn du allerdings an der strikten beidnennung festhalten willst, sind "Benutzerdaten" und "Affendompteuren" noch nicht p.c. ;-)

noch mehr kleinigkeiten:
in "1.2 Logische Textauszeichnung" fehlt ein komma nach dem ersten "es".

in "3.2 Formatierung" legst du zwar variablennamen fest, sagst jedoch nix zu funktionennamen

in "3.3.3 Inline Kommentare" wuerde ich noch ein semikolon hinter den sprintf-aufruf setzen.

prost
seth

[Severin Kacianka]

Hallo seth,

an sich schon ganz gut, aber schon der erste absatz ist grauenhaft zu lesen. wenn kein eiserner gegner des generischen maskulinums bist, waere es imho geschickt dieses zu verwenden, das wuerde das lesen und das schreiben enorm vereinfachen.

Im Gegenteil: Aber ich arbeite für eine Universität, und da gibt es ganze Forschungsgruppen, die einen bei "Genderinsensibilitäten" in kleine Stücke reißen...

wenn du allerdings an der strikten beidnennung festhalten willst, sind "Benutzerdaten" und "Affendompteuren" noch nicht p.c. ;-)

Shhhhh! Noch schlafen SIE!

in "3.2 Formatierung" legst du zwar variablennamen fest, sagst jedoch nix zu funktionennamen

Werde ich nachholen.

Gruß,
Severin

[seth]

gudn tach!

[gegner des generischen maskulinums?]

Im Gegenteil: Aber ich arbeite für eine Universität, und da gibt es ganze Forschungsgruppen, die einen bei "Genderinsensibilitäten" in kleine Stücke reißen...

wenn das der einzige grund gegen die verwendung des generischen maskulinums ist (und das ist leider tatsaechlich oft so), dann waere mir das an deiner stelle egal, da die das in-stueck-reissen eh nur verbal versuchen wuerden.

wenn du allerdings an der strikten beidnennung festhalten willst, sind "Benutzerdaten" und "Affendompteuren" noch nicht p.c. ;-)

Shhhhh! Noch schlafen SIE!

hmm, du koenntest es auch einfach p.c. gestalten und deren reaktionen abwarten... auf "feind/feindin", "benutzer/innendaten", "benutzer/inneneingaben" und "affen/aeffinnendompteur/innen" ... ;-)
vielleicht schlagen sie dann von ganz alleine das generische maskulinum vor, hihi.

ach ja, du hast uebrigens noch keine angaben darueber gemacht, welches dateiformat (unix/dos/mac, ansi/utf-8/...) benutzt werden soll. ist mir aufgefallen, als ich einen umlaut (*igitt*) im beispielcode entdeckte.

prost
seth

[Severin Kacianka]

Hallo seth,

wenn das der einzige grund gegen die verwendung des generischen maskulinums ist (und das ist leider tatsaechlich oft so), dann waere mir das an deiner stelle egal, da die das in-stueck-reissen eh nur verbal versuchen wuerden.

Umschreiben musste ich es dann trotzdem. Meine Chefin hat mir geraten den Text gleich "Gendersensetiv" zu schreiben.
Ich mags nicht, aber sich zu wehren bringt höchstens böse E-Mails.... (und ja, es gibt irgendwo ein Dokument in dem die "korrekte" Schreibweise von jedem "Genderwort" geregelt ist....)

ach ja, du hast uebrigens noch keine angaben darueber gemacht, welches dateiformat (unix/dos/mac, ansi/utf-8/...) benutzt werden soll. ist mir aufgefallen, als ich einen umlaut (*igitt*) im beispielcode entdeckte.

Weil ich es nicht so wirklich weiß. Die Dateien liegen auf einem Linuxserver, der als Netzwerklaufwerk in die Windowsrechner eingebunden wird. Wenn ich die Datein unter Windows editiere, und umlaute ganz normal schreibe funktioniert alles. Wenn ich mich jetzt über ssh einlogge, und eine Datei mit Umlauten mit vim bearbeiten will, werden Umlaute als "komische Zeichen" dargestellt. Wenni ch mit vim direkt Umlaute schreibe, sind sie im Web nicht darstellbar.

Ich bin irgendwie in der Zeichensatzhölle und gebe mich damti zufrieden, dass Umlaute, wenn sie unter Windows geschreiben werden in jedem meiner Browser dargestellt werden.

Gruß,
Severin

[Ashura]

Hallo Severin.

Wenn ich mich jetzt über ssh einlogge, und eine Datei mit Umlauten mit vim bearbeiten will, werden Umlaute als "komische Zeichen" dargestellt. Wenni ch mit vim direkt Umlaute schreibe, sind sie im Web nicht darstellbar.

Was sagt die Ausgabe von „locale“?
Ggf. musst du hier dann für LANG und LC_ALL den von dir gewünschten Wert setzen, bevor du mit vim zu Werke schreitest.

Ich bin irgendwie in der Zeichensatzhölle und gebe mich damti zufrieden, dass Umlaute, wenn sie unter Windows geschreiben werden in jedem meiner Browser dargestellt werden.

In diesem Sinne könntest du auch gleich auf UTF-8 umstellen.
Diejenigen, die später an den jeweiligen Dokumenten arbeiten, dürften erfreut sein, Umlaute und sonstige Sonderzeichen direkt notieren zu dürfen.

Einen schönen Mittwoch noch.

Gruß, Ashura

[Severin Kacianka]

Hallo Ashura,

Was sagt die Ausgabe von „locale“?

LANG=de_AT
LANGUAGE=de_AT:de_DE:de

Wenn ich eine Datei mit vim erstelle, gibt es keine Probleme. Ich scheine erst Probleme zu bekommen, wenn vim auf eine windowserstellte Datei trifft und umgekehrt.

In diesem Sinne könntest du auch gleich auf UTF-8 umstellen.

Wollte ich eigendlich. Ich habe es aber nicht so ganz geschafft. Aber vielleicht ist es noch einen Versuch wert :-)

Gruß,
Severin

[Ashura]

Hallo Severin.

Wenn ich eine Datei mit vim erstelle, gibt es keine Probleme. Ich scheine erst Probleme zu bekommen, wenn vim auf eine windowserstellte Datei trifft und umgekehrt.

Dann sollte recode eigentlich weiterhelfen können.

In diesem Sinne könntest du auch gleich auf UTF-8 umstellen.

Wollte ich eigendlich. Ich habe es aber nicht so ganz geschafft. Aber vielleicht ist es noch einen Versuch wert :-)

Ich habe mein System hauptsächlich wegen vim auf UTF-8 umgestellt und die meisten Probleme gab es lediglich dabei, herauszufinden, wo das GNOME-Terminal seine Einstellungen für die Darstellung von Zeichen herholt. (Es war /etc/environment)

Einen schönen Freitag noch.

Gruß, Ashura

[Jonathan]

Was mir noch auffällt:

Einseseits sagst du, dass man alles logisch und semantisch Formatiren soll und die Darstellung über das CSS laufen soll, andererseits bringst du ein sehr merkwürdiges Positivbesipiel mit
<img src="bullet.gif" alt="" />

Ich dachte Bullets sollte man mit Listen erzeugen? Und <img>-Tags ohne Bedeutung haben in semantischem (X)-HTML genauso wenig etwas verloren wie spacer-gifs. Bilder ohne semantische Bedeutung fügt man per CSS ein, wenn das überhaupt nötig sein sollte.

[Severin Kacianka]

Hallo Jonathan,

Ich dachte Bullets sollte man mit Listen erzeugen? Und <img>-Tags ohne Bedeutung haben in semantischem (X)-HTML genauso wenig etwas verloren wie spacer-gifs. Bilder ohne semantische Bedeutung fügt man per CSS ein, wenn das überhaupt nötig sein sollte.

Ich bin der Meinung, dass es durchaus legitm ist, sich ein "schöneres" Bullet zu machen und dieses auch einzufügen. Wichtig ist nur, dass ein Screenreader dann nicht ständig "Bullet - Bullet - Bullet" quäkt.

Wie füge ich Bilder per CSS ein?

Gruß,
Severin

[Tobias]

Hallo,

Wie füge ich Bilder per CSS ein?

Da es in deinem Fall ja wohl um Listen geht, kannst du für ul bzw. ol list-style-image: url(bullet.gif); verwenden.

Tschau

Tobias

[Severin Kacianka]

Hallo,

Da es in deinem Fall ja wohl um Listen geht, kannst du für ul bzw. ol list-style-image: url(bullet.gif); verwenden.

Mir ging es beim schreiben eigendlich nicht explizit um Listen. Eher um Bilder die zwar schön aussehen, aber keine Informationen beitragen. Obwohl ich nicht gewusst habe, dass man seine eigenen Listenkennzeichner so elegant einbinden kann.

Gruß,
Severin

[Ashura]

Hallo Severin.

Ich bin der Meinung, dass es durchaus legitm ist, sich ein "schöneres" Bullet zu machen und dieses auch einzufügen.

Apropos Listen: du erwähnst ul und ol. Warum nicht dl?

Einen schönen Mittwoch noch.

Gruß, Ashura

[Severin Kacianka]

Hallo  Ashura,

Apropos Listen: du erwähnst ul und ol. Warum nicht dl?

Weil ich es nicht kannte.

Gruß,
Severin