Beiträge mit zu viel C-Code "sperren"

Der Code schaut ja grauslig aus. Ein Reformatter wär gut, dann könn't 
mans auch lesen.

Wenn Code nicht vernünftig aufbereitet gepostet wird, schaue ich mir das 
meisstens gar nicht an. Dann störts auch den Lesefluss nicht :-)

chris_dus schrieb:
> dann man man ihn auch gut lesen ;-)

Das Dingen malt nur die Keywords bunt an. Das kann diese Seite mit den 
[c ] [/c ] Tokens auch.
Der Code schaut noch immer noch grauslig aus ...

chris_dus schrieb:
> wird html Formatierung denn hier richtig angezeigt ???

Nein. Damit könnte man ja vernünftige Links posten.

Aber in deinen Forum ist das alles natürlich kein Problem...

Wann kriegen wir es denn zu sehen?

Mark Brandis schrieb:
> Nein. Damit könnte man ja vernünftige Links posten.

Klappt aber auch ohne für Angriffe anfälliges Erlauben von HTML in 
Beiträgen ganz gut, BBCode würde reichen.

... ad nauseam.

vn nn schrieb:
> Klappt aber auch ohne für Angriffe anfälliges Erlauben von HTML in
> Beiträgen ganz gut, BBCode würde reichen.

Ja. Einfach eine vernünftige Art von Tags zu haben, mit der man einen 
Link markieren kann, wäre eine gute Lösung.

Uhu Uhuhu schrieb:
> Aber in deinen Forum ist das alles natürlich kein Problem...
>
> Wann kriegen wir es denn zu sehen?

[Mod.: entf.]

Das Argument, dass man selbst etwas besser machen muss um es kritisieren 
zu dürfen, war schon immer schwachsinnig. Nach der Logik müsste ja auch 
Dein Chef auf der Arbeit Deinen Job besser machen als Du. Das ist aber 
nun mal überhaupt nicht seine Aufgabe.

Klaus schrieb:
> Ach, und du bist hier Chef, oder was?

Ein Beispiel ist keine zur Allgemeingültigkeit erhobene Aussage.

Mark Brandis schrieb:
> [Mod.: entf.]

Jörg, du übertreibst.

JUHUU, der brandis ist wieder da...

Wie wäre es mit einem Hinweis an der 'Poser' ?

Immer nur Verbote ... Dummes Land.

Uhu Uhuhu schrieb:
> Mark Brandis schrieb:
>> [Mod.: entf.]
>
> Jörg, du übertreibst.

Womit eigentlich?  Ich bin gerade aus dem Urlaub zurück ...

Was sagt uns das?  Auch wenn hier jeder offfenbar "seinen"
Lieblings-Moderator hat, sind wir uns untereinander offenbar
recht gut einig in der Art unserer Moderation. ;-)

Back to topic: ich denke nicht, dass man Leuten, die gedankenlos
riesige Sourcecodepamphlets hier posten, nennenswert helfen können
wird, egal ob mit oder ohne technische(n) Maßnahmen.

Jörg Wunsch schrieb:
> Back to topic: ich denke nicht, dass man Leuten, die gedankenlos
> riesige Sourcecodepamphlets hier posten, nennenswert helfen können
> wird, egal ob mit oder ohne technische(n) Maßnahmen.

und

>Wichtige Regeln - erst lesen, dann posten!
>    Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

vielleicht mit dem Hinweis, wenn Du Böser ...

Jörg Wunsch schrieb:
> Ich bin gerade aus dem Urlaub zurück ...

Ob Juppi dir diese Extravaganz jemals verzeihen wird, steht in den 
Sternen...

Ich sehe keinen Grund, Beiträge mit "zu viel" Code zu sperren.

Wenn jemand schreibt, "folgender Code funktiniert nicht"

1

...

2

if (a == o)

3

   lcd_printf (u, v_32, r, "\n");

4

...

Dann heisst es doch sofort "zeig mehr Code!"

Und Code der inline steht, den kann man auch einfach zitieren und 
einfacher darauf Bezug nehmen als Zitate für externen Code zu erzeugen.

Wem der Code zu lange ist, der kann doch den Rollballken betätigen, den 
Beitrag überspringen oder Hoch- Runter-Taste betätigen, die in jedem 
Brauser funktioniert. Auch in Textbrausern.

Eher störend find ich überbreiten Text wie in
Beitrag "undefined reference to `__sync_val_compare_and_swap_4' error at compilation, using gcc 4.1.1 and 4.2"

Eine Roll-Box um Code, der physikalisch zu groß für den Bildschirm ist, 
könnte da eine Lösung sein.

