Einrücken mit Leerzeichen - wo ist das Problem?

Sone

Dann beschäftigt man sich nur noch damit, wo man jetzt Tabs und wo Spaces setzt.

Nein, wieso? Es ist doch ganz logisch, wo man Tabs und wo man Spaces benutzt. Deinen Code könnte ein Schimpanse formatieren, da wette ich drum. Ich habe feste Regeln für die kleinsten Dinge, die ich auch einhalte, schon wie "Es kommt ein Leerzeichen zwischen die schließende Klammer und den Doppelpunkt bei einer Initialisierungsliste im Konstruktor".

ist schnell mal unabsichtlich eingetippt

Das wäre merkwürdig. Wieso sollte ich aus Versehen vier Spaces statt einem Tab (oder vice versa) eintippen?

Sone schrieb:

Das wäre merkwürdig. Wieso sollte ich aus Versehen vier Spaces statt einem Tab (oder vice versa) eintippen?

Das ist nicht nötig, die meisten Text-Editoren bieten Funktionen, um Tabs beim Speichern standardmäßig in x Leerzeichen (meist 1 Tab = 4 Leerzeichen) umzuwandeln.

Ohne mich genauer informiert zu haben, vermute ich, dass der vim das unterstützt.

Ich lag richtig:
http://vim.wikia.com/wiki/Converting_tabs_to_spaces

Sone

die meisten Text-Editoren bieten Funktionen, um Tabs beim Speichern standardmäßig in x Leerzeichen (meist 1 Tab = 4 Leerzeichen) umzuwandeln.

Klar, aber die Option verändert sich ja nicht zufällig mitten beim Ausrichten.

Kellerautomat

Ich benutze Tabbreite 8. Wer spaces benutzt hat seinen Code meist mit 4 Zeichen eingerueckt und ich muesste diesen durch ein Konvertierungstool jagen, daher sind Spaces Bullshit.

Shade Of Mine

Kellerautomat schrieb:

Ich benutze Tabbreite 8. Wer spaces benutzt hat seinen Code meist mit 4 Zeichen eingerueckt und ich muesste diesen durch ein Konvertierungstool jagen, daher sind Spaces Bullshit.

Warum nimmst du 8 Zeichen pro Tab?

Wir haben letztens in der Firma mal darueber diskutiert aber keiner hatte ein Argument warum man etwas anderes als 4 nehmen sollte.

PS:
da es unendlich viele Argumente pro Tabs und pro Leerzeichen gibt, denke ich dass das einzig sinnvolle ist die Tabbreite im Codingstyle zu definieren und dann zu definieren ob Tabs oder Leerzeichen verwendet werden sollen.

Denn wenn mit Unterschiedlicher Tabbreite gearbeitet wird, wird es zu notwendigen reformatierungs commits kommen. Und wenn das der Fall ist, dann hat man den falschen Style gewaehlt da man ploetzlich Arbeit mit etwas hat, dass keine Arbeit produzieren darf.

Kellerautomat

Shade Of Mine schrieb:

Kellerautomat schrieb:

Ich benutze Tabbreite 8. Wer spaces benutzt hat seinen Code meist mit 4 Zeichen eingerueckt und ich muesste diesen durch ein Konvertierungstool jagen, daher sind Spaces Bullshit.

Warum nimmst du 8 Zeichen pro Tab?

Weils mir am besten gefaellt.

hustbaer

Also ich hab' noch kaum Code gesehen der mit Tab=4 schlecht aussieht.
Code der auf endlich breiten Bildschrimen mit Tab=8 schlecht aussieht gibt's dagegen recht viel.
Tab=8 "hindert" einen nur daran bestimmte Dinge einzurücken -- wie z.B. namespaces.

Ansonsten...

Shade Of Mine schrieb:

PS:
da es unendlich viele Argumente pro Tabs und pro Leerzeichen gibt, denke ich dass das einzig sinnvolle ist die Tabbreite im Codingstyle zu definieren und dann zu definieren ob Tabs oder Leerzeichen verwendet werden sollen.

full ack

Kellerautomat

Eine Tabbreite hat in nem Codingstyle nichts verloren. Das ist eine persoenliche Einstellung des Programmiers.

Namespaces mache ich so:

namespace foo { namespace bar { namespace baz {
        blubb;
}}}

tntnet

Ihr habt ja Probleme. Die Diskussion lässt sich endlos führen und es wurden bereits Mannjahre dafür investiert, zu einem Ergebnis zu kommen.

Ich persönlich bevorzuge immer Spaces aber noch wichtiger ist es, einen einheitlichen Standard im Projekt zu haben. Wenn wir uns im Projekt auf Tabs einigen, dann sind es halt tabs.

Ein Vorteil von Spaces zur Einrückung wurde glaube ich noch nicht erwähnt: Es lässt sich leichter kontrollieren, ob das eingehalten wurde. Ein grep auf Tabs über alle Sourcen ist schnell gemacht. Ein grep auf Spaces ist natürlich auch schnell gemacht, wird aber viele false positives liefern. Also eigentlich wird es wohl fast den kompletten Sourcecode liefern, da in praktisch jeder Zeile ein Space vorkommt.

