Was machen Programmier-Anfänger mit ihren Fragen?

[eggy]

Verstehe ich das richtig, dass Du meinst, dass man es so einrichten sollte, dass alle Funktionen nur zwischen 10 und 15 Zeilen lang sind?

Ich denke, dass man da keine Zahl nennen kann. Außerdem: keine Regel ohne Ausnahme.

Es wird oft empfohlen, dass man Funktionen nicht größer schreiben sollte, als das was man noch gut "mit einem Blick" erfassen kann.
Früher war die Metrik dafür mal "eine (Bildschirm-)Seite". Da heute manche Leute aber ne halbe Kinoleinwand vor sich aufgebaut haben, nicht mehr in allen Fällen anwendbar. Außerdem kommt es sehr auf die benutzte Sprache an, manchmal ist ne Methode in der einen Sprache nen Dreizeiler, während in anderen dreizig Zeilen allein für die Initialisierung der Variablen nötig sind.

Versuche Code, wenn möglich, in kleinste "Sinneinheiten" aufzuteilen. Immer wenn Du nen Block mit if/while/etc vor Dir hast, der komplizierter als "ist die Zahl ungrade" ist, frag Dich: welchen Nachteil habe ich, wenn ich das hier in ne Funktion auslagere? Wenn Dir nicht sofort nen guter Grund einfällt: ab in ne eigene Funktion.

Spoiler: Die nächsten paar Monate wirst Du wirklich schrecklichen Code schreiben. Jeder Krümel Code wird in ner eigenen Funktion landen. Deine Header werden Kilometer lang. Keine Sorge. Das ist ok. Für jetzt. Zuerst nervt es dich. Ignorier das. Dann hast Du Dich dran gewöhnt. Dich wird es einige Zeit lang nicht stören. Dann nervt es Dich wieder. Das ist der richtige Zeitpunkt, anzufangen wieder etwas größere Funktionen zu schreiben. Jetzt solltest Du in der Lage sein, zu beurteilen, an welchen Stellen "Mikromodule" sinnvoll waren und an welchen Stellen es übertrieben war.

[Meillo]

Am sinnvollsten finde ich es, viel guten Code zu lesen und darueber ein Gefuehl dafuer zu bekommen, wie man Code sinnvoll strukturiert und unterteilt. Natuerlich gibt es unterschiedliche Meinungen darueber, was guter Code ist. Da wird man sich nie komplett einig werden. Nur verschiedene groessere Ziele werden vermutlich gemeinsam angestrebt werden. Mit welchen Mitteln man das aber erreicht, da gibt es schon wieder Kulturunterschiede.

Ich empfehle, sich mit der Frage, was guter Code ist, zu beschaeftigen. Sich die Meinungen der verschiedenen Communities anzuhoeren und mit der eigenen Erfahrung und den eigenen Vorstellungen zu pruefen. Code zu diskutieren. So kann man sich ueber Jahre und Jahrzehnte gutem Code annaehern. Man wird meist Komprimisse machen muessen, weil sich manche Ziele widersprechen. Aber man sollte dies realisieren und begruenden koennen, warum man sich gerade so oder so entschieden hat.

Konkret: Implementiere dein mycompare() nun in anderer Weise und vergleiche anschliessend die beiden Varianten. Welche ist besser. Dann fertige nochmal eine neue Variante an ... Mache mal die Funktionen so klein wie moeglich und mal ziemlich gross. Lese vor allem fremden Code, der ganz kleine Funktionen hat und lese fremden Code, der grosse Funktionen hat. Lese verschiedene Implementierungen des gleichen Programms, z.B. GNU ed vs. Heirloom ed, oder verschiedene cut(1)-Implementierungen, wie ich es hier gemacht habe: http://marmaro.de/docs/freiesmagazin/cut/ . Wenn du Suckless magst, dann vergleiche deren 9base mit den GNU Coreutils und den entsprechenden BSD-Programmen. Oder vergleiche dwm mit larswm (der die engste Vorlage fuer dwm war), desweiteren kannst du dir dazu noch ion und ratpoison anschauen. Freie Software bietet diese Moeglichkeit, nutze sie!