Im Wiki ist überbreiter Text/Bilder auch lästig, eber da liegt es in der 
Hand des jeweiligen Autos, ein barrierefreies Betrachten zu ermöglichen 
anstatt Voraussetzungen zu machen wie daß die Bildschirmauflösung der 
Leser mindetsens so hoch ist wie die eigene.

Dies erfordert nämlich beim Lesen von Fließtext, der garnix mit der 
überbreiten Stelle zu tun hat, ständiges Links-Rechts-Rollen.

Johann L. schrieb:
> Eher störend find ich überbreiten Text wie in
> Beitrag "undefined reference to `__sync_val_compare_and_swap_4' error at 
compilation, using gcc 4.1.1 and 4.2"
>
> Eine Roll-Box um Code, der physikalisch zu groß für den Bildschirm ist,
> könnte da eine Lösung sein.

Genau die gibt es doch, siehe Anhang. Oder wünschst Du vielmehr ein 
vertikales Scrollen?

Johann L. schrieb:
> Eher störend find ich überbreiten Text wie in
> Beitrag "undefined reference to `__sync_val_compare_and_swap_4' error at compilation, using gcc 4.1.1 and 4.2"

Sowas nervt mich auch. Man könnte z.B. bei extrem langen Zeilen nach N 
Zeichen einen automatischen Zeilenumbruch generieren. (where N = 
sinnvoll)

> Eine Roll-Box um Code, der physikalisch zu groß für den Bildschirm ist,
> könnte da eine Lösung sein.

Gute Idee.

Rufus Τ. Firefly schrieb:
> Johann L. schrieb:
>> Eher störend find ich überbreiten Text wie in
>> Beitrag "undefined reference to `__sync_val_compare_and_swap_4' error at
> compilation, using gcc 4.1.1 and 4.2"
>>
>> Eine Roll-Box um Code, der physikalisch zu groß für den Bildschirm ist,
>> könnte da eine Lösung sein.
>
> Genau die gibt es doch, siehe Anhang.

Nö, offenbar nicht für Opera. Da is keine horizontal-scroll-box

Johann L. schrieb:
> Nö, offenbar nicht für Opera. Da is keine horizontal-scroll-box
Dann ist Opera der Meinung, dass das so besser sei (oder Version < 7):

--> http://www.css4you.de/overflow.html (ist für das Element auf 
overflow: auto)

Mark Brandis schrieb:
>> Eine Roll-Box um Code, der physikalisch zu groß für den Bildschirm ist,
>> könnte da eine Lösung sein.
>
> Gute Idee.

Bloß nicht. Ich ärgere mich im ruby-Umfeld dauernd über solchen 
Scheiß...

Das kommt der Wiedereinführung von 640x480-Bildschirmen gleich.

Läubi .. schrieb:
> Johann L. schrieb:
>> Nö, offenbar nicht für Opera. Da is keine horizontal-scroll-box
> Dann ist Opera der Meinung, dass das so besser sei (oder Version < 7):

Es ist Version 10.x

Irgendwelche Eigenen Einstellungen?

1

auto - Die Einstellung ist Browserabhängig, sollte aber scroll sein.

Läubi .. schrieb:
> Irgendwelche Eigenen Einstellungen?
>> auto - Die Einstellung ist Browserabhängig, sollte aber scroll sein.

Wo muss das senn eingestellt werden? In Opera kann man eigene Styles 
angeben, was ich aber nicht gemacht habe.

Ich sehe weder in screen.css noch in forum.css von µC das da was auf 
"scroll" gesetzt wird.

Johann L. schrieb:
> screen.css

Der relevante Eintrag ist:

1

DIV.code DIV {

2

 PADDING-BOTTOM: 7px;

3

 MARGIN: 0px; 

4

 PADDING-LEFT: 7px; 

5

 PADDING-RIGHT: 7px; 

6

 OVERFLOW: auto; 

7

 PADDING-TOP: 7px

8

}

Das 'OVERFLOW: auto' überläßt dem Browser die Wahl und hat normalerweise 
die Auswirkung, dass Elemente welche (nach Meinung des Browsers!) noch 
genug Platz haben ohne, sobald der Platz knapp wird (nach Meinung des 
Browsers!) ein scrollbalken angezeigt wird.

Warum Opera da jetzt abweicht kann ich nicht sagen, deshalb habe ich 
vermutet, dass es da eventuell eine Option gibt welche man aktivieren 
kann, eventuell liegt das auch daran das eines der parrent elemente 
einen unbeschränkte Größe hat.

Ein generelles

1

overflow: scroll

führ leider in einigen Browsern dazu das immer scrollbalken (in beide 
Ausdehnungen) angezeigt werden, was doch sehr suboptimal ist.

Johann L. schrieb:
> In Opera kann man eigene Styles
> angeben
Du könntest mal versuchen bei den eigenen Styles

1

