Hallo,
häufig sieht man Threads in denen seitenweise C-Code gepostet wird,
richtig formatiert ([c ] [/c ]) oder auch nicht. Beispiel:
Beitrag "Re: Vorzeichen Ausgeben" Das stört den
Lesefluss ganz gehörig. Könnte man nicht eine FUnktion einbauen die bei
zu viel C-Code das Abschicken des Beitrags sperrt (o.ä.) und die Leute
so zwingt den Code als Datei anzuhängen?
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 :-)
um den Code ein bisserl aufzupeppen habe ich die Seite hier im Web
gefunden dann man man ihn auch gut lesen ;-)
http://tohtml.com/
wird html Formatierung denn hier richtig angezeigt ???
schöne grüße
Chris
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 ...
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.
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.
Mark Brandis schrieb:> 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.
Ach, und du bist hier Chef, oder was?
Wenn zuviel Code stört, dann kann an ja eine art "Klappfunktion" ins
BB-Code integrierten. So wird nur ein Link anstelle des Codes angezeigt
und beim draufklicken wird der Inhalt angezeigt.
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 ...
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?
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
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.
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
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.
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.
...
Back to topic, hier mal wieder ein wunderbares Beispiel warum eine "Wenn
zu viel Code Absenden nicht möglich"-Funktion nötig ist:
Beitrag "Hilfe Triacs explodieren"
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.
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.
Servus Leute
ich habe jetzt mal nur die ersten paar Beiträge hier gelesen da es mir
irgendwann zu OT wurde. Daher möge man mir bitte nachsehen falls mein
Vorschlag hier schon genannt wurde.
Wie wäre es denn mit einem ausklappbaren "Spoiler" für Code Tags > 20
Zeilen?
Falls das mit der Forensoftware möglich ist wäre das mMn eine gute
Lösung.
MfG
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.
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 ;-)