[MSfree]

Am sinnvollsten finde ich es, viel guten Code zu lesen

Sowas? https://www.ioccc.org/

*SCNR*

[Meillo]

Am sinnvollsten finde ich es, viel guten Code zu lesen

Sowas? https://www.ioccc.org/

Natuerlich gibt es unterschiedliche Meinungen darueber, was guter Code ist.

[ViNic]

Natuerlich gibt es unterschiedliche Meinungen darueber, was guter Code ist. Da wird man sich nie komplett einig werden. Nur verschiedene groessere Ziele werden vermutlich gemeinsam angestrebt werden.

Entwicklerteams und Projekte haben oft auch Coderichtlinien, woran sich alle halten sollten. Ist auch eine Art von gutem Code.

[MSfree]

Entwicklerteams und Projekte haben oft auch Coderichtlinien,...

Wir haben Uncrustify im Pre-Commit-Hook von Subversion (GIT-Migration steht noch aus). Code, der nicht den Anforderungen entspricht, darf gar nicht erst comittet werden.

[ViNic]

Entwicklerteams und Projekte haben oft auch Coderichtlinien,...

Wir haben Uncrustify im Pre-Commit-Hook von Subversion (GIT-Migration steht noch aus). Code, der nicht den Anforderungen entspricht, darf gar nicht erst comittet werden.

Ich weiß nicht ob es stimmt, aber GitLab soll auch eine Qualitätsprüfung von Code machen. Habe es mir aber nur erzählen lassen. In wieweit das stimmt, kann ich jetzt nicht sagen, da ich GitLab nicht nutze und kenne. Aber vielleicht auch ein Tipp.