DIV.code PRE {

2

 max-width: 400px;

3

}

 zu definieren.

Habe hier einen Opera 11.61, der mir im verlinkten Thread Scrollboxen 
anzeigt.
Scheint also irgendwo zwischen Version 10 und der aktuellen behoben 
worden zu sein.

overflow ist ja ganz nett, nur lesen kann man den Quelltext dann
nicht mehr - es fehlt die Übersicht.

Joachim Drechsel schrieb:
> overflow ist ja ganz nett, nur lesen kann man den Quelltext dann
> nicht mehr - es fehlt die Übersicht.

Das ist aber ein Problem des Quelltextautors, dem man schwerlich
auf der Server- oder Browserseite sinnvoll beikommen kann.

Wenn man konservativ programmiert, hält man sich an 80 Zeichen pro
Zeile.  Auf allem außer einem Mobiltelefon sollte das ohne Rollbalken
darstellbar sein. ;-)  Wenn man noch konservativer ist, nimmt man
noch einen klassischen TAB mit 8er-Spaltenraster für Einrückungen.
Alles, was da nicht mehr sinnvoll passt, lagert man dann lieber in
("static" markierte) Funktionen aus.

Jörg Wunsch schrieb:
> Das ist aber ein Problem des Quelltextautors, dem man schwerlich
> auf der Server- oder Browserseite sinnvoll beikommen kann.

Nein. Das ist ein Problem dessen, der den Schlonz lesen möchte.

Jörg Wunsch schrieb:
> Wenn man konservativ programmiert, hält man sich an 80 Zeichen pro
> Zeile.  Auf allem außer einem Mobiltelefon sollte das ohne Rollbalken
> darstellbar sein. ;-)  Wenn man noch konservativer ist, nimmt man
> noch einen klassischen TAB mit 8er-Spaltenraster für Einrückungen.
> Alles, was da nicht mehr sinnvoll passt, lagert man dann lieber in
> ("static" markierte) Funktionen aus.

Logisch ;) Deshalb verwende ich immer noch meinen alte DOS-Editor ...

Mal ein anderer Ansatz:

Längere Listings haben ja fast immer ein "main(" drin. Man könnte
den Post vor dem Speichern dann ablehnen wenn's mehr wie 20 Zeilen
sind.

Joachim Drechsel schrieb:
> Das ist ein Problem dessen, der den Schlonz lesen möchte.

Ich möchte das Zeug nicht mehr lesen, wenn der Autor zu faul war,
es leserlich aufzuschreiben.  Damit wäre das Problem dann wieder beim
Autor, der ja in aller Regel gern Hilfe hätte.

Jörg Wunsch schrieb:
> Das ist aber ein Problem des Quelltextautors, dem man schwerlich
> auf der Server- oder Browserseite sinnvoll beikommen kann.
>
> Wenn man konservativ programmiert, hält man sich an 80 Zeichen pro
> Zeile.

Das sehe ich auch so. Und wenn man vom Editor Tabs (Schrittweite 2 oder 
4) durch Spaces ersetzen lässt, sehen die Einrückungen auch im Browser 
oder Texteditor (deren Tabs andere Schrittweiten haben) sauber aus.

Jörg Wunsch schrieb:
> Ich möchte das Zeug nicht mehr lesen, wenn der Autor zu faul war,
> es leserlich aufzuschreiben.

Ich auch nicht. Wobei ich mich nicht auf C beziehe, sondern auf ASM bzw. 
auch Bascom.

...

Jörg Wunsch schrieb:
> Wenn man konservativ programmiert, hält man sich an 80 Zeichen pro
> Zeile.

Ich finde das für alles außer ASM ziemlich weltfremd. Die 80 Zeichen 
waren ein technischer Kompromiß, weil früher die Bildschirme mal 80 
Zeichen breit waren.

Bemerkenswert ist, daß man die 80 Zeichen auch voll ausnutzte und daß 
auch früher die Bildschirme i.d.R. breiter, als hoch waren.

Mit dem technischen Fortschritt wuchs die Breite der Schirme sogar 
stärker, als die Höhe und die alten Regeln für Längenbeschränkungen von 
Namen in Programmen sind Computer-Steinzeit und niemand tut sich sowas 
heute noch an.

Vor diesem Hintergrund Quelltexte mit 80 Zeichen Breite zu fordern, ist 
einfach nur absurd: Die heutige Bildschirmbreite wird nur zu Bruchteilen 
ausgenutzt, was natürlich zur Folge hat, daß sie in die Länge gehen. 
Selbst wenn man die volle Bildschirmhöhe für so einen Sehschlitz 
ausnützt - was natürlich zur "konservativen" Programmierideologie 
überhaupt nicht paßt - bleibt der Überblick auf der Strecke.

