Codestyle: Einrücken untergeordneter Abschnitte?

Michael E.

314159265358979 schrieb:

Tabs mitten im Text zerstören bei geänderter Tabbreite meist die Formatierung. Schon oft genug geärgert.

Cool, jetzt gibst du dir schon selbst Gegenargumente.

otze

314159265358979 schrieb:

@otze: Nein. Tabs mitten im Text zerstören bei geänderter Tabbreite meist die Formatierung. Schon oft genug geärgert.

Exakt das habe ich gesagt. Unixsysteme gehen den anderen Weg: anstatt Tabs im Text zu verbieten, setzen sie per konvention die Tabbreite auf 8.

314159265358979

SeppJ schrieb:

Dann hör auf hier rumzukotzen.

sry, i'm drunk! okay, eigentlich nich. aber ich mag erdbeeren! srsly!

Michael E. schrieb:

Cool, jetzt gibst du dir schon selbst Gegenargumente.

In meinen Aussagen ist kein Widerspruch. Du musst nur genau lesen.

314159265358979

otze schrieb:

Exakt das habe ich gesagt. Unixsysteme gehen den anderen Weg: anstatt Tabs im Text zu verbieten, setzen sie per konvention die Tabbreite auf 8.

Dann kapier ich deine Aussagen nicht. Mein Standpunkt: Tabs mitten im Text sind Mist. Deine Meinung dazu zusammengefasst?

hustbaer

otze schrieb:

314159265358979 schrieb:

@otze: Nein. Tabs mitten im Text zerstören bei geänderter Tabbreite meist die Formatierung. Schon oft genug geärgert.

Exakt das habe ich gesagt. Unixsysteme gehen den anderen Weg: anstatt Tabs im Text zu verbieten, setzen sie per konvention die Tabbreite auf 8.

Auch nur so lange man keinen vernünftigen Editor anwirft, wo man die Tab-Breite einstellen kann

otze

314159265358979 schrieb:

Dann kapier ich deine Aussagen nicht. Mein Standpunkt: Tabs mitten im Text sind Mist. Deine Meinung dazu zusammengefasst?

Das ist eine Konvention wie viele andere auch. Man kann sich da jetzt hinstellen und sagen: "aber meine Konvention ist besser", fällt damit aber auf die Schnauze, da die Konventionen jeweils unterschiedliche Dinge können und man leicht in Situationen kommt, wo entweder die eine oder die andere besser wäre. Das Problem ist nicht entscheidbar, da die Vergleichbarkeit fehlt.

Ich bin ein Tabber mit tabwith=4, aber mir ist das am Ende relativ Schnurz. Wenn ich Code-Konvention 2 oder 8 vorgesetzt kriege und die IDE so einstellen muss, dass mir die Tabs automatisch Leerzeichen erzeugen, ist mir das völlig egal. Alles eine Sache der Gewöhnung. Für mich als Einzelperson ist es egal, ob ich spaces oder tabs verwende. Da muss ich nur darauf achten, dass ich zu mir selbst Konsistent bin. Im Team nehme ich das, was sich als Konsens anbietet oder bereits etabliert ist.

Also zusammengefasst: Deine Meinung in ihrer Pauschalität ist Quark. Mal wieder, leider.

314159265358979

Und wo ist es besser Tabs mitten im Text zu verwenden? Es hat ausschließlich nachteile.

pyhax

Ich benutze mittlerweile selber Spaces, aber früher habe ich das mit Tabs und Spaces gemacht. Und zwar Tabs immer nur am Anfang der Zeile, und Spaces wenn man sich an Zeichen orientiert.

Bsp: (Alles was nicht Tabs sind sind Spaces :D)

class X {
private:
{TAB}int M_x;
public:
{TAB}void setX(int x)  { M_x = x; }
{TAB}int  getX() const { return x; }
}

Eisflamme

Ich finde, seldon hat das alles schön gesagt. Aufzwingen sollte man niemandem etwas und irgendwie geschieht das in diesen Diskussionen ziemlich häufig: Das ist hässlich, mach das auf keinen Fall so! Habe ich ja auch getan, gebe ich reuhaft zu.

Dennoch habt ihr mich überzeugt die Tabs in Leerzeichen-Tabs im Editor umzuwandeln. Mir geht es so ein wenig darum, dass ich bei geschriebenem OpenSource-Code mit so wenig Widerstand bzgl. des Stils rechnen kann wie möglich. Mir graut es Code zu veröffentlichen. Nicht, weil ich ihn nicht effektiv, fehlerfrei oder schlecht designed halte; sondern weil ich keine Lust habe wegen dem Stil in irgendeiner Weise abgestempelt werden. ^^

hustbaer

@Eisflamme
Ich verstehe dein Problem nicht ganz, und deinen Entscheindungsfindungsprozess auch nicht wirklich.

Ich würde einfach "meinen" Stil durchziehen, aber gut, das bin ich.

Wenn du da Bedenken hast, dann machs doch so: such dir Open-Source Projekte die folgende Bedingungen erfüllen

* Der Code-Stil sagt dir einigermassen zu
* Das Projekt geniesst allgemein halbwegs gutes Ansehen
* Das Projekt wird kaum wegen komischem Stil/unübersichtlichem Code/... kritisiert

Und dann machst du 1:1 den Stil eines dieser Projekte nach.

otze

314159265358979 schrieb:

Und wo ist es besser Tabs mitten im Text zu verwenden? Es hat ausschließlich nachteile.

