Umfrage: Welchen Indent style verwendet ihr

leider doch. Ich hatte das Problem an einer solchen Stelle auch überhaupt nicht erwartet und deshalb zunächst an allen anderen Stellen gesucht, nur nicht dort Ist allerdings inzwischen 9 Jahre her.

audacia

Den Compiler will ich gar nicht kennen

DEvent schrieb:

Da muss ich entschieden widersprechen. Zum einen hat nicht jeder einen breiten Monitor, zum anderen haben moderne IDEs links und rechts Fenster (fuer Typenuebersicht, Klassenuebersicht, usw, siehe Eclipse)

Ja, aber der Platz ist dennoch groß genug um mehr als 80 Zeichen auf den Bildschirm bringen zu können.
Trotz Eclipse!

und zum dritten fuehrt die Regel der 80 Zeichen dazu, dass Verschachtelungen flach gehalten werden (also das nicht mehr als 3 oder 4 If-Verschachtelungen benutzt werden).

Und das sehe ich wiederum als Nachteil wenn man nur 3-4 If Verschachtelungen nutzt, aber mehr sinnvoll wären.

Denn gerade mit guten tief verzweigten If-Verschachtelungen kann man viel Rechenpower einsparen und wenn das ganze in einer Schleife läuft, zählt das umso mehr.

audacia schrieb:

Das sehe ich ähnlich. Nur weil man einen Breitbildmonitor hat, muß man nicht geltende und sinnvolle Standards brechen und ihn in voller Breite mit Codezeilen füllen. Oder schreibt ihr neuerdings eure Diplomarbeiten auch im Breitbildformat?
Zudem ist auch die Codedichte in diesem Falle geringer, da nur verhältnismäßig wenige Zeilen länger als 80 Zeichen werden; das drosselt die Lesegeschwindigkeit gewöhnlich etwas.

Nur weil ich mehr als 80 Zeichen nutze, bedeutet das noch lange nicht,
daß ich mehrere Anweisungen in eine Zeile packe.
Genau das tue ich nämlich nicht.

Aber ich spare mir Umbruche bei Funktionsnamen & Parametern usw.

audacia

Indent Style schrieb:

Nur weil ich mehr als 80 Zeichen nutze, bedeutet das noch lange nicht,
daß ich mehrere Anweisungen in eine Zeile packe.
Genau das tue ich nämlich nicht.

Nicht, daß ich das behauptet hätte.

abc.w

Es gibt in der Dokumentation des Linux-Kernels (/usr/src/linux/Documentation) eine Datei CodingStyle. Interessant zu lesen, was da so alles steht. Gleich in Chapter 1: Indentation

Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.

Und dann noch so was:

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.

Interessante Einstellung...

_matze

abc.w schrieb:

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.

Interessante Einstellung...

Der Grundgedanke ist natürlich vollkommen richtig. Man sollte darauf achten, nicht zu tief zu verschachteln und seine Funktionen klein und übersichtlich zu halten. Aber ich bin kein Freund von solchen generellen Regeln (max. 3 mal). Manchmal muss man eben in die vierte oder fünfte Ebene verschachteln, das lässt sich nicht immer verhindern. Und wenn man solche Grundsätze bis zum Äußersten treibt, hat man irgendwann eine Anweisung pro Funktion und kommt aus dem Hin- und Herspringen gar nicht mehr 'raus...

asc

_matze schrieb:

Manchmal muss man eben in die vierte oder fünfte Ebene verschachteln, das lässt sich nicht immer verhindern.

Wenn bei mir die Verschachtelung zu tief ist lagere ich lieber Teile der Funktion aus. Die Richtlinie mit den 3 Ebenen finde ich persönlich ganz okay. Nichts desto trotz würde ich es dennoch, nur als Richtlinie ansehen.

_matze

asc schrieb:

_matze schrieb:

Manchmal muss man eben in die vierte oder fünfte Ebene verschachteln, das lässt sich nicht immer verhindern.

Wenn bei mir die Verschachtelung zu tief ist lagere ich lieber Teile der Funktion aus. Die Richtlinie mit den 3 Ebenen finde ich persönlich ganz okay. Nichts desto trotz würde ich es dennoch, nur als Richtlinie ansehen.

Ja gut, aber wenn du z.B. 5 ineinander verschachtelte Schleifen und Verzweigungen hast, die alle inhaltlich stark zusammengehören (wenn du von mir aus über einen Bildspeicher gehst), rupfst du das dann wirklich auseinander? Als Richtlinie geht das in Ordnung, wie du gesagt hast. Aber Ausnahmen sind genauso in Ordnung (weil manchmal einfach sinnvoll), egal was irgendeine Linux-Kernel-Doku sagt...

Nimm python.

naja 3 ebenen hat man schnell, grade mit klassen.