Ein weiteres Relikt sind TABs. Früher positionierte TAB praktisch immer 
auf die nächste 8er-Position - für ASM-Programme ist das ganz praktisch, 
für höhere Programmiersprachen i.d.R. nicht. Deswegen baute man in die 
Editoren die Möglichkeit ein, die TAB-Länge zu definieren und handelte 
sich damit ein, daß die TAB-Darstellung von Umgebungsparametern abhängt.

Das mag in einem Projekt, das immer mit derselben IDE bearbeitet wird, 
nicht weiter stören, aber wenn der Text die IDE verläßt - z.B. um hier 
gepostet zu werden -, dann werden TABs zum Unsicherheitsfaktor, der nach 
Murphy immer dann das Layout zerfetzt, wenn es wegen Zeitdruck am aller 
wenigsten in den Kram paßt.

Ergo:
Keine Begrenzung auf 80 Zeichen, Horizontal-Scroller, 
Quelltext-Mäusekinos und ähnliche Schikanen im Forum.

Mein Rat an die Programmierer: TABs in Leerzeichen umsetzen lassen.

Probleme sollte man kurz, knapp und präzise formulieren.

Das neumodische Geschwafel mit ewig langen Variablen- und
Funktionsnamen geht mir auf den Senkel.

  DieseVariableZaehltDenZählerHoch += 1;

Wasa ein Käse. 80 Zeichen reiche völlig (auch auf meinem 30 Zöller).

Joachim Drechsel schrieb:
> Wasa ein Käse. 80 Zeichen reiche völlig (auch auf meinem 30 Zöller).

Das kannst du im stillen Kämmerlein halten, wie du willst.

Nur wenn du mit anderen zusammenarbeiten und pflegbaren Code 
produzieren mußt, dann wirst du entweder kommentieren, oder einigermaßen 
selbsterklärenden Code schreiben müssen und dazu sind dermaßen 
künstliche Beschränkungen nicht sehr nützlich - zumindest wenn es sich 
nicht im Trivialprogramme handelt.

Uhu Uhuhu schrieb:
> Nur wenn du mit anderen zusammenarbeiten und pflegbaren Code
> produzieren mußt, dann wirst du entweder kommentieren, oder einigermaßen
> selbsterklärenden Code schreiben müssen und dazu sind dermaßen
> künstliche Beschränkungen nicht sehr nützlich - zumindest wenn es sich
> nicht im Trivialprogramme handelt.

Das hängt davon ab ob dokumentiert und nicht sinnlos herumschradroniert
wird. Statt "MeinErsterSchleifenzaehler" nehme ich lieber ein "i".

Joachim Drechsel schrieb:
> Das hängt davon ab ob dokumentiert und nicht sinnlos herumschradroniert
> wird. Statt "MeinErsterSchleifenzaehler" nehme ich lieber ein "i".

Man kann natürlich immer das Kind mit dem Bade ausschütten und Leute, 
die von nichts eine Ahnung haben, tendieren zu sinnlosen 
Gehorsamsleistungen - aber die meinte ich eigentlich nicht.

Uhu Uhuhu schrieb:
> Jörg Wunsch schrieb:
>> Wenn man konservativ programmiert, hält man sich an 80 Zeichen pro
>> Zeile.
>
> Ich finde das für alles außer ASM ziemlich weltfremd.

Nö. Es gehört zum Beispiel zu den GNU Coding rules und ist damit für GNU 
Quellen verbindlich.

Und ich finde diese Beschränkung auch sinnvoll.

Zu längeren Zeilen kommt es zB wenn jemand 1:1 eine Kommandozeile postet 
oder die Kommanozeilenausgabe eine Tools, wie zB Fehlermeldung von GCC.

> Mein Rat an die Programmierer: TABs in Leerzeichen umsetzen lassen.

Mein Rat: Erst garkeine TABs verwenden. TABs bringen nur Ärger.

Ausnahme: Sie sind Teil der Semantik wie in Makefile, da müssen 
natürlich TABs stehen.

Joachim Drechsel schrieb:

> Längere Listings haben ja fast immer ein "main(" drin. Man könnte
> den Post vor dem Speichern dann ablehnen wenn's mehr wie 20 Zeilen
> sind.

Sorry, aber das ist doch Käse. Das führt doch nur dazu, daß noch mehr 
Märchencode gepostet wird wie

1

// code

2

...

3

//noch mehr code

4

a = 1;  // <-- HIER PROBLEM

5

...

Das Problem ist in 99% der Fälle in den Pünktchen-Pünktchen-Pünktchen.

Uhu Uhuhu schrieb:
> Die 80 Zeichen
> waren ein technischer Kompromiß, weil früher die Bildschirme mal 80
> Zeichen breit waren.