Tabellen. Matrizen. Alles was irgendwie strukturierte Daten sind. Wie ich bereits dargelegt hab. Aber wir wissen ja bereits, dass du ein ziemlicher Sturkopf bist. Alles was nicht von dir kommt, kann nicht begründet sein, selbst wenn es Begründungen sind. Damit beende ich hier auch die Diskussion mit dir :).

@Eisflamme Es ist völlig egal, wie du einrückst. Wer sich dein Projekt holt und sich mit dem Code auseinandersetzt, wird noch den Formatierungsbutton seiner IDE finden. Und der ist es völlig egal, ob du Tabs oder spaces verwendest.

314159265358979

otze schrieb:

Tabellen. Matrizen. Alles was irgendwie strukturierte Daten sind.

Ne. Genau dort zerfällt alles, wenn die Tabbreite mal nicht stimmt, oder irgendwo gepasted wird und Tabs durch X Leerzeichen ersetzt werden.

Eisflamme

Aber erkennt der nicht,wenn in einem Fall tab nur einem einfachen Leerzeichen entspricht? Fall doch,gäbe es doch kein Problem.

pumuckl

Eisflamme schrieb:

Sagen wir, ich habe ein Objekt mit einem ctor mit 10 Elementen (ob das jetzt zu viel ist, sei mal dahingestellt)

Nein, es sei nicht dahingestellt. Es ist zu viel. Wenn man sich angewöhnt, den Funktionen maximal 3-4 Parameter zu geben, stellt sich die Frage nämlich garnicht, wie man Aufrufe mit 10 Parametern einrücken sollte.
Klar gibts immer wieder mal Ausnahmen, wo man nur schwer drumrum kommt.

Was dein Trainwreck angeht: Lässt sich vermeiden.

auto const& obj = SomeObject(arg1, arg2);
GetElements().push_back(obj);

//oder:
auto& elems = GetElements();
elems.emplace_back(arg1, arg2);

Eisflamme

Also ich finde,dass es in vielen umfeldern normal ist viele parameter zu haben. bei irgendeiner applikation mit personendaten z.b. kommen halt mal 10 oder mehr zusammen. aber selbst bei 4 Parametern wird die Zeile schnell lang,wenn man lange Namen hat. und manchmal braucht man leider lange Namen,wenn man präzise sein will. in dem Beispiel hast du natürlich recht...

Jockelx

314159265358979 schrieb:

cooky bevorzugt z.B. 4 Spaces, ich verwende 8.

314159265358979 schrieb:

otze schrieb:

Tabellen. Matrizen. Alles was irgendwie strukturierte Daten sind.

Ne. Genau dort zerfällt alles, wenn die Tabbreite mal nicht stimmt, oder irgendwo gepasted wird und Tabs durch X Leerzeichen ersetzt werden.

1{tab}{tab}X
12345{tab}X

ist bei cooky das passende

1.......X
12345...X

und bei dir das nicht passende
1...............X
12345...X

314159265358979

Ich sag doch Tabs mitten im Text sind Mist!

pumuckl

Eisflamme schrieb:

Also ich finde,dass es in vielen umfeldern normal ist viele parameter zu haben. bei irgendeiner applikation mit personendaten z.b. kommen halt mal 10 oder mehr zusammen.

Selten. Normalerweise werden zusammengehörige Daten gepackt, d.h. z.B. ist die Adresse in den Personendaten ein einzelnes Attribut, und nicht Straße, Hausnummer, Postleitzahl, Ort, Adresszusatz etc. einzeln.

Bashar

pumuckl schrieb:

Selten. Normalerweise werden zusammengehörige Daten gepackt, d.h. z.B. ist die Adresse in den Personendaten ein einzelnes Attribut, und nicht Straße, Hausnummer, Postleitzahl, Ort, Adresszusatz etc. einzeln.

Und wie entsteht so eine Adresse? Siehe Ursprungsposting. Ersetze SomeObject durch Address und den ganzen Rest sinngemäß.

Eisflamme

Ich kann das auch in irgendwelche Gruppen stecken, die keinen anderen Sinn haben als aus 20 Attributen 10 zu machen, wobei ich dann zwei Gruppen habe, die mit hundertprozentiger Sicherheit keinen Wiederverwendungswert haben, weil sie nur in diesem Kontext auf diese Weise zusammengestellt sind. Man hat manchmal einfach viele Felder in irgendwelchen Formularen oder an sonstigen Stellen. Das passiert in der Praxis einfach ständig imo. Da kann man sich quasi eine beliebige Geschäftsapplikation bei SAP anschauen oder auch ein Data Warehouse oder auch ein Webformular, wo ein paar Daten mehr stehen.

Oder man schaut sich eine Umfrage an. Man gruppiert da schon, aber an einer gewissen Stelle hat man eben 20 Items. Und dann sind das 20 und nicht 5 und es macht auch keinen Sinn sich künstlich Gruppen auszudenken.

Und wenn ich bei einem 3D-Modell Vertices, Indices, Normalenvektoren, Tangentenvektoren, Texturkoordinaten, Bonekoordinaten uvm. habe, dann macht das für mich imo auch keinen Sinn das großartig weiter zu gruppieren, denn schlussendlich muss man das wieder für genau ein Objekt (nämlich das Modell) an OpenGL oder DirectX übergeben. Das sind dann viele Attribute, doch sie gehören trotzdem logisch zu einer Sinneinheit. Absolut legitim imo.