An alle Devs mit cvs-Schreibrechten

[Günther]

Bin ich eigentlich der Einzige, dem es stört, daß es hier noch nicht mal einen Editor-Standard gibt (von Coding Standards im Allgemeinen möchte ich erst gar nicht anfangen ) ?

Ehrlich gesagt geht es mir langsam auf die Nüsse ständig das Textformat zu studieren, bevor ich Änderungen machen kann. Mal werden Tabs mal spaces, mal UTF-8, mal ISO sonstwas, mal UNIX, mal Windows linefeed verwendet.

Ich habe mich jetzt schon mehrmals mit verschwunden Umlauten rumplagen müssen und unnötig Zeit verloren.

Bisher verwende ich immer spaces und UTF-8. Mir ist es ja schnurzpipegal was wir verwenden, aber können wir uns nicht mal auf etwas Einheitliches einigen? Dann könnte man nach und nach die Sourcen umwandeln (z.B. mit proton).

Ich benutzte zumeist eclipse auf linux und windows basis, und das erkennt das Textformat nicht zuverlässig.

(Oder bin ich nur zu blöd, weil nicht die richtigen tools und trick kenne?)

Günther

[yjogol]

Bin ich eigentlich der Einzige, dem es stört, daß es hier noch nicht mal einen Editor-Standard gibt (von Coding Standards im Allgemeinen möchte ich erst gar nicht anfangen ) ?

Ehrlich gesagt geht es mir langsam auf die Nüsse ständig das Textformat zu studieren, bevor ich Änderungen machen kann. Mal werden Tabs mal spaces, mal UTF-8, mal ISO sonstwas, mal UNIX, mal Windows linefeed verwendet.

Ich habe mich jetzt schon mehrmals mit verschwunden Umlauten rumplagen müssen und unnötig Zeit verloren.

Bisher verwende ich immer spaces und UTF-8. Mir ist es ja schnurzpipegal was wir verwenden, aber können wir uns nicht mal auf etwas Einheitliches einigen? Dann könnte man nach und nach die Sourcen umwandeln (z.B. mit proton).

Ich benutzte zumeist eclipse auf linux und windows basis, und das erkennt das Textformat nicht zuverlässig.

(Oder bin ich nur zu blöd, weil nicht die richtigen tools und trick kenne?)

Günther

Jau, habe mich auch schon gewundert.
Da die HTML-Seiten (also Quellcode) direkt in das Image kommen, habe ich einen Vorschlag:

UTF-8, zum Einrücken nur Tabs verwenden 8 Spalten!
(Spaces statt Tabs würden die Webseiten um ca. 8-10% größer machen.)

Ich verwende auch eclipse und Kate unter Linux u. Windows. (in alten UNIX und SunOS Zeiten waren es immer 8 Spalten)

Gruß
yjogol

[saruman]

UTF-8 saugt in meinen Augen - da ich aber bisher kaum was eingecheckt habe und auch sonst nicht gerade durch aktives Entwickeln aufgefallen bin ist es mir eigentlich egal. Und TABs statt Spaces find ich irgendwie sinnvoller.

[Günther]

Mit Tabs statt Spaces kann ich leben, obwohl es beim kombinierten Gebrauch von Leerzeichen schnell zu lustige Formartierungen mit anderen Tools kommen kann, weil TAB eigentlich ein Makro und kein Zeichen ist. Deshalb kenne ich es bei der SW-Entwicklung auch nur mit Spaces.

TAB-8 finde ich dagegen nicht nur ungewöhnlich (auch wenn es aus 'alter' Zeit kommt) sondern auch unpraktisch, weil die Zeilen dann schnell nach rechts wandern. Wäre da eher für TAB-4 (oder Space-4 ), ist soweit ich weiß bei Tools auch meist als Standard eingestellt.

UTF-8 würde mir auch besser gefallen, schon alleine deshalb, weil es beiden Konfig-Files der dbox 'Standard' ist. Probleme gibt es nur mit Windows-Tools, die oft nur ISO können.

Die anscheinend häufigste Formatierung im cvs scheint allerdings ISO und TAB-4 zu sein. Das sollte man auch nicht ausser acht lassen...

Wie gesagt, zu dem Thema gibt es viele (richtige) Möglichkeiten, nur dieses derzeitge Durcheinander finde ich halt etwas seltsam (und zeitraubend).

Aber wirklich viele scheint das Thema eh nicht zu interessieren

Günther

[Houdini]

die meisten Files sind mit Tab-8 geschrieben,
Umlaute haben in sourcecode eigentlicht auch nix zu suchen, deswegen ist hier ISO-Kodierung auch kein Problem.
Anders sieht es in bei den locales aus...

