c:tutorial:start

[cloidnerux]

Vlt interessant fürs Tutorial:
http://panopticoncentral.net/2011/05/16 ... ogrammers/

[Xin]

Du bist nicht zufällig auch bei der Konkurrenz unterwegs? Code-Project zum Beispiel? ;-D

[cloidnerux]

Du bist nicht zufällig auch bei der Konkurrenz unterwegs? Code-Project zum Beispiel? ;-D

Nein, ich bekomme nur den Newsletter^^

Edit: Es ist ja nicht mal wirkliche Konkurrenz, weil wir wenig mit dem Englischen Raum zu tun haben
Aber CodeProject hat die besseren C# Beispiele und überhaupt mehr davon

[Xin]

1.) Do not write long procedures. A procedure should not have more than ten or twelve lines.

Die Regel ist so wie sie da steht falsch. Das funktioniert nur in C++, wenn man Getter und Setter hat und ich habe Getter und Setter, die ich nur mit Mühe in 12 Zeilen unterbringen könnte.
Wie in aller Welt sollte ich da ein switch-Anweisung unterbringen!?

2.) Each procedure should have a clear purpose. It should not overlap in purpose with the procedures that went before or come after. A good program is a series of clear, non-overlapping procedures.

Grundsätzlich stimme ich zu. Trotzdem überlappen sich viele Funktionen, wenn es Spezialisierungen oder Optimierungen erforderlich sind.

3.) Do not use fancy language features. If you’re using something more than variable declarations, procedure calls, control flow statements and arithmetic operators, there is something wrong. The use of simple language features compels you to think about what you are writing. Even difficult algorithms can be broken down into simple language features.

Hier stellt sich die Frage, was "difficult" ist. Wenn's schwer ist, macht's kein Anfänger.

4.) Never use language features whose meaning you are not sure of. If you break this rule you should look for other work.

Zumindest nicht in Programmen, die man wirklich einsetzen will. Anfänger üben vorrangig, was bedeutet, dass sie so oder so nicht sicher sind.

5.) The beginner should avoid using copy and paste, except when copying code from one program they have written to a new one they are writing. Use as few files as possible.

Dem stimme ich grundsätzlich auch zu. Wobei es hier verschiedene Ansichten und Gesichtspunkte gibt.

6.) Avoid the abstract. Always go for the concrete. [Ed. note: This one applies unchanged.]

Hmm... Abstraktion ist eigentlich das Ziel von objektorientierter Programmierung und generischer Programmierung.

Every day, for six months at least, practice programming in this way. Short statements; short, clear, concrete procedures. It may be awkward, but it’s training you in the use of a programming language. It may even be getting rid of the bad programming language habits you picked up at the university. You may go beyond these rules after you have thoroughly understood and mastered them.

Ich sage immer, dass man Programmieren lernt, in dem man erfährt, was nicht geht - und warum es nicht geht.

Diese Regeln gehen davon aus, dass man einsatzfähige Programme produziert. Diese Regeln erscheinen mir für Anfänger angemessen. Das können zum Beispiel Informatik-Bachelors sein, die neben dem Studium keine Erfahrung haben und dann produktiv arbeiten sollen. Wer einsteigt möge bitte so viele Fehler machen, wie möglich, aber deswegen auch nicht ohne tiefgreifende Kontrolle produktiv an echter Software zu arbeiten.

[cloidnerux]

1.) Do not write long procedures. A procedure should not have more than ten or twelve lines.

Die Regel ist so wie sie da steht falsch. Das funktioniert nur in C++, wenn man Getter und Setter hat und ich habe Getter und Setter, die ich nur mit Mühe in 12 Zeilen unterbringen könnte.
Wie in aller Welt sollte ich da ein switch-Anweisung unterbringen!?

Naja, es gibt verschiedene Auffassungen, aber jede sagt aus, das man Funktionen kurz halten soll.
Ich hab in einem prototyp-Programm eine Funktion über gut 100 Zeilen->Großer Mist, habe aber keine Lust das im Moment zu ändern.

12 Zeilen ist Möglich, aber nicht immer Sinnvoll. Ich bin eher für maximal 1 Bildschirmseite.

2.) Each procedure should have a clear purpose. It should not overlap in purpose with the procedures that went before or come after. A good program is a series of clear, non-overlapping procedures.

Grundsätzlich stimme ich zu. Trotzdem überlappen sich viele Funktionen, wenn es Spezialisierungen oder Optimierungen erforderlich sind.

Wobei du hier wahrscheinlich auch von C++ Sprichst und dort hast du die Möglichkeit, Funktionen in Klassen und Namespaces zu kapseln.
Generell ist das auch eine sehr gute Regel, aber nur für Anfänger, wo die Programme nicht so umständlich sind.

