Forum: C-Programmieren

Zitat:

1.Ich wollte das öffnen der Datei der Shell überlassen, im gegensatz zu cat.

Die Datei wird in jedem Fall vom OS geöffnet, damit hat weder die Shell, noch cat, noch Dein Programm etwas zu tun.

Zitat:

2. @broesel: Dein Programm ist zwar eine Lösung, aber Ich wollte erst nach EOF das gesamte Dokument ausgeben.

Zum Zwischenspeichern eignet sich die Festplatte wesentlich besser als der Arbeitsspeicher: [some_program] > /tmp/foo.txt; sed < /tmp/foo.txt

Zitat:

Außerdem ist es für den Einsatzt in Pipes (z. B. vor sed) gedacht.

Das spielt keine Rolle. Pipes arbeiten zeilenweise; wenn ein Programm eine vollständige "Datei" erwartet, muss es sowieso selbst auf EOF warten.

Zitat:

Also nicht ganz sooo ernstnehemen, das mit dem Speicher !

Das ist insbesondere bei C eine äusserst wichtige Angelegenheit. Was nutzt ein Programm, dass nur in einigen Ausnahmefällen funktioniert?


Ansonsten ist Dein Code von der Qualität deutlich besser als das, was man hier üblicherweise so sieht. Es gibt allerdings einen gravierenden Nachteil, die Lesbarkeit. Der Code ist übersäht mit nutzlosen Kommentaren, und die Einrückungen sind grauenhaft.

Tipps:

- nicht das WIE kommentieren, sondern das WARUM. Du kommentierst das WIE, aber das wird ja bereits durch den Code selbst kommentiert. Jeder Deiner Kommentare ist vollständig redundant. Benutze Kommentare lieber, um das WARUM zu erklären. Warum hast Du das Programm überhaupt geschrieben? Warum machst Du es so und nicht anders?

- keine unnötigen Leerzeichen einfügen. Vor allem Dein Spleen, alles in der gleichen Spalte anzuordnen, ist ausgesprochen gewöhnungsbedürftig. Halte Dich mit derartigen Spielereien zurück. Die Formatierung des Quellcodes ist Aufgabe der IDE.

- Du kannst bei der Definition von main() ruhig den Rückgabewert explizit angeben.

Gruss,
Philip

--
The C Programming Quiz - bitte Fragen einreichen :)

 

Zitat:
- keine unnötigen Leerzeichen einfügen. Vor allem Dein Spleen, alles in der gleichen Spalte anzuordnen, ist ausgesprochen gewöhnungsbedürftig. Halte Dich mit derartigen Spielereien zurück. Die Formatierung des Quellcodes ist Aufgabe der IDE.

Ich finde seine Formatierung OK.
Der Code ist, weil durchgängig gleich formatiert, gut lesbar.
Warum soll das Aufgabe der IDE sein? Imo kocht da alles sein eigenes Süppchen!
Da halte ich mich lieber an meine eigenen Coding-Standards.

Meine Meinung.

--
To follow the path: look to the master, follow the master, walk with the master, see through the master, become the master.

 

Hallo zusammen,

Zitat:
Imo kocht da alles sein eigenes Süppchen!

Ja, stimmt, und über dieses Thema wurden sicher schon viele Flamewars geschlagen

Zitat:

Zitat:
- keine unnötigen Leerzeichen einfügen. Vor allem Dein Spleen, alles in der gleichen Spalte anzuordnen, ist ausgesprochen gewöhnungsbedürftig. Halte Dich mit derartigen Spielereien zurück. Die Formatierung des Quellcodes ist Aufgabe der IDE.

Ich finde seine Formatierung OK.
Der Code ist, weil durchgängig gleich formatiert, gut lesbar.
Warum soll das Aufgabe der IDE sein? Imo kocht da alles sein eigenes Süppchen!
Da halte ich mich lieber an meine eigenen Coding-Standards.

Wenn ich beruflich oder für die Uni im Team was machen muss, sind Coding-Rules viel wert, da scheitert sonst die Lesbarkeit manchmal schon daran, dass unterschiedliche Tabbreiten/Codierungen oder sowas verwendet wird.

Aber wenn ich was code, an dem hauptsächlich ich alleine arbeite, dann finde ich persönlich die Formatierung mit spaltenweise Einrückung sogar sehr übersichtlich, im Vergleich dazu, wenn man alles nur mit den notwendigsten Leerzeichen/Tabs schreibt.

Zum Vergleich Quellcode in zwei verschiedenen Formatierungen. Der Quellcode ist aus dem Linux-Kernel in der dafür typischen Formatierung.

    case EV_ABS:
        event.type = JS_EVENT_AXIS;
        event.number = joydev->absmap[code];
        event.value = joydev_correct(value,
                    &joydev->corr[event.number]);
        if (event.value == joydev->abs[event.number])
            return;
        joydev->abs[event.number] = event.value;
        break;

Gleicher Quellcode, ein kleinwenig umformatiert:

    case EV_ABS:
        event.type      = JS_EVENT_AXIS;
        event.number    = joydev->absmap[ code ];
        event.value     = joydev_correct( value, &joydev->corr[ event.number ] );
        
        if( event.value == joydev->abs[ event.number ] )
        {
            return;
        }
        
        joydev->abs[ event.number ] = event.value;
        break;

Vorteil: Man erkennt schon von Weitem Zuweisungen, if-Bedingungen und Arrayzugriffe.

mfg, Wolfgang

--
Hex, Bugs and Rock 'n Roll

 

Aaalso...
Ich arbeite nur mit Texteditor (Ich benutze BlueFish) und Terminal. Ich habe die Whitespaces für mich gesetzt, weil ich es besser überschauen wollte. Es ist halt meine Programmier-art.
Und das mit den Kommentaren:
Ja, ich hab vieleicht ein paar viele Kommentare gestzt, aber nur, weil mir in ein paar Monaten der Sinn (z.b. für realloc) vieleicht schon entfallen ist.
Außerdem: Ich halte mich an Folgende Code-Konnventionen (und ein paar andere):
1.Nach und vor Operatoren setzte ich Leerzeichen. Vorne so viele dass alle Operatoren übereinanderstehen. Hinten so viele dass dass alle hinteren Operanden übereinanderstehen. Das gilt auch für Zuweisungen , Bedingungen u.Ä!
2. Die geschweiften Klammern von Blöcken gehören in eine eigene Zeile!
3. Innerhalb von Blöcken rücke ich jede Zeile mit einem Tab ein.
4. An jede Zeile gehört ein Zeilenkommentar (s.o.)

 

Das mit den Kommentaren sehe ich genau so wie Philip.
Die sollen das Warum beschreiben, nicht das Was.
Muss das Was beschrieben werden, sollte man prüfen, ob man nicht grade gegen das KISS-Prinzip verstößt.

Eine mögliche Ausnahme wäre für mich, wenn ein z.B. ein Praktikant/Azubi nachweisen soll, dass er die verwendeten Aufrufe verstanden hat.

--
To follow the path: look to the master, follow the master, walk with the master, see through the master, become the master.