Edit: Ein nachträglich prüfender Blick auf GitLab (https://about.gitlab.com/) zeigt, das es eine Qualitätskontrolle wohl doch macht.

[RobertDebiannutzer]

Jetzt bin ich fast fertig mit der neuen Version meiner Funktion, da fällt mir auf, warum der von "Toby Speight" vorgeschlagene, von @meillo unterstützte und von mir ja auch ursprünglich eingeschlagene Weg wohl doch besser als mein aktueller ist...
Der Hase liegt dort im Pfeffer, wo über die Continuation Bytes eines Multibyte-Encodings zurückgeloopt wird. Mit UTF-8 läuft das, aber was ist mit anderen Multibyte-Encodings? Ursprünglich hatte ich nur an ASCII und UTF-8 gedacht, aber es ist vielleicht kein Fehler, es doch etwas mehr zu generalisieren. Denn auch bei mir (also Debian 9) sehe ich in /etc/locale.gen doch auch ein paar Encodings, die nicht single-byte oder UTF-8 zu sein scheinen.
Und vor dem Hintergrund ist der "alternative approach" natürlich die einzige Möglichkeit. Also bis zu Zahlen loopen, danach mit strcoll() alles bis dahin vergleichen, wenn gleich, dann Zahlen vergleichen (und dabei Folgezahlen berücksichtigen), wenn gleich, dann von vorne. Kommt keine Zahl vor, ist es ja eh einfach.
Schade, hat Spaß gemacht mit ASCII und UTF-8 zu arbeiten und sich dabei auch mit der Hexadezimal-Darstellung zu beschäftigen... Und schneller war es auch. Aber natürlich geht Funktionalität vor, sonst bringt mir ja auch die Geschwindigkeit nichts.
Apropos Geschwindigkeit:

@eggy: Bezüglich Deines Spoilers - ich glaube nicht, dass mir das passieren wird. Denn da ich mit shell-Scripten angefangen habe, habe ich immer noch die Tendenz, zu viel auf die Performance zu achten, auch wenn die Situation bei C ja eigentlich ganz anders ist. Insofern denke ich nicht, dass ich in das von Dir beschriebene Extrem umschwanken werde. Eher werde ich mich hoffentlich langsam der "Normalform" annähern... Aber vielleicht kommt es ja doch anders, ich werde es ja sehen.

@meillo:
Sehr interessant, Dein Artikel über cut! Wusste gar nicht, was das alles kann. Ich habe das bisher immer mit den Optionen "-d" und "-f" genutzt - wenn überhaupt, denn meistens habe ich versucht, das aus Performance-Gründen wegzulassen und die Aktion, die cut durchgeführt hätte, woanders reinzuschmuggeln (z.B. in einen Aufruf von sed, den ich sowieso hatte, oder in eine shell-Funktionalität wie "${variable#delimiter}" - je nachdem). Ich weiß auch nicht, was ich immer mit der Performance habe...

[ViNic]

Jetzt bin ich fast fertig mit der neuen Version meiner Funktion, da fällt mir auf, warum der von "Toby Speight" vorgeschlagene, von @meillo unterstützte und von mir ja auch ursprünglich eingeschlagene Weg wohl doch besser als mein aktueller ist...

Willkommen in der Welt der Programmierung. Das ist normal. Bedenke das du erst angefangen hast und es real viele Jahre dauern wird, bis du darin auch wirklich gut wirst. Besonders am Anfang wirst du viele Fehler machen. Aber wenn du dabei bleibst und dich darum bemühst besser zu werden, wirst du auch besser. Außerdem wirst du dann auch mal über deinen alten Code oft staunen und sich vielleicht fragen, was hast du dir damals dabei gedacht

Ich habe heute mein erstes Projekt, ein WebCRM, durch Zufall wieder gefunden. Ich will es jetzt gar nicht aufmachen und sehen was da drin steht

[novalix]

Die Einstufung Deiner Frage als "nicht einschlägig" auf der Codereview-Plattform finde ich ein wenig voreilig.
Aber manchmal ist das so, wenn man versucht in komplexen Feldern (ab)grenzende Fäden zu spannen (working code und so). Dabei ist es häufig genug so, dass die Fragen, die von Neulingen aufgeworfen werden, den Eingeweihten dazu auffordern, die damit zusammenhängenden Probleme verständlich - und damit sauber - zu (re)formulieren.
Das kann natürlich zuweilen lästig sein, oder gar die unangenehme Ahnung auslösen, dass das eigene Verständnis löchrig ist. Das ist meiner bescheidenen Meinung nach so wie so der Normalzustand; kein Grund für Scham.[1]

…
Schade, hat Spaß gemacht mit ASCII und UTF-8 zu arbeiten und sich dabei auch mit der Hexadezimal-Darstellung zu beschäftigen... Und schneller war es auch. Aber natürlich geht Funktionalität vor, sonst bringt mir ja auch die Geschwindigkeit nichts.
…

Ohne Scheiß, der Spaß ist viel, viel wichtiger als oftmals angenommen.
Der eingeschlagene Weg führt nicht zu dem Gehöft, das man zu erreichen gedenkt? Sei 's drum.
Man hat einen Teil des Feldes erkundet, an den Blumen geschnuppert, die dort wachsen und die Sicht von diesem Standpunkt aus ergänzt die Vorstellung der Gegend. Manchmal justiert man sogar seinen Kompass neu.

Nach Donald E. Knuth sind 97% der Optimierungen "premature". Wir sollten sie vergessen. Aber die restlichen, wichtigen drei Prozent sollten wir uns keinesfalls durch die Lappen gehen lassen.[2]

[1]Ich schließe da von mir auf andere. Das ist selbstverständlich nicht beweisbar, aber eben auch "normal".

[2]https://en.wikiquote.org/wiki/Donald_Kn ... Art_(1974)

[RobertDebiannutzer]

@novalix:
"Working Code" ist insbesondere bei einem Anfänger keine absolute Feststellung. Und irgendwo muss man seine Frage ja posten. Hier im debianforum habe ich ja auch bereits wieder viele hilfreiche Anregungen bekommen. Und auch die Antwort von dem User bei stackexchange war ja hilfreich, doch erst mit ein wenig Erklärung.
"Lästig" ist mir Kritik nie, dass mein Verständnis "löchrig" ist, ist ja eh klar, wie könnte es auch anders sein. Man kann ja nie gleich alles wissen. Dafür muss sich doch niemand schämen! Vielleicht ist man manchmal kurz enttäuscht, dass noch nicht alles richtig ist, aber diese Enttäuschung weicht ja schnell der Freude, wenn es dann besser wird!

Zu meiner Funktion:
Ich habe jetzt bald beide Ansätze soweit. Warum doch wieder beide?

Der Hase liegt dort im Pfeffer, wo über die Continuation Bytes eines Multibyte-Encodings zurückgeloopt wird.

Das stimmt nicht ganz, denn das Problem kann ich - glaube ich - lösen, wenn ich mich einfach auf den Rückgabewert von mblen verlasse statt auf mein Macro "ISCB" (welches ich geschrieben hatte, um Continuation Bytes zu entdecken, was aber nur bei UTF-8 funktioniert). Der Rückgabewert von mblen ist nämlich -1, wenn ein Continuation Byte vorliegt. Denn Zitat manpage mblen:

If the n bytes starting at s do not contain a complete multibyte character, mblen() returns -1.

Dann sieht das quasi so aus:

Code: Alles auswählen

		/* loop to begin of character */
		while ((r = mblen(s1, MB_LEN_MAX)) < 0) { s1--; };
		memcpy(u1, s1, r);
		u1[r] = '\0';
		/* loop to begin of character */
		while ((r = mblen(s2, MB_LEN_MAX)) < 0) { s2--; };
		memcpy(u2, s2, r);
		u2[r] = '\0';

(Noch ohne die vielleicht nötige Fehlerbehandlung.)

[RobertDebiannutzer]

So, einmal der "alternative approach" (loop bis Zahl, schauen, ob alles bis dahin gleich ist, danach Zahlen verarbeiten, schauen, ob sich da eine differenz ergibt, ansonsten weiter): 40534
und einmal mein doch wieder präferierter Ansatz (loop bis sich eine differenz ergibt, dann handeln): 40533.
(Beide Funktionen sind mit einer kleinen main() und zwei Test-Funktionen. Kompiliert wurde beides auf Debian 9 mit "gcc -pedantic -Wall -Wextra".)
Den eingebauten Performance-Test kann man mit dem bash-Builtin "time" (oder dem separaten Programm "time") verwenden.
Ergebnisse:
für den "alternative approach": ca. 6.0 Sekunden
für meinen präferierten Ansatz: ca. 1.7 Sekungen.

Fehlerhandling sieht so aus, dass die Funktion 0 zurückgeben soll, wenn es einen Fehler gab.

Eine Schwachstelle könnte mblen sein, wenn das Encoding fehlerhaft ist oder irgendetwas anderes (?) ist und mblen ständig -1 herausgibt. Ich habe versucht, unter Berücksichtigung dessen Buffer Overflows o.ä. zu verhindern.

Was meint ihr?

[Meillo]

Den eingebauten Performance-Test kann man mit dem bash-Builtin "time" (oder dem separaten Programm "time") verwenden.
Ergebnisse:
für den "alternative approach": ca. 6.0 Sekunden
für meinen präferierten Ansatz: ca. 1.7 Sekungen.

Da ist ca. Faktor 4. (Also aus Zeitperformance-Optimierungs-Sicht gering.)

Du testest 8 Eintraege (manche einfach, manche komplex) 1 Mio Mal.

Wenn man ein grosses Verzeichnis mit 1000 Eintraegen nimmt, dann waeren das in einem realen Anwendungsfall im Filemanager rein rechnerisch 0,0008s vs. 0,0002s -- also voellig egal.

Was sagt dieser Performance-Test also aus? Nichts. (Oft sind am Ende irgendwelche Overheads oder IO-Operationen dann eh nochmal groesser als die ganze Berechnung selbst.) Du stellst die Performance-Messung hier in den Raum, wie wenn sie eine Aussagekraft haette.

Ich bin nicht der erste, der empfiehlt, auf die Zeit- und Speicher-Performance zuletzt zu schauen. Achte zuerst auf die Programmier- und Debug-Performance, die ist viel wichtiger. Erst wenn's am Ende zu langsam sein sollte, dann nimm einen Profiler und schau, *was* zu langsam ist, bevor du deinen Code unleserlich machst.


Btw: Auch wenn du nun scheinbar zwei verschiedene Verfahren verwendest, so ist der Code doch beidesmal gleich unleserlich. Meine Empfehlung waere, nochmal ganz frisch und zwar Top-Down anzufangen, also etwa in der Art:
1. Leere function mycmp()
2. Darin enthalten: While-Schleife die den String in Chunks mit nur Ziffern oder nur Nicht-Ziffern zerlegt (Das Zerlegen evtl. in separater Funktion)
3. Fuer jeden Chunk wird die passende Hilfscomparefunktion aufgerufen (separate Funktion
4. ...

Und schon hast du dein Problem zerteilt, hast mehrere kleine Funktionen, die jeweils nur eine kleine Teilaufgabe machen. Damit wird das ganze lesbarer werden.

[RobertDebiannutzer]

Danke für die klare Rückmeldung!

Ich wollte die neue Funktion gleich mitbringen, aber ich habe noch Probleme mit dem Vergleich meiner beiden Zahlen-Sequenzen. Wo kann ich eigentlich herausfinden, ob Zahlen immer Einzelbytes sind bzw. ob man die dann auch ganz einfach mit ">" "<" vergleichen kann?

Was ich noch gerne fragen wollte: Was genau macht Code wie den in meinen obigen Funktionen eigentlich unleserlich? Ist das dahinterstehende Konzept nicht klar genug oder schlecht, oder ist der Code von der Syntax her nicht strukturiert genug, oder was genau ist es?

[eggy]

a) Die Länge der Funktionen. Siehe weiter oben im Thread
b) Unnötig kompliziertes if/elseif

