Hallo, wenn ihr Quellcodefragmente in eine Dokumentation aufnehmen wollt, wie stellt ihr das dar, wenn ihr in der nächsten Zeile weiterschreibt es aber eigentlich keinen Umbruch geben dürfte. Also: Dies ist eine sehr lange Programmzeile welche in der doku umgebrochen werden muss aber wenn man es verwenden möchte alles in einer Zeile stehen muss. Macht ihr das so: Dies ist eine sehr lange Programmzeile \ welche in der doku umgebrochen werden muss \ aber wenn man es verwenden möchte alles in \ einer Zeile stehen muss. oder so: Dies ist eine sehr lange Programmzeile -> welche in der doku umgebrochen werden muss -> aber wenn man es verwenden möchte alles in -> \ einer Zeile stehen muss. -> Gibt es da evtl. irgendeine Zitiernorm? vielen Dank...
Am besten die zu langen Programmzeilen schon im Programm umbrechen. Und auf zu große Einrückabstände verzichten. 2 Zeichen pro Einrückung reichen.
Ralf Liebau schrieb: > Hallo, > wenn ihr Quellcodefragmente in eine Dokumentation aufnehmen wollt, wie > stellt ihr das dar, wenn ihr in der nächsten Zeile weiterschreibt es > aber eigentlich keinen Umbruch geben dürfte. > > Also: > Dies ist eine sehr lange Programmzeile welche in der doku umgebrochen > werden muss aber wenn man es verwenden möchte alles in einer Zeile > stehen muss. Da würde ich ansetzen. Warum MUSS alles in einer Zeile stehen? Bei den meisten Programmiersprachen spielen Zeilenumbrüche keine Rolle. > > Macht ihr das so: > Dies ist eine sehr lange Programmzeile \ > welche in der doku umgebrochen werden muss \ > aber wenn man es verwenden möchte alles in > \ einer Zeile stehen muss. > > oder so: > Dies ist eine sehr lange Programmzeile -> > welche in der doku umgebrochen werden muss -> > aber wenn man es verwenden möchte alles in -> > \ einer Zeile stehen muss. -> > > > Gibt es da evtl. irgendeine Zitiernorm? Nicht das ich wüsste. Aber ich würde entweder * auf Biegen und Brechen vermeiden, dass aktueller Code und Zitat in der Doku nicht übereinstimmen. Sprich: Im Zweifel lieber den Original-Code verändern * Das Zitat in der Doku nur andeuten. Wer die Details sehen will, soll in den Originalcode sehen.
1 | // So siehts im Programm aus:
|
2 | langer_variablen_name = geb_mir_was_zurück(ganz_langer_name, auch_lang, noch_viel_laenger, und_noch_mehr_text, funktion_mit_vielen_parametern, und_ich_bin_das_letzte_element); |
3 | |
4 | // So kann man es schöner machen:
|
5 | langer_variablen_name = geb_mir_was_zurück(ganz_langer_name, |
6 | auch_lang, noch_viel_laenger, |
7 | und_noch_mehr_text, |
8 | funktion_mit_vielen_parametern, |
9 | und_ich_bin_das_letzte_element); |
So mach ich es meistens wenn ich mich nicht an irgendwelche Richtlinien richten muss.
Und von welcher (Programmier-)sprache sprichst du? Zumindest die "->" Notation ist mir nicht bekannt. Üblicherweise benutzt man hierfür in der Tat den Backslash. Allerdings sollte man - zumindest meiner Meinung nach - soweit wie möglich darauf verzichtenn, da du dir ansonsten schwer tust den Quellcode nach eben diesem String zu durchsuchen (z.B. mittels grep). Udo Schmitt schrieb: > 2 Zeichen pro Einrückung > reichen. Wofür? Um nicht deutlich zu machen, dass es sich um eine Einrückung handelt? Da reichen in der Tat 2. Alle anderen benutzen, wie es eigentlich auch der Standard ist 4.
Ralf Liebau schrieb: > Dies ist eine sehr lange Programmzeile welche in der doku umgebrochen > werden muss aber wenn man es verwenden möchte alles in einer Zeile > stehen muss. das ist doch das Hauptproblem, warum hast du zeilen mit mehr als 80 Zeichen? Hast du dich noch nie darüber gewundert das oft "ältere" Programierer sich oft daran halten? Damit ist der Quellcode auch wesentlich besser lesber, weil man mehr überblick hat und auch mehre Fenster nebeneinander darstellen kann. (Leider ist die Industrie irgendwie dageben, sie bauen immer breite monitore)
Nachtrag: Code Zitate kann (und sollte man sowiso) in einem nichtproportionalen Zeichensatz machen. Da kann man dann auch einen entsprechend kleineren Zeichensatz benutzen. Falls das eine Diplom, Master oder sonstige Arbeit wird gibt es meist genaue Vorschriften wie die auszusehen hat. Da wird auch sowas definiert.
Peter II schrieb: > (Leider ist die Industrie irgendwie dageben, sie bauen immer breite > monitore) Dann kann man endlich mal mehrere Dokumente gleichzeitig nebeneinander haben!
Peter II schrieb: > (Leider ist die Industrie irgendwie dageben, sie bauen immer breite > monitore) Was ja auch cool ist. Der Platzgewinn ist nicht zu verachten. Trotzdem gebe ich unumwunden zu, meine Codezeilen nicht allzulang zu machen. Mich persönlich ermüdet das nämlich auch sehr schnell, wenn ich da elends lange Code-Zeilen in einer Wurscht lesen muss. Durch Umbrüche kriegt man ja auch eine Struktur rein, die einem beim Entschlüsseln des Codes hilft.
Udo Schmitt schrieb: > Dann kann man endlich mal mehrere Dokumente gleichzeitig nebeneinander > haben! aber nicht wenn es auf kosten der höhe geht. Unter 1200px in der höhe sollte minimum sein. Dann ist mir egal wie breit er ist. Aber doch nicht 1900 x 1080.
Bei Fortran95 darf die Zeile zum Beispiel nicht beliebig lang sein, da der Compiler nach einer bestimmten String-Länge einfach kappt.
Peter II schrieb: > aber nicht wenn es auf kosten der höhe geht. Unter 1200px in der höhe > sollte minimum sein. Dann ist mir egal wie breit er ist. Aber doch nicht > 1900 x 1080. Frommer Wunsch. Ich war früher begeistert als ich von einem 320 x 200 auf einen 720 * 348 (Hercules Karte) monochrom Bildschirm mit langer Nachleuchtdauer wechseln konnte, da hat man sich gefühlt wie ein König. Ihr seid heute echt verwöhnt :-)
dgps schrieb: > Bei Fortran95 darf die Zeile zum Beispiel nicht beliebig lang sein, da > der Compiler nach einer bestimmten String-Länge einfach kappt. .... ein Überbleibsel aus der Lochkartenzeit. Der Pack Lochkarten ist einem nämlich ab und an schon mal runtergefallen. Wer sich dann die Karten in den letzten Zeichen der 80-spaltigen Karten durchnummeriert hat (die extra dafür vorgesehen waren), der war gut drann. Mit einem Sortierprogramm konnte man den ungeordneten Haufen Karten wieder in der richtigen Reihenfolge neu auf Karten stanzen lassen.
Karl Heinz Buchegger schrieb: > wieder in der richtigen Reihenfolge neu auf > Karten stanzen lassen. Tja, damals hatte ein Programm noch 'Substanz'. :-)
mr. mo schrieb: >
1 | > // So siehts im Programm aus: |
2 | > langer_variablen_name = geb_mir_was_zurück(ganz_langer_name, auch_lang, |
3 | > noch_viel_laenger, und_noch_mehr_text, funktion_mit_vielen_parametern, |
4 | > und_ich_bin_das_letzte_element); |
5 | >
|
6 | > // So kann man es schöner machen: |
7 | > langer_variablen_name = geb_mir_was_zurück(ganz_langer_name, |
8 | > auch_lang, noch_viel_laenger, |
9 | > und_noch_mehr_text, |
10 | > funktion_mit_vielen_parametern, |
11 | > und_ich_bin_das_letzte_element); |
12 | >
|
> > So mach ich es meistens wenn ich mich nicht an irgendwelche Richtlinien > richten muss. Was ich auch nicht verstehen kann, sind Leute die Code so schreiben:
1 | gewinn_summe = gewinn_deutschland + gewinn_frankreich + gewinn_belgien + gewinn_italien + gewinn_spanien + gewinn_polen + gewinn_ungarn + gewinn_schweden + gewinn_norwegen + gewinn_griechenland + gewinn_tuerkei; |
Früher oder später kommt nämlich mal eine Code-Änderung, bei der ein Summand wegfällt. Oder hinzukommt. Oder beides! Das sieht dann im "diff" ganz toll aus, wenn man in solche langen Zeilen die Änderung optisch nachverfolgen darf. Jeder der halbwegs klar geradeaus denken kann schreibt es doch wohl so:
1 | gewinn_summe = gewinn_deutschland |
2 | + gewinn_frankreich |
3 | + gewinn_belgien |
4 | + gewinn_italien |
5 | + gewinn_spanien |
6 | + gewinn_polen |
7 | + gewinn_ungarn |
8 | + gewinn_schweden |
9 | + gewinn_norwegen |
10 | + gewinn_griechenland |
11 | + gewinn_tuerkei; |
Dem Compiler ist es schietegal. Den nächsten Menschen, der diese Code-Stelle ändern muss, freut's.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.