3.) Do not use fancy language features. If you’re using something more than variable declarations, procedure calls, control flow statements and arithmetic operators, there is something wrong. The use of simple language features compels you to think about what you are writing. Even difficult algorithms can be broken down into simple language features.

Hier stellt sich die Frage, was "difficult" ist. Wenn's schwer ist, macht's kein Anfänger.

Naja, es geht hier wahrscheinlich auch eher darum, Anfängern zu zeigen, das wirklich ALLES auf ihrem Computer darauf(und etwas ASM) basiert.
Denn viele Anfänger haben meiner Meinung nach den Denkansatz, das "schwierige" Probleme sich nicht auf sowas "einfaches" reduzieren lassen und so schnell sich etwas Hilflos vorkommen.
Wenn man sich aber etwas "stur" daran hält, merkt man schnell, das viele nur mehr Coding-Aufwand bedeutet, nicht aber wirklich mehr Denkarbeit. Und das auch das komplexeste Problem sich auf etwas so einfaches Reduzieren lässt.

4.) Never use language features whose meaning you are not sure of. If you break this rule you should look for other work.

Zumindest nicht in Programmen, die man wirklich einsetzen will. Anfänger üben vorrangig, was bedeutet, dass sie so oder so nicht sicher sind.

Es gibt glaube ich 21 Schlüsselwörter in C. Hinzu kommen noch printf, scanf, gets und später auch noch file, cstrings und die dazugehörigen Funktionen.
Das kann man innerhalb eines Monats lernen.
Und damit kann man schon sehr viel erreichen. Vom schiffe Versenken bis zu einem Bild-generator.
Das heißt, man kann extrem viel Üben, ohne neue Features erlernen zu müssen. Zudem sehe ich es Positiv, wenn jemand eine Lösung für ein Problem für sich selber findet und nicht einfach eine schon fertige Funktion nutzt.

6.) Avoid the abstract. Always go for the concrete. [Ed. note: This one applies unchanged.]

Hmm... Abstraktion ist eigentlich das Ziel von objektorientierter Programmierung und generischer Programmierung.

Ich glaube er verwendet "abstract" als Nomen und meint damit "Abstraktes" zu vermeiden, nicht Abstraktion zu vermeiden.
Dabei wird der Autor darauf hinzielen, das man nicht sein Code anfangen soll so Kryptisch und Optimiert wie nur Irgends möglich zu schreiben, sodass man ihn am ende nur sehr Schwer verstehen kann.
So etwas hatte ich auch in dem besagten Prototype-Programm. Ich hatte pointer auf andere Klassen innerhalb einer Klasse die von einer anderen Klasse referenziert wurde und dann habe ich damit gearbeitet.
Und das gab Müll. Hier hätte ein konkreterer Ansatz mehr erreicht.

Ich sage immer, dass man Programmieren lernt, in dem man erfährt, was nicht geht - und warum es nicht geht.

Diese Regeln gehen davon aus, dass man einsatzfähige Programme produziert. Diese Regeln erscheinen mir für Anfänger angemessen. Das können zum Beispiel Informatik-Bachelors sein, die neben dem Studium keine Erfahrung haben und dann produktiv arbeiten sollen. Wer einsteigt möge bitte so viele Fehler machen, wie möglich, aber deswegen auch nicht ohne tiefgreifende Kontrolle produktiv an echter Software zu arbeiten.

"Sprachen" lernt man nur durch "sprechen". Das ist der sinn davon
Aber wie du sagtest und der Titel der Seite ist:

Seven Rules for Beginning Programmers

Wenn du jahrelange Erfahrung hast, brauchst du solche Regeln nicht.
Wenn man sich aber einmal schlechten Code angewöhnt hat, wird man ihn so schnell nicht los.

[Xin]

Naja, es gibt verschiedene Auffassungen, aber jede sagt aus, das man Funktionen kurz halten soll.
Ich hab in einem prototyp-Programm eine Funktion über gut 100 Zeilen->Großer Mist, habe aber keine Lust das im Moment zu ändern.

Meine sagt das nicht aus. Ich sage aus, dass ein Quelltext übersichtlich formatiert sein muss.
Über die Länge des Quelltextes oder einer Funktion lasse ich mich nicht aus.

Die größte Funktion, die ich mal hatte lag alleine in einem Quelltext, weil ich Kompilierzeit sparte, wenn diese Funktion nicht im gleichen Quelltext liegt, wie der Rest der Klasse und damit auch nicht immer neu kompiliert wurde. Das waren zwischenzeitlich mal 95kB - eine Funktion. Wenn ich mich recht entsinne und die waren besser zu bearbeiten als das meiste, was ich jetzt so sehe.