Code: Alles auswählen

 if (argc == 3) {
                printf("%d\n", mycompare(argv[1], argv[2]));
                exit(EXIT_SUCCESS);
        } else if (argc == 2 && strcmp(argv[1], "--debug") == 0) {
              [...]                   
                exit(EXIT_SUCCESS);
        } else if (argc == 2 && strcmp(argv[1], "--perftest") == 0) {
              [...]

lesbarer wäre:

Code: Alles auswählen

    if (argc == 3) {
                printf("%d\n", mycompare(argv[1], argv[2]));
                exit(EXIT_SUCCESS);
        }
        
    if (argc == 2 && strcmp(argv[1], "--debug") == 0) {
              [...]                   
                exit(EXIT_SUCCESS);
    }
    
    if (argc == 2 && strcmp(argv[1], "--perftest") == 0) {
              [...]

Jede der Teilfunktionen, die mit exit oder return endet würde ich alleine stehen haben. In diesen Fällen ist es semantisch äquivalent die Funktionen auseinanderzuziehen. Erhöht die Lesbarkeit gleich ungemein.

c) Es fehlen Headerfiles. Sie ermöglichen ein schnelles Überfliegen "was ist in der Datei, welche Funktionen gibt es", man kann sich gedanklich auf den Code vorbereiten, hat praktisch eine "Karte", wo es langgehen wird, wenn man den restlichen Code liest.

Edit: Typo

[ViNic]

Also ich würde die Benennung der Variablen bemängeln, die Einrückungen im Code und das Code anscheinend doppelt vorhanden ist.

Ist aber nur meine Meinung.

[Meillo]

Ich wollte die neue Funktion gleich mitbringen, aber ich habe noch Probleme mit dem Vergleich meiner beiden Zahlen-Sequenzen. Wo kann ich eigentlich herausfinden, ob Zahlen immer Einzelbytes sind bzw. ob man die dann auch ganz einfach mit ">" "<" vergleichen kann?

Du koenntest auch einfach mit strtol(3) vergleichen, dann bekommst du auch gleich das Suchen des Zahlenendes geschenkt (bloss wuerde das sowas wie ``1234e-56'' als eine Zahl interpraetieren ...). Die Ziffern sind alle Teil von US-ASCII, insofern kannst du die auch direkt vergleichen, aber ...

Was ich noch gerne fragen wollte: Was genau macht Code wie den in meinen obigen Funktionen eigentlich unleserlich? Ist das dahinterstehende Konzept nicht klar genug oder schlecht, oder ist der Code von der Syntax her nicht strukturiert genug, oder was genau ist es?

... genau das macht Code unleserlich, Low-Level-Code, der Bytes vergleicht. Der Grund ist, dass er nur schwer erkennen laesst, was *inhaltlich* gemacht wird. Wenn du also nicht strtol(3) verwendest, dann schreibe dir selber eine strnumcmp() oder so, die zwei Strings entgegen nimmt und die in ihnen enthaltenen Zahlen vergleicht.

Code wird beispielsweise lesbarer, wenn jede Funktion nur auf einem Abstraktionslevel arbeitet. Die eine Funtion arbeitet auf Bytes, die darueber auf Chunks von Strings, die darueber auf ganzen Strings. Sowas hilft.

Ansonsten sei auf den Telefontest verwiesen. (Siehe dazu auch: viewtopic.php?f=34&t=165425 )

Wenn du ein Buch lesen willst, dann ist meine beste Empfehlung: ``The Practice of Programming'' von Kernighan und Pike.

[RobertDebiannutzer]

Danke für eure Anregungen!

Du koenntest auch einfach mit strtol(3) vergleichen[…]

Dann kann die Zahlenfolge aber nicht beliebig lang sein, oder?

Die Ziffern sind alle Teil von US-ASCII, insofern kannst du die auch direkt vergleichen […]

Also auch bei irgendeinem anderen Encoding und sogar in der Form (a == '0') (nach geeignetem setlocale() natürlich)? Wenn ja, ist das toll, so habe ich die neue Funktion auch einfach mal verfasst. Allerdings habe ich dann das mit den Encodings noch nicht ganz verstanden...
Vielen Dank übrigens für die Buch-Empfehlung, hört sich sehr interessant an!

c) Es fehlen Headerfiles. Sie ermöglichen ein schnelles Überfliegen "was ist in der Datei, welche Funktionen gibt es", man kann sich gedanklich auf den Code vorbereiten, hat praktisch eine "Karte", wo es langgehen wird, wenn man den restlichen Code liest.