[Tommy]

Leider sind die alten Dev's nicht mehr da (interessiert) und es sind nicht viel Neue nachgerückt. Und nicht zu vergessen wurden auch leider einige sehr Fähige von Halbwissenden vergrault. (und Ihre Ideen haben sich zum Glück trotzdem durchgesetzt)
Wenn ich mehr Zeit hätte, würde ich mich auch mit cpp auseinandersetzen. Leider habe ich damals auf VB gesetzt und muß @work meine tools jetzt auf .net umsetzen. Zuhause warten Frau und 15 Monate alter Sohn. Da bleibt nicht viel Zeit......

[Günther]

Umlaute haben in sourcecode eigentlicht auch nix zu suchen, deswegen ist hier ISO-Kodierung auch kein Problem.

Und Sonderzeichen ... siehe z.B. eventlist.cpp (EDIT: ich meinte channellist.cpp)

Also TAB-8 mit ISO ohne Sonderzeichen (um notfalls auch mit UTF-8 arbeiten zu können) ?

Günther

[robspr1]

IMO finde ich Tabs in c/cpp Sourcen nicht richtig, in HTML code, aus dem Grund den yjogol genannt hat, hingegen schon.

Zwar würde eine Einignung auf Tab==8Spaces ein einheitliches Bild ergeben, ich finde c Sourcen die dann sehr stark nach rechts einrücken aber unleserlich, da man ja genaugenommen nach 78 Zeichen eine neue Zeile beginnen sollte wird das dann noch schlimmer.

(Spaces statt Tabs, max 78 Zeichen pro Zeile wird übrigens derzeit als Standard beim Informatik-Studium in Graz gelehrt, hab ich zwar schon lange hinter mir, ich hab mich aber erkundigt)

Zu den Umlauten:
ISO-8859-1 reicht für unsere Anwendungen (deutsche bzw. englische GUI), UTF8 macht einiges komplizierter (ein Umlaut besteht dann aus 2 Zeichen, da die Ausgabe am Bildschirm aber mit den ISO Codes zurecht kommt, muss man erst recht wieder zurückkonvertieren)

[racker]

IMO finde ich Tabs in c/cpp Sourcen nicht richtig, in HTML code, aus dem Grund den yjogol genannt hat, hingegen schon.

Zwar würde eine Einignung auf Tab==8Spaces ein einheitliches Bild ergeben, ich finde c Sourcen die dann sehr stark nach rechts einrücken aber unleserlich, da man ja genaugenommen nach 78 Zeichen eine neue Zeile beginnen sollte wird das dann noch schlimmer.

...

Die Meinung von Linus dazu:

Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

Vlt. wäre folgendes eine Diskussionsgrundlage:
http://www.linuxfromscratch.org/alfs/vi ... style.html

[robspr1]

Die Meinung von Linus dazu:
Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

Dann sollte man also auch viele Kernel-Sourcen wegwerfen , wobei, die Verwendung von goto's IMO noch schlimmer ist also einfach noch eine Ebene einzuführen.

Vlt. wäre folgendes eine Diskussionsgrundlage:
http://www.linuxfromscratch.org/alfs/vi ... style.html

Da würde ich besser dies als Diskussionsgrundlage vorschlagen:
http://www.possibility.com/Cpp/CppCodingStandard.html

[racker]

wobei, die Verwendung von goto's IMO noch schlimmer ist also einfach noch eine Ebene einzuführen.

Ich denke hier geht es um coding style (format) und nicht um Programmiertechniken.
Der Kernel hat nun mal andere Anforderungen als Code im Userspace.

Auf der von mir verlinkten Seite wird beschrieben, wie man äußerst kompakt
und trotzdem übersichtlich! coden kann.
Mal ein negatives Beispiel aus der neutrino.cpp, dass mir immer wieder
die Tränen in die Augen treibt:

Code: Alles auswählen