Das schlimmste sind Tabs und Spaces gemischt in Sourcecode. Das kommt in der Praxis bei alten Sourcen leider oft vor. Da muss man schon manchmal durch ausprobieren feststellen, mit welcher Tabeinstellung der Code überhaupt lesbar ist. Bei uns kommt viel Sourcecode vor, der nur bei Tabstop=5 lesbar ist. Oder aber eine Datei ist an einer Stelle mit Tabstop=8 gut lesbar, an einer anderen Stelle mit Tabstop=5. So sieht die Praxis aus und dabei lernt man Toleranz. Man muss es einfach akzeptieren, wenn man seine Zeit nicht mit Diskussionen über Tabs und Spaces verschwenden kann.

king- schrieb:

Das beste ist Tabs UND Spaces. Tabs zum Einrücken und Spaces zum Ausrichten.

erfordert aber disziplin die die meisten progger nicht haben. leider

hustbaer

tntnet schrieb:

Bei uns kommt viel Sourcecode vor, der nur bei Tabstop=5 lesbar ist. Oder aber eine Datei ist an einer Stelle mit Tabstop=8 gut lesbar, an einer anderen Stelle mit Tabstop=5. So sieht die Praxis aus und dabei lernt man Toleranz. Man muss es einfach akzeptieren, wenn man seine Zeit nicht mit Diskussionen über Tabs und Spaces verschwenden kann.

Toleranz zu lernen ist aber die falsche Lösung. Tab-Breite + Tabs vs. Spaces vorzuschreiben ist IMO die bessere Lösung. Dann verschwendet man nämlich keine Gehirnzellen mehr darauf so "unwichtige" (aber dennoch irritierende) Unterschiede auszublenden.

Ich kann mir wirklich kaum eine Situation vorstellen wo das (=Tab-Breite etc. vorschreiben) nicht möglich wäre. Viele, gerade grosse, Open-Source Projekte haben solche Vorschriften. Dort funktioniert es auch. Wieso sollte es dann nicht auch in Firmen etc. funktionieren?

es funktioniert in Firmen nicht da dort alles schnell gehen muss, da bleibt keine zeit für solche unwichtigkeiten

Bashar

tntnet schrieb:

Ein grep auf Spaces ist natürlich auch schnell gemacht, wird aber viele false positives liefern. Also eigentlich wird es wohl fast den kompletten Sourcecode liefern, da in praktisch jeder Zeile ein Space vorkommt.

Mir scheint, du suchst das Regex-Pattern ^ für "Anfang der Zeile".

hustbaer

x schrieb:

es funktioniert in Firmen nicht da dort alles schnell gehen muss, da bleibt keine zeit für solche unwichtigkeiten

Blödsinn

Hier muss man einfach als Chef hart durchgreifen und das Umwandeln von möglichen Tabs zu Leerzeichen beim Speichern vorschreiben.
Bei guten IDEs kann man dann auch gleich festlegen, zu wievielen Leerzeichen ein Tab beim Speichern umgewandelt werden soll.

Wie der Programmierer seinen Tab dann für die Darstellung einstellt, kann dann am Ende egal sein.

B4ndit

x schrieb:

es funktioniert in Firmen nicht da dort alles schnell gehen muss, da bleibt keine zeit für solche unwichtigkeiten

Dann bist du in den falschen Firmen gewesen. Ich hatte immer Zeit für ein übersichliches Layout, zu mal das Eintippen von Code nur ein Bruchteil der Zeit bei mir ausmacht. Der Löwenanteil ist Planen, Recherchieren, Testen, Fehlersuche. Das eigentliche Code in die Tastatur hacken ist vom Zeitaufwand total unbedeutend. Da tippt jede Sekretären hundert mal mehr.

Aber vielleicht gibt es auch die Hacker aus den Filmen wirklich, die nur nonstop auf der Tastatur ihren Code runter hacken. Ich kann das jedenfalls nicht. Es sind vielleicht 10% meiner Zeit, die ich wirklich mit dem reinen Sourcecode zu tun habe.

8 Zeichen als Tabbreite soll wohl dafür gut sein, damit man auch noch mit müden Augen die Struktur erkennt. Ich code aber selten müde. Da legen ich mich lieber hin und mache dann frisch weiter. Genauso code ich ungern abends oder gar Nachts, bin eher der Frühaufsteher und kann ab 6:00 Uhr am besten Probleme lösen.

Club-Mate hasse ich übrigens auch, das Zeug schmeckt einfach zum k....

knivil

@B4ndit: Was willst du damit sagen?

Sone

once schrieb:

erfordert aber disziplin die die meisten progger nicht haben. leider

Wer nicht genug Disziplin besitzt seinen Code richtig aufzuräumen*, der hat auch zu wenig um Fehlerfreie und saubere Programme zu schreiben.

Namespaces mache ich so:

Übernehme ich mal, das sieht ja lecker aus.
Auch wenig bisher leider nicht so tief verschachtelte Namensräume hatte...

Der Löwenanteil ist Planen, Recherchieren, Testen, Fehlersuche. Das eigentliche Code in die Tastatur hacken ist vom Zeitaufwand total unbedeutend.

Interessant. Also wieder ein Beweis: Firmen ist der Code egal, das Ergebnis zählt?

* Was heißt hier schon richtig. Wir reden hier von Tabs und Spaces...

knivil

und ich so, namespaces warden nicht eingerueck:

namespace foo {
namespace bar {

class fun
{
...

};

}