Ja, bei einem "ganzen" Programm mache ich auch immer eine schöne Header-Datei, in der ich auch die globalen Variablen kurz erkläre (habe ich mir von Linus Torvalds uemacs abgeschaut...). Aber ich habe jetzt mal alle Funktionen ganz oben separat deklariert.

Ich habe versucht, alle eure Kommentare zu berücksichtigen und den von @meillo vorgeschlagenen Ablauf so gut ich konnte einzuhalten:
40535
Zeile 93 ist vielleicht noch etwas kompliziert...
Was dort passiert:
--------------
wenn len1 == 0 und i == 0, dann ist s1 größer, deshalb len2-len1
wenn len1 == 0 und i > 0, dann ist s2 größer, deshalb len1-len2
wenn len2 == 0 und i == 0, dann ist s2 größer, deshalb len2-len1
wenn len2 == 0 und i > 0, dann ist s1 größer, deshalb len1-len2
-------------
Vielleicht sollte man sowas im Code doch weiter auseinanderpflücken? Allerdings sieht es so als ein if wenn man es mal durchschaut hat übersichtlicher aus...

[eggy]

Code: Alles auswählen

int
main(int argc, char *argv[])
{

Der Typ des Rückgabewerts gehört in C und vielen anderen Sprachen mit zur Signatur. Daher sollte er mit dem Rest der Signatur auf einer Zeile sein.

Code: Alles auswählen

int main(int argc, char *argv[]) {

Dass Du die Klammern auf der nächsten Zeile setzt, ist hingegen reine Geschmackssache. Ich finde öffnende Klammer auf neuen Zeilen absolut fürchterlich, für mich gehören die ans Ende der Zeile. Macht es aus meiner Sicht dann auch wieder nen ganzes Stück schneller lesbar. Aber wie gesagt, der Teil ist Geschmackssache.

[Meillo]

Du koenntest auch einfach mit strtol(3) vergleichen[…]

Dann kann die Zahlenfolge aber nicht beliebig lang sein, oder?

Korrekt erfasst. Daran habe ich nicht gedacht.

Die Ziffern sind alle Teil von US-ASCII, insofern kannst du die auch direkt vergleichen […]

Also auch bei irgendeinem anderen Encoding und sogar in der Form (a == '0') (nach geeignetem setlocale() natürlich)?

AFAIK sind in jedem bekannten Locale die Ziffern 0-9 aufsteigend direkt hintereinander. Du kannst zwei Ziffern also anhand ihrer Character-Values vergleichen und bekommst die nummerisch korrekten Ergebnisse.

Bloss mit sowas wie UTF-16 kenne ich mich nicht aus.

[Meillo]

Code: Alles auswählen

int
main(int argc, char *argv[])
{

Der Typ des Rückgabewerts gehört in C und vielen anderen Sprachen mit zur Signatur. Daher sollte er mit dem Rest der Signatur auf einer Zeile sein.

Code: Alles auswählen

int main(int argc, char *argv[]) {

Dass Du die Klammern auf der nächsten Zeile setzt, ist hingegen reine Geschmackssache. Ich finde öffnende Klammer auf neuen Zeilen absolut fürchterlich, für mich gehören die ans Ende der Zeile. Macht es aus meiner Sicht dann auch wieder nen ganzes Stück schneller lesbar. Aber wie gesagt, der Teil ist Geschmackssache.

Ersteres ist aber ein durchaus verbreiteter Stil in C.

K&R schreiben die oeffnende geschweifte Klammer bei Funktionen (nur da!) auch auch in eine neue Zeile. Der vi beruecksichtigt das auch, denn da kann man mit [[ und ]] dann von Funktion zu Funktion springen.

Historisch gesehen gab es in Pre-ANSI-C keine Rueckgabetypangaben und die Argumenttypen wurden *zwischen* die Funktionssignatur und die oeffnende geschweifte Klammer geschrieben. Darum ist die oeffnende geschweifte Klammer in einer extra Zeile.

Den Rueckgabetyp in eine extra Zeile zu schreiben hat den schoenen Vorteil, dass man dann mit der RegExp /^foo(/ direkt zur Definition der Funktion foo springen kann. K&R machen das so zwar nicht, ich mache es aber gerne so. Ausserdem ist es hilfreich, wenn man komplexe Typen zurueckliefert und viele Argumente mit komplexen Typen hat, weil man sich dann oft Umbrueche auf 80 Columns spart. (Und man muss den Funtionsnamen nicht suchen, wenn man ohne Syntax-Highlighting arbeitet.)

Wie du schreibst, ist manches Geschmackssache. Fuer manches gibt es Begruendungen die im einen oder anderen Fall relevant sind. Wie man es auch macht, man sollte begruenden koennen, warum man es so macht und nicht anders. (Eine Begruendung waere, dass die Programmiercommunity in der man sich bewegt es so macht und man sich ihr anpasst.)

[tobo]

Der Typ des Rückgabewerts gehört in C und vielen anderen Sprachen mit zur Signatur. Daher sollte er mit dem Rest der Signatur auf einer Zeile sein.

Das ist genauso Geschmacksache. Zwei z.B., die das anders sehen:
https://www.gnu.org/prep/standards/standards.html
https://suckless.org/coding_style/

PS: Diese Anzeige, dass da inzwischen ein weiterer Beitrag war, scheint aber auch nicht immer zu funktionieren!?

[novalix]

(sorry für OT)

PS: Diese Anzeige, dass da inzwischen ein weiterer Beitrag war, scheint aber auch nicht immer zu funktionieren!?

Das scheint immer dann nicht zu funktionieren, wenn man den "Vorschau"-Modus benutzt hat.

[RobertDebiannutzer]

AFAIK sind in jedem bekannten Locale die Ziffern 0-9 aufsteigend direkt hintereinander. Du kannst zwei Ziffern also anhand ihrer Character-Values vergleichen und bekommst die nummerisch korrekten Ergebnisse.

Ok, aber sind das auch immer Singlebytes? Sowas muss doch irgendwo stehen. Für Unicode habe ich nun das hier gefunden: https://en.wikipedia.org/wiki/Compariso ... #In_detail . Demnach müsste ich den Loop über die Zahlen doch umschreiben, da doch nicht eine Zahl = ein Byte gilt.

Zum Style:
Ich schreibe bei Funktionen immer Rückgabewert und geschweifte Klammer in eine separate Zeile, da ich es viel übersichtlicher finde. (Ich nutze auch kein syntax highlighting, außer für Kommentare). Gerade, wenn eine Funktion viele Argumente entgegennimmt, ist die Klammer auf der nächsten Zeile sehr gut, da dann Freiraum ist zwischen der Liste der Argumente und den Deklarationen der Variablen. Außerdem möchte ich immer gerne unter 81 Columns bleiben, da das angenehmer ist, wenn man zwei Dateien nebeneinander bearbeitet (tiling window manager / split screen in vim).

@meillo: Als ich gestern nach einem "Blick ins Buch" von "The Practice of Programming" suchte, habe ich u.a. das hier gefunden: https://www.oreilly.com/library/view/th ... /ch01.html . Das Zitat kenne ich sogar, denn "The Elements of Style" von William Strunk (https://en.wikipedia.org/wiki/The_Elements_of_Style) habe ich sogar als Buch bzw. eher Heft. (Eine hübsche neuere Ausgabe, die ich mal in einer Buchhandlung gefunden habe, da ich dort immer auch nach versteckten kleinen Büchlein schaue. Die Buchhändlerin wusste gar nicht, dass sie das hatte, und hat den Preis nicht mehr im Computer gefunden, deshalb habe ich es sogar geschenkt bekommen. )

[Meillo]

AFAIK sind in jedem bekannten Locale die Ziffern 0-9 aufsteigend direkt hintereinander. Du kannst zwei Ziffern also anhand ihrer Character-Values vergleichen und bekommst die nummerisch korrekten Ergebnisse.

Ok, aber sind das auch immer Singlebytes? Sowas muss doch irgendwo stehen. Für Unicode habe ich nun das hier gefunden: https://en.wikipedia.org/wiki/Compariso ... #In_detail . Demnach müsste ich den Loop über die Zahlen doch umschreiben, da doch nicht eine Zahl = ein Byte gilt.

In UTF-16 ist es natuerlich kein Single-Byte, weil dort alle Zeichen zwei Bytes haben. (Aber mit solchen Sackgassentechnologien beschaeftige ich mich nicht darum kann ich dazu nichts sagen.)

@meillo: Als ich gestern nach einem "Blick ins Buch" von "The Practice of Programming" suchte, habe ich u.a. das hier gefunden: https://www.oreilly.com/library/view/th ... /ch01.html . Das Zitat kenne ich sogar, denn "The Elements of Style" von William Strunk (https://en.wikipedia.org/wiki/The_Elements_of_Style)

``The Elements of Style'' wird in mehreren der Computerbuecher von den Autoren um Kernighan erwaehnt. Die Denkweisen passen auch gut zusammen (``Omit needless words!'' ). Sozusagen der Vorlaeufer von ``The Practice of Programming'' (1999) ist ``The Elements of Programming Style'' (1974) von Kernighan und Plauger. Das ist nicht nur vom Titel angelehnt. Allerdings kommt das noch aus der Fortran-Zeit. Man braucht schon ein bisschen historischen Background, wenn man das mit Vergnuegen lesen will. Das Buch von 1999 ist sozusagen die moderne(re) Verarbeitung des gleichen Themas.