Ob ein Konzept großer Mist ist, kann ich an einem Prototyp nicht allgemein festlegen.

Wobei du hier wahrscheinlich auch von C++ Sprichst und dort hast du die Möglichkeit, Funktionen in Klassen und Namespaces zu kapseln.

Optimieren kann man auch in C.

Es gibt glaube ich 21 Schlüsselwörter in C. Hinzu kommen noch printf, scanf, gets und später auch noch file, cstrings und die dazugehörigen Funktionen.
Das kann man innerhalb eines Monats lernen.

Öhm... ja, kann man... wenn man sich sonst mit nichts beschäftigt.

Ich glaube er verwendet "abstract" als Nomen und meint damit "Abstraktes" zu vermeiden, nicht Abstraktion zu vermeiden.
Dabei wird der Autor darauf hinzielen, das man nicht sein Code anfangen soll so Kryptisch und Optimiert wie nur Irgends möglich zu schreiben, sodass man ihn am ende nur sehr Schwer verstehen kann.

So kann ich es akzeptieren.

Diese Regeln gehen davon aus, dass man einsatzfähige Programme produziert. Diese Regeln erscheinen mir für Anfänger angemessen. Das können zum Beispiel Informatik-Bachelors sein, die neben dem Studium keine Erfahrung haben und dann produktiv arbeiten sollen. Wer einsteigt möge bitte so viele Fehler machen, wie möglich, aber deswegen auch nicht ohne tiefgreifende Kontrolle produktiv an echter Software zu arbeiten.

"Sprachen" lernt man nur durch "sprechen". Das ist der sinn davon
Aber wie du sagtest und der Titel der Seite ist:

Seven Rules for Beginning Programmers

Wenn du jahrelange Erfahrung hast, brauchst du solche Regeln nicht.
Wenn man sich aber einmal schlechten Code angewöhnt hat, wird man ihn so schnell nicht los.

Ich halte meinen Code für relativ gut. Ich habe mit Basic angefangen. ^^

Ein CS-Bachelor nur mit dem Wissen aus dem Studium kann mit den Regeln was anfangen. Während des Studiums - also da wo derjenige wirklich Anfänger ist - sind die Regeln nicht für mehr zu gebrauchen, als nettes Ideal für die Zukunft.
Der Einstieg ist eine Weg von einem Prototypen zum Nächsten.

[Dirty Oerti]

Eine kurze Anmerkung zu diesen Regeln ... auch wenn es nun schon etwas länger her ist:

1.) Do not write long procedures. A procedure should not have more than ten or twelve lines.

Regeln wie diese halte ich für den größten B##lsh#t überhaupt.
Da wären wir auch wieder gut bei der Diskussion, was LOC überhaupt für eine Aussage im Bezug auf den Sinn, die Korrektheit oder die Intelligenz eines Code(stückes) hat.

Wenn ich, nur um diese Regel einzuhalten, Kaskaden von Funktionen habe, die alle nur von einer Funktion gerufen werden, und ich die Funktionen nur habe, um die eine Funktion nicht zu "groß" werden zu lassen, dann mache ich etwas falsch.

Eine Funktion sollte, wie es in einer anderen Regel dort heißt, möglichst "abgeschlossen" sein.

Sprich: Ich weiß, was sie tut. Sie tut das, und auch wirklich nur das. Nicht mehr, nicht weniger.

Wenn ich eine Funktion schreibe, die mir z.B. einen Vektor im ECI (Earth Centered Ineartial) System in das ECEF (Earth Centered Fixed) System umrechnet, dann braucht so eine Funktion auch mal ihren Platz.
Da sind nun mal ein paar Berechnungen zu tätigen, und die müssen sein.
Da lagere ich Teile der Berechnungen nicht aus, das bringt nichts, damit sind diese ausgelagerten Funktionen alles andere als abgeschlossen. (Außer natürlich, es handelt sich um Berechnungen, die auch anderweitig wiederverwendet werden können, Rotationsmatrizen o.ä.)

[Dirty Oerti]

http://www.proggen.org/doku.php?id=c:tutorial:quickops

Ich hab hier einen unvollständigen Satz beendet, kA ob du das so gemeint hattest?

[Xin]

*thumbs up*

[Xin]

Soo.... ich bin dann auch mal wieder am Start.

Nachdem ich mich etwas verfahren habe und etwas Probleme hatte, da wieder den Anschluss zu finden, habe ich jetzt mal die Rekursion vorgezogen und jetzt geht's wieder weiter.

Der Artikel 'Software-Architektur' muss entsprechend noch überarbeitet werden.