Jein, es gab auch zu Zeiten von Terminals schon 132 Spalten, hat
trotzdem niemand benutzt.

Die heutigen breiten Bildschirme kann man natürlich trotzdem sinnvoll
benutzen, da man neben dem Quelltext beispielsweise das unerlässliche
Datenblatt oder einen zweiten Quelltext anzeigen kann.

Zugegeben, auch ich nehme zuweilen mehr als 80 Zeichen, aber das Forum
hat (je nach Bildschirmgröße) ja mit 100 Zeichen noch kein Problem.
Wer aber 150 oder 200 Zeichen auf eine Zeile stopfen muss, nur weil
er das Fenster auf seinem Bildschirm so breit gezogen bekommt, der
hat irgendwie ein Problem, den Code vernünftig zu strukturieren.

Johann L. schrieb:
>> Mein Rat an die Programmierer: TABs in Leerzeichen umsetzen lassen.
>
> Mein Rat: Erst garkeine TABs verwenden. TABs bringen nur Ärger.

Das sehe ich nicht so. Wenn die TAB-Taste so interpretiert wird, daß sie 
bis zu einer bestimmten Position Leerzeichen auffüllt, dann ist sie 
durchaus hilfreich, ohne daß TAB-Zeichen in den Text eingefügt würden. 
So war mein Rat auch gemeint.

> Uhu Uhuhu schrieb:
>> Die 80 Zeichen
>> waren ein technischer Kompromiß, weil früher die Bildschirme mal 80
>> Zeichen breit waren.
>
> Jein, es gab auch zu Zeiten von Terminals schon 132 Spalten, hat
> trotzdem niemand benutzt.

Drucker waren oft 132 Zeichen breit, während 132er Bildschirme zumindest 
in Programmiererkreisen eher selten waren. "Normal" waren 80 Zeichen und 
24 Zeilen.

Die ersten Computerbildschirme, die ich kennengelert habe, hatten keine 
Rasterzeichengenerierung, sondern hatten für jedes Zeichen einen eigenen 
Generator, der den X/Y-Verlauf wie auf einem Oszilloskop dargestellt 
hat. Die Zeichen sahen etwas eigenwillig aus und der grüne Phosphor der 
Röhre leuchtete recht lange nach.

> Wer aber 150 oder 200 Zeichen auf eine Zeile stopfen muss, ...

Das meine ich nicht. Mir reichen i.d.R. 100 Zeichen und das kommt der 
Übersichtlichkeit zugute, insbesondere, wenn üppig und einheitlich 
ausgerichtet kommentiert wird.

Uhu Uhuhu schrieb:
> Die Zeichen sahen etwas eigenwillig aus und der grüne Phosphor der
> Röhre leuchtete recht lange nach.

Sowas gab es mal von Siemens, mit 64 Zeichen je Zeile in 16 Zeilen, wenn 
ich mich recht erinnere.

Mein erstes eigenes (selbstgebautes) Terminal stellte 96 Zeichen pro 
Zeile dar, in 25 Zeilen und es nutzte eine 9x12-Matrix. Da ich einen 
ebenfalls sehr lang nachleuchtenden Monitor hatte, konnte ich auch auf 
Interlace-Betrieb mit 50 Zeilen umschalten ...

Uhu Uhuhu schrieb:
> Wenn die TAB-Taste so interpretiert wird, daß sie
> bis zu einer bestimmten Position Leerzeichen auffüllt, dann ist sie
> durchaus hilfreich, ohne daß TAB-Zeichen in den Text eingefügt würden.

Genau das habe ich gemeint. AS4 macht das so, wenn man es bei den 
Editor-Optionen so einstellt. Allerdings nur für neu geschriebenen 
Quältext, bei Kopien bleiben die Tabs erhalten.

Auch ich versuche, 80 Zeichen nicht zu überschreiten, denn ich drucke 
mir gern mal zur Fehlersuche eine Routine aus. Und aufgrund der nicht 
mehr taufrischen Augen meide ich dabei grafikorientierte Charsets und 
drucke im ASCII-Mode, was schöne große gut lesbare und unterscheidbare 
Zeichen ergibt.

C mache ich zwar nicht, aber in BASIC (QB, VB6, seltener auch Bascom) 
nutze ich Tab-Schrittweite 2, was auch eine gut sichtbare Struktur 
ergibt. Denn ich will ja hinter dem Code noch etwas Platz für Kommentare 
haben. Das ist auch ein Grund, weshalb ich kurze prägnante Bezeichner 
bevorzuge.

...

Die würde bloß hier nicht greifen, weil der Poster des Spaghetticodes 
den noch nicht mal als Code gekennzeichnet hat.

Man könnte hier natürlich eine generelle Zeilenbeschränkung einführen, 
aber das wäre erst recht vollkommen kontraproduktiv.