void CNeutrinoApp::InitMainMenu(CMenuWidget &mainMenu,
								CMenuWidget &mainSettings,
								CMenuWidget &audioSettings,
								CMenuWidget &parentallockSettings,
								CMenuWidget &networkSettings,
								CMenuWidget &recordingSettings,
								CMenuWidget &colorSettings,
								CMenuWidget &lcdSettings,
								CMenuWidget &keySettings,
								CMenuWidget &videoSettings,
								CMenuWidget &languageSettings,
								CMenuWidget &miscSettings,
								CMenuWidget &driverSettings,
								CMenuWidget &service,
								CMenuWidget &fontSettings,
								CMenuWidget &audiopl_picSettings,
								CMenuWidget &streamingSettings,
								CMenuWidget &moviePlayer)
{

Wer soetwas braucht, um nichts doppelt zu schreiben, sollte besser seine Arbeitssorgfalt überprüfen.

Aber das geht schon wieder zuweit. Die Frage war hier ob spaces oder tabs verwendet
werden sollen. Schon mal ein Listing mit Proportionalschrift ausgedruckt,
das mit spaces formatiert war?

[robspr1]

das mit der Proportionalschrift und Sourcecode meinst du hoffentlich nicht ernst

Indentation/Tabs/Space Policy

* Indent using 3, 4, or 8 spaces for each level.
* Do not use tabs, use spaces. Most editors can substitute spaces for tabs.
* Tabs should be fixed at 8 spaces. Don't set tabs to a different spacing, uses spaces instead.
* Indent as much as needed, but no more. There are no arbitrary rules as to the maximum indenting level. If the indenting level is more than 4 or 5 levels you may think about factoring out code.

Justification

* Tabs aren't used because 8 space indentation severely limits the number of indentation levels one can have. The argument that if this is a problem you have too many indentation levels has some force, but real code can often be three or more levels deep. Changing a tab to be less than 8 spaces is a problem because that setting is usually local. When someone prints the source tabs will be 8 characters and the code will look horrible. Same for people using other editors. Which is why we use spaces...
* When people using different tab settings the code is impossible to read or print, which is why spaces are preferable to tabs.
* Nobody can ever agree on the correct number of spaces, just be consistent. In general people have found 3 or 4 spaces per indentation level workable.
* As much as people would like to limit the maximum indentation levels it never seems to work in general. We'll trust that programmers will choose wisely how deep to nest code.

[Günther]

Was Linus meint ist sicher richtig, nur muß das nicht zwangläufig für alle Branchen/Projekte gelten. SW-Prozesse sind ein wirklich schönes und spannendes Thema, vor allem wenn die Störgrößen Kunde (Pflichtenheftänderungen), Wirtschaftlichkeit, dead-lines und Quartals-Zahlen dazukommen

Aber zurück zum Thema, ich sehe es ähnlich wie robspr1. In Tab-8 kann ich nach wie vor keinen Vorteil sehen (ausser dass das auf die alten Fernschreiber zurückgeht). In der realen SW (neutrino) -Welt mit mehr als 3 Einrückungen und mehr als 80 Zeilen pro Funktion hat das für mich nur Nachteile. Mit Tab-4 und ISO könnte ich leben.

[Houdini]

aber 95% der Neutrino SW ist nun mal mit Tab8 geschrieben...
noch schlechter als das eine oder das andere ist ein Mischmasch

[robspr1]

... wobei die neutrino.cpp mit Tab-4 formatiert ist (zumindest schaut das noch am ehesten vernünftig aus ), und, mehr als 20 Tabs in einer Zeile bei Tab-8 wären sicher nicht sehr druckerfreundlich.

Aber du hast sicher Recht, die Mischung, insbesonders Tab-8 und andere Tab-x ist das unangenehmste, denn dann muss man immer raten, wie man den jetzt den Editor einstellen soll. Deshalb würde ich selbst Spaces statt Tabs bevorzugen, dann gibt es keine Ratespiele.

Und, das unangenehmere als Tabs / Spaces (da wird ja nur der Source schwerer zu lesen) ist sicher die Verwendung unterschiedlicher Codierungen (wie Günther ja in seinem Eingangspost bemerkt hat). Da es nicht so viele Sourcen geben wird die Umlaute verwenden, wird sich da ja hoffentlich eine Lösung finden lassen (bzw. gibt es jetzt wirklich Sourcen die in UTF-8 und andere die in ISO codiert sind?)

[mws]

na gott sei dank hab ich für neutrino2 die specs selber verfasst

ist ja eine haarspalterei hier *fg*

gruss
mws

[Tommy]

neutrino2

[Günther]

na gott sei dank hab ich für neutrino2 die specs selber verfasst

Da läßt es sich ja leicht lästern

Aber zur Beruhigung, 95% sind natürlich der Maßstab und da sich sonst keiner hierzu gemeldet hat macht es auch keinen Sinn das zu ändern. Ich habe bereits beim letzten Checkin auf Tab-8 / ISO umgestellt (auch wenn ich Tab-8 greusslich finde. Ich könnte hier noch einige aktuelle Beispiele der letzten Tage posten - aber was solls ... ) .