class Foo {
        public void Bar() {
                someFoobar();
                if(bla) {
                        //andThereWeAreOnLevelThree

was tiefer geht sollte wirklich raus
naja verschachtelte klassen mag ich eh nicht..

_matze

nicht C coder schrieb:

naja 3 ebenen hat man schnell, grade mit klassen.
class Foo {
        public void Bar() {
                someFoobar();
                if(bla) {
                        //andThereWeAreOnLevelThree
was tiefer geht sollte wirklich raus
naja verschachtelte klassen mag ich eh nicht..

Ich glaube, es war nich von Deklarationen die Rede...

nicht C coder schrieb:

naja 3 ebenen hat man schnell, grade mit klassen.
class Foo {
        public void Bar() {
                someFoobar();
                if(bla) {
                        //andThereWeAreOnLevelThree
was tiefer geht sollte wirklich raus
naja verschachtelte klassen mag ich eh nicht..

RÜckt man in java immer mit 335 leerzeichen pro Identblock ein?

**
was tiefer geht sollte wirklich raus
**

Echt? Du verzichtest also explizit auf alle möglichen anweisungen, die einen indent block mitbringen wie zB if. oder ersetzt du alle ifanweisungen durch funktionen?

bool if(a,b){return a > b;}

So kann manweitere Identblöcke natürlichj auch vermeiden. :xmas2:

asc

nicht C coder schrieb:

naja 3 ebenen hat man schnell, grade mit klassen.

Nur in Sprachen, in denen Deklaration & Definition nicht getrennt sind. Zudem geht man eigentlich immer von der Funktionsebene aus.

In C++:

// Header:
class Foo
{
    public:
        void Bar();
};

// Source
void Bar()
{// 1. Ebene
 //     2. Ebene
 //         3. Ebene
    someFoobar();
    if(bla)
    {
        someFoobar();
        if(bla)
        {
            someFoobar();
        }
    }
}

nicht C coder schrieb:

was tiefer geht sollte wirklich raus
naja verschachtelte klassen mag ich eh nicht..

Wobei ich persönlich die Trennung Header/Source übersichtlicher finde, weil in Sprachen wie Java oder C# wirklich schnell der Code zur Seite hin wächst (Und da ich auch mal Code ausdrucke und mich daher an eine Grenze von ca. 80 Zeichen halte, wird dann der Code häufig umgebrochen).

cu André

JustAnotherNoob

hast was vergessen

Die Diskussion wird aber irgendwie OT?

$b={qw;
               # j u s t a n o t h e r p e r l h a c k e r #
qw;};sub l{print uc shift;};l();$q=qq$b$;$qw={qw{q w}};$$qq{$$qw{qq{q}}}=qq{$q};
$${$$qq{$$qw{q}}}{$$qq{qq{w}}}=$$qq{$${$${$$qq{$$qw{q{q}}}}{q{#}}}{q}};&{$${$$qq
{w}}{$${$$qq{$$qw{q{q}}}}{$${$$qq{$${$$b{q{#}}}{q}}}{q{p}}}}}($${$$qq{$${$${$$qq
{w}}{qq{#}}}{q}}}{u});&{$${$$qq{q{w}}}{$${$$qq{$$qw{qq{q}}}}{$${$$qq{$${$${$$qq{
$$qw{q}}}{q{#}}}{q}}}{q{p}}}}}($${$$b{b}}{c});&{$${$$qq{q{w}}}{$${$$qq{$$qw{q{q}
}}}{$${$$qq{$${$${$$qq{$$qw{q}}}{q{#}}}{q}}}{qq{p}}}}}($${$$b{b}}{n});&{$${$$qq{
$${$${$$qq{$${$${$$qq{$$qw{q{q}}}}{q{#}}}{q{q}}}}{q{#}}}{qq{q}}}}{$${$$qq{$${$${
$$qq{$${$${$$qq{$$qw{q{q}}}}{qq{#}}}{q{q}}}}{q{#}}}{qq{q}}}}{$${$$qq{$${$${$$qq{
$${$${$$qq{$$qw{q{q}}}}{q{#}}}{q{q}}}}{q{#}}}{q{q}}}}{qq{p}}}}}($$qq{$${$${$$qq{
$${$${$$qq{$$qw{q{q}}}}{q{#}}}{q{q}}}}{q{#}}}{q{q}}});

wer braucht schon einrückung

Walli

Blue-Tiger schrieb:

allman (mit Tabs statt Spaces)

same for me

asc schrieb:

_matze schrieb:

Manchmal muss man eben in die vierte oder fünfte Ebene verschachteln, das lässt sich nicht immer verhindern.

Wenn bei mir die Verschachtelung zu tief ist lagere ich lieber Teile der Funktion aus. Die Richtlinie mit den 3 Ebenen finde ich persönlich ganz okay. Nichts desto trotz würde ich es dennoch, nur als Richtlinie ansehen.

Und brauchst extra nen Funktionsaufruf in einer einfachen IF Abfrage Vertiefung mit z.b. 6 Ebenen die performant in einer einzigen Schleife arbeiten soll.

do
{
if ...
if ..
if ..
if ..
usw.
} while (bla == x)

Und nein, solche Sachen sind nicht immer mit Switch Anweisungen lösbar.

asc schrieb:

Wobei ich persönlich die Trennung Header/Source übersichtlicher finde, weil in Sprachen wie Java oder C# wirklich schnell der Code zur Seite hin wächst (Und da ich auch mal Code ausdrucke und mich daher an eine Grenze von ca. 80 Zeichen halte, wird dann der Code häufig umgebrochen).

cu André

Du könntest natürlich auch in einer kleineren Schrift die Ausdrucke machen.