Oder Andreas baut hier eine semantische Analyse ein, die herausfindet, 
was für eine Art Text da gepostet wird, den dann je nach verwendeter 
Programmiersprache auch noch durch einen Code-Beautifier sendet und mit 
geeigneten Quelltext-Tags versieht. Dann kann man auch gleich noch eine 
Rechtschreibkorrektur, Geplenke und grobe Beleidigungen entfernen, und 
unlogische Fragen als solche kennzeichnen ...

Sicher.

Also betrachten wir doch mal die Situation, wie sie ist: Einige wenige 
Trottel posten hier manchmal ellenlange Quelltexte, aber die sehr 
deutlich überwiegende Mehrheit macht das nicht.

Muss jetzt nur wegen einiger gelegentlich mal postender Trottel die 
Forensoftware angepasst werden?

Rufus Τ. Firefly schrieb:
> Muss jetzt nur wegen einiger gelegentlich mal postender Trottel die
> Forensoftware angepasst werden?

Nun, eigentlich wäre der Themenersteller dafür verantwortlich, die 
fehlenden code-Tags nachträglich einzubauen. Freilich hat er alsbald 
nicht mehr die Möglichkeit dazu.

Warum das so ist, wurde hier bereits ad nauseam ausdiskutiert. Und ich 
habe keine Lust darauf, das jetzt zu wiederholen.

Rufus Τ. Firefly schrieb:
> Und ich habe keine Lust darauf, das jetzt zu wiederholen.

Das macht ja Mark Brandis für uns alle...

Joachim Drechsel schrieb:
> Probleme sollte man kurz, knapp und präzise formulieren.
>
> Das neumodische Geschwafel mit ewig langen Variablen- und
> Funktionsnamen geht mir auf den Senkel.
>
>   DieseVariableZaehltDenZählerHoch += 1;
>
> Wasa ein Käse. 80 Zeichen reiche völlig (auch auf meinem 30 Zöller).

Tja! Mir gehen diese "Ich kann auch alles abkürzen und kryptische 
Variablennamen benutzen" Menschen auf den Senkel.

  dvzdzh += 1;

Ja, wesentlich besser! ...

Die meisten Monitore sind heute groß genug für wesentlich mehr als 80 
Zeichen pro Zeile. Und einen ausgedruckten Code habe ich auch noch nie 
gesehen (Das Argument zählt also nicht).
Dauernd an uralten Vorgaben festzuhalten ist nicht immer zielführend und 
oft auch albern.

Möglicherweise kann das daran liegen, dass wir unterschiedlicher 
"Altersklassen" angehören.

Zu dem TAB Argument: Übliche IDEs lassen sich so einstellen, dass pro 
TAB 4 Leerzeichen eingefügt werden. Also die TAB-Taste sollte dann schon 
benutzt werden.

PS: Und ich möchte noch mal betonen, dass Programmieren eine Art von 
Kunst ist und es somit völlig normal und gesund ist, dass es 
unterschiedliche Ansichten gibt.

Simon K. schrieb:
> Zu dem TAB Argument: Übliche IDEs lassen sich so einstellen, dass pro
> TAB 4 Leerzeichen eingefügt werden. Also die TAB-Taste sollte dann schon
> benutzt werden.

Ich glaub ich hab bis auf wenige Ausnahmen seit Jahren keinen Quellcode 
mehr per Hand formatiert/eingerichtet dafür gibt es Autoformater, dann 
kann einem auch ein Fremder Quelltext nicht mehr schrecken und man kann 
es einstellen wie es einem beliebt.

Arbeitet man im Team sollte man sich einfach auf einen Stil einigen, 
ob der zu dem persönlichem Geschmack passt sollte einen aber auch nicht 
in eine Sinnkriese stürzen es gibt wahrlich wichtigeres im Leben.

Simon K. schrieb:
> Und einen ausgedruckten Code habe ich auch noch nie
> gesehen

Soso.  Wieviel hast du denn schon so programmiert, und wie groß war
dein größtes Projekt?  Hast du schon mal in einem Team Code Reviews
durchführen müssen?  Nein, das macht man nicht mit "live mal schnell
ändern" am Bildschirm, sondern mit Zettel und Stift und einem
Ausdruck.

Ganz davon abgesehen, zuweilen mach' ich sowas auch für meine eigenen
Projekte.  Es gibt Situationen, wo man anders gerade nicht mehr
durchblickt.

Was natürlich richtig ist: heutzutage wird niemand mehr standardmäßig
einfach alles ausdrucken, wie das früher noch üblich war, als die
Bildschirmarbeitsplätze knapp waren und man nur aller drei Tage ein
paar Stunden davor sitzen durfte.

Jörg Wunsch schrieb:
> Es gibt Situationen, wo man anders gerade nicht mehr durchblickt.

Je größer die Bildschirme werden, um so seltener kommt das allein aus 
Platzgründen vor und gute IDEs bieten einige Werkzeuge, um den Überblick 
zu schaffen, wo er fehlt.

Früher, als Mäusekinos mit 640x480 Pixel Standard waren, sah die Welt 
des Programmierers deutlich anders aus.

Uhu Uhuhu schrieb:
>> Es gibt Situationen, wo man anders gerade nicht mehr durchblickt.
>
> Je größer die Bildschirme werden, um so seltener kommt das allein aus
> Platzgründen vor und gute IDEs bieten einige Werkzeuge, um den Überblick
> zu schaffen, wo er fehlt.

Genügt mir zuweilen trotzdem nicht.  Erst gestern wieder hat mir
ein Forenteilnehmer ein 5seitiges BASIC-Programm mit der Bitte zum
Review gegeben (der ich aus persönlichen Gründen gern nachgeben
wollte).  Da hätte mir auch der schönste große Bildschirm nicht
geholfen, denn mit seinen 100 dpi Auflösung schafft er (trotz seiner
immensen Größe) nicht das, was ein Drucker mit 600 dpi auf knapp 3
A4-Seiten (1:2 verkleinert, zum Papiersparen) bietet, die ich noch
dazu in Ruhe auf dem Sofa reviewen kann.  Ich hab' auch eine Weile
draufgucken müssen (und noch zweimal mit ihm hin und her mailen),
bevor mir dann schwante, wo der Fehler war.  Und nein, das lag weniger
daran, dass ich seit praktisch 25 Jahren kein BASIC mehr in den
Fingern hatte, sondern eher daran, dass der Fehler sich in die
Untiefen des "historisch gewachsenen" Codes da eingeschlichen hatte.

Der Code hatte übrigens nur wenige Zeilen, die beim Ausdruck umgebrochen
worden sind.  Sonst wäre es mir noch schwerer gefallen, das zu finden.

Jörg Wunsch schrieb:
> Genügt mir zuweilen trotzdem nicht.

Das mag ja sein, nur die Tendenz ist eben, daß man das immer seltener 
wirklich braucht.

Und natürlich muß man Anfängern beizeiten beibringen, wie sie ihren 
Quelltext strukturieren sollten, damit der Überblick erhalten bleibt.

Basic ist so ziemlich das schlechteste Vehikel, das zu lernen.

Uhu Uhuhu schrieb:
> Jörg Wunsch schrieb:
>> Genügt mir zuweilen trotzdem nicht.
>
> Das mag ja sein, nur die Tendenz ist eben, daß man das immer seltener
> wirklich braucht.
>
> Und natürlich muß man Anfängern beizeiten beibringen, wie sie ihren
> Quelltext strukturieren sollten, damit der Überblick erhalten bleibt.
>
> Basic ist so ziemlich das schlechteste Vehikel, das zu lernen.

Wau, wer hätte gedacht, dass ich dem Uhu mal zustimme.

Jörg, dein Beispiel in allen Ehren, aber das ist eher ein 
Extrembeispiel, wie ich finde.

Jörg Wunsch schrieb:
> Soso.  Wieviel hast du denn schon so programmiert, und wie groß war
> dein größtes Projekt?

Jaja, jetzt hast du mich ;-) Ich bin ja nicht mal hauptsächlich 
Programmierer, auch wenn ich da in letzter Zeit (auch beruflich) ganz 
schön stark reingerutscht bin.

Simon K. schrieb:

> Jörg, dein Beispiel in allen Ehren, aber das ist eher ein
> Extrembeispiel, wie ich finde.

Kann einem mit x-beliebiger, über einige Jahre "gewachsener" Software
passieren, das hat wenig damit zu tun, dass das in BASIC war (außer
dass der konkrete Fehler durch die Wahl der Sprache etwas begünstigt
worden ist).

Wenn man dann erst anfangen will, das Zeug (wo man sowieso gerade
im Zeitdruck ist, denn eigentlich sollte ja alles schon letzte Woche
laufen, nicht? ;) so zu formatieren, dass man es wirklich nun auch
mal ausgedruckt bekommt, dann ist Hopfen und Malz verloren.

Ich will ja auch nicht dogmatisch auf 80 Zeichen/Zeile rumreiten,
ich schrieb ja oben, dass es auch bei mir zuweilen mal bis 100 oder
so geht, wenn es Sinn hat (kann man mit etwas kleinerem Font im
a2ps dann immer noch ausdrucken), aber als Grundregel halte ich
mich schon dran.  Wie geschrieben, den freien Platz links neben
dem Quelltext auf meinem schönen (nun nicht mehr ganz neuen)
großen Monitor spendiere ich dann lieber dem Datenblatt oder einem
Headerfile oder dergleichen.

> Jörg Wunsch schrieb:
>> Soso.  Wieviel hast du denn schon so programmiert, und wie groß war
>> dein größtes Projekt?
>
> Jaja, jetzt hast du mich ;-)

Je größer das Projekt, und je älter es wird (und trotzdem noch ergänzt/
gepflegt werden muss), um so größer wird die Wahrscheinlichkeit, dass
man irgendwann mal Teile davon ausdrucken möchte.

Sicher: in der Tendenz ist das über die Jahre seltener geworden, dass
man sowas macht, aber s. o., wenn man es erst "druckfähig" formatieren
will, wenn das wirklich mal gedruckt werden soll, ist es meist zu spät
dafür.  Gleich entsprechend schreiben ist einfacher.

Jörg Wunsch schrieb:
> Genügt mir zuweilen trotzdem nicht.

Kann ich nachvollziehen. Früher, als ich noch auf einem 80x25-Terminal 
arbeiten durfte, da produzierte ich jeden Monat einen gut 30cm dicken 
Stapel Papier auf dem Schnelldrucker, seitdem die Bildschirmauflösungen 
benutzbarer wurden, hat das allerdings fast vollkommen abgenommen. 
Zumindest gefühlt hat auch die Produktivität etwas zugenommen.

Bei kniffligen Problemstellungen (die nur noch alle paar Monate mal 
vorkommen) aber reicht auch mein hochkant stehender Monitor nicht mehr 
aus, obwohl der über 90 Zeilen Quelltext darstellt.

Sehr hilfreich ist, wenn der Editor - für die Sprache passend - Blocks 
einfalten kann. Damit kann man recht schnell Klarheit über die Struktur 
längerer Codewürste bekommen.

Uhu Uhuhu schrieb:
> Sehr hilfreich ist, wenn der Editor - für die Sprache passend - Blocks
> einfalten kann. Damit kann man recht schnell Klarheit über die Struktur
> längerer Codewürste bekommen.

das ist ein Feature, dass ich höchst selten benutze.
ICh hab dann immer das Gefühl, das mir was wichtiges vorenthalten wird, 
oder der Fehler genau da drin liegt.

Für die Klarheit über die Strukur ist für mich Klammerhighlighting 
unverzichtbar.

Uhu Uhuhu schrieb:
> Sehr hilfreich ist, wenn der Editor - für die Sprache passend - Blocks
> einfalten kann. Damit kann man recht schnell Klarheit über die Struktur
> längerer Codewürste bekommen.

Das halte ich für genauso unnötig wie Syntax-Highlightning.

Es lenkt unnötig ab. Sinnvoller ist eine Aufteilung in einzelne
Funktionen.

Joachim Drechsel schrieb:
> Es lenkt unnötig ab. Sinnvoller ist eine Aufteilung in einzelne
> Funktionen

Kann man bei eigenem Code machen, aber das hilft beim Lesen fremden 
Codes logischerweise nicht.

Rufus Τ. Firefly schrieb:
> Kann man bei eigenem Code machen, aber das hilft beim Lesen fremden
> Codes logischerweise nicht.

Ok.

Joachim Drechsel schrieb:
>
> Das halte ich für genauso unnötig wie Syntax-Highlightning.

Syntax-Highlightning ist -wenn dezent gemacht- sehr gut, um syntaktische 
Fehler zu finden.
Um syntaktische Fehler erst gar nicht zu produzieren, ist die 
Code-Vervollständigung da.

Vlad Tepesch schrieb:
> das ist ein Feature, dass ich höchst selten benutze.

Ich benutze es auch selten. Wenn man jedoch Überblick über eine 
umfangreichere Blockstruktur bekommen will, ist es durchaus praktisch.

Eine andere, sehr nützliche Funktion ist Match Brace.

Joachim Drechsel schrieb:
> Das halte ich für genauso unnötig wie Syntax-Highlightning.

Das kannst du halten, wie du willst

> Sinnvoller ist eine Aufteilung in einzelne Funktionen.

Nur, was machst du, wenn du von einem lieben Kollegen eine 
20-Seiten-Funktion übernehmen mußt?

Dann wirs du die Wurst wohl selbst in einzelen Funktionen aufteilen 
müssen und dazu sind so kleine Helferlein schon mal ganz nützlich.

Stefan B. schrieb:
> Syntax-Highlightning ist -wenn dezent gemacht- sehr gut, um syntaktische
> Fehler zu finden.

Ich finde es nur begrenzt nützlich, ich komme genauso gut ohne aus. Aber 
es lenkt weniger ab, als die schöne Nachbarin ;-)