c:tutorial:start
- cloidnerux
- Moderator
- Beiträge: 3123
- Registriert: Fr Sep 26, 2008 4:37 pm
- Wohnort: Ram (Gibts wirklich)
Re: c:tutorial:start
Vlt interessant fürs Tutorial:
http://panopticoncentral.net/2011/05/16 ... ogrammers/
http://panopticoncentral.net/2011/05/16 ... ogrammers/
Redundanz macht wiederholen unnötig.
quod erat expectandum
quod erat expectandum
- Xin
- nur zu Besuch hier
- Beiträge: 8859
- Registriert: Fr Jul 04, 2008 11:10 pm
- Wohnort: /home/xin
- Kontaktdaten:
Re: c:tutorial:start
Du bist nicht zufällig auch bei der Konkurrenz unterwegs? Code-Project zum Beispiel? ;-D
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
- cloidnerux
- Moderator
- Beiträge: 3123
- Registriert: Fr Sep 26, 2008 4:37 pm
- Wohnort: Ram (Gibts wirklich)
Re: c:tutorial:start
Nein, ich bekomme nur den Newsletter^^Du bist nicht zufällig auch bei der Konkurrenz unterwegs? Code-Project zum Beispiel? ;-D
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
Redundanz macht wiederholen unnötig.
quod erat expectandum
quod erat expectandum
- Xin
- nur zu Besuch hier
- Beiträge: 8859
- Registriert: Fr Jul 04, 2008 11:10 pm
- Wohnort: /home/xin
- Kontaktdaten:
Re: c:tutorial:start
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.panopticoncentral.net hat geschrieben:1.) Do not write long procedures. A procedure should not have more than ten or twelve lines.
Wie in aller Welt sollte ich da ein switch-Anweisung unterbringen!?
Grundsätzlich stimme ich zu. Trotzdem überlappen sich viele Funktionen, wenn es Spezialisierungen oder Optimierungen erforderlich sind.panopticoncentral.net hat geschrieben: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.
Hier stellt sich die Frage, was "difficult" ist. Wenn's schwer ist, macht's kein Anfänger.panopticoncentral.net hat geschrieben: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.
Zumindest nicht in Programmen, die man wirklich einsetzen will. Anfänger üben vorrangig, was bedeutet, dass sie so oder so nicht sicher sind.panopticoncentral.net hat geschrieben:4.) Never use language features whose meaning you are not sure of. If you break this rule you should look for other work.
Dem stimme ich grundsätzlich auch zu. Wobei es hier verschiedene Ansichten und Gesichtspunkte gibt.panopticoncentral.net hat geschrieben: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.
Hmm... Abstraktion ist eigentlich das Ziel von objektorientierter Programmierung und generischer Programmierung.panopticoncentral.net hat geschrieben:6.) Avoid the abstract. Always go for the concrete. [Ed. note: This one applies unchanged.]
Ich sage immer, dass man Programmieren lernt, in dem man erfährt, was nicht geht - und warum es nicht geht.panopticoncentral.net hat geschrieben: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.
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.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
- cloidnerux
- Moderator
- Beiträge: 3123
- Registriert: Fr Sep 26, 2008 4:37 pm
- Wohnort: Ram (Gibts wirklich)
Re: c:tutorial:start
Naja, es gibt verschiedene Auffassungen, aber jede sagt aus, das man Funktionen kurz halten soll.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.1.) Do not write long procedures. A procedure should not have more than ten or twelve lines.
Wie in aller Welt sollte ich da ein switch-Anweisung unterbringen!?
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.
Wobei du hier wahrscheinlich auch von C++ Sprichst und dort hast du die Möglichkeit, Funktionen in Klassen und Namespaces zu kapseln.Grundsätzlich stimme ich zu. Trotzdem überlappen sich viele Funktionen, wenn es Spezialisierungen oder Optimierungen erforderlich sind.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.
Generell ist das auch eine sehr gute Regel, aber nur für Anfänger, wo die Programme nicht so umständlich sind.
Naja, es geht hier wahrscheinlich auch eher darum, Anfängern zu zeigen, das wirklich ALLES auf ihrem Computer darauf(und etwas ASM) basiert.Hier stellt sich die Frage, was "difficult" ist. Wenn's schwer ist, macht's kein Anfänger.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.
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.
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.Zumindest nicht in Programmen, die man wirklich einsetzen will. Anfänger üben vorrangig, was bedeutet, dass sie so oder so nicht sicher sind.4.) Never use language features whose meaning you are not sure of. If you break this rule you should look for other work.
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.
Ich glaube er verwendet "abstract" als Nomen und meint damit "Abstraktes" zu vermeiden, nicht Abstraktion zu vermeiden.Hmm... Abstraktion ist eigentlich das Ziel von objektorientierter Programmierung und generischer Programmierung.6.) Avoid the abstract. Always go for the concrete. [Ed. note: This one applies unchanged.]
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.
"Sprachen" lernt man nur durch "sprechen". Das ist der sinn davonIch 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.
Aber wie du sagtest und der Titel der Seite ist:
Wenn du jahrelange Erfahrung hast, brauchst du solche Regeln nicht.Seven Rules for Beginning Programmers
Wenn man sich aber einmal schlechten Code angewöhnt hat, wird man ihn so schnell nicht los.
Redundanz macht wiederholen unnötig.
quod erat expectandum
quod erat expectandum
- Xin
- nur zu Besuch hier
- Beiträge: 8859
- Registriert: Fr Jul 04, 2008 11:10 pm
- Wohnort: /home/xin
- Kontaktdaten:
Re: c:tutorial:start
Meine sagt das nicht aus. Ich sage aus, dass ein Quelltext übersichtlich formatiert sein muss.cloidnerux hat geschrieben: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.
Ü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.
Optimieren kann man auch in C.cloidnerux hat geschrieben:Wobei du hier wahrscheinlich auch von C++ Sprichst und dort hast du die Möglichkeit, Funktionen in Klassen und Namespaces zu kapseln.
Öhm... ja, kann man... wenn man sich sonst mit nichts beschäftigt.cloidnerux hat geschrieben: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.
So kann ich es akzeptieren.cloidnerux hat geschrieben: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.
Ich halte meinen Code für relativ gut. Ich habe mit Basic angefangen. ^^cloidnerux hat geschrieben:"Sprachen" lernt man nur durch "sprechen". Das ist der sinn davonXin hat geschrieben: 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.
Aber wie du sagtest und der Titel der Seite ist:Wenn du jahrelange Erfahrung hast, brauchst du solche Regeln nicht.Seven Rules for Beginning Programmers
Wenn man sich aber einmal schlechten Code angewöhnt hat, wird man ihn so schnell nicht los.
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.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
- Dirty Oerti
- Beiträge: 2229
- Registriert: Di Jul 08, 2008 5:05 pm
- Wohnort: Thurndorf / Würzburg
Re: c:tutorial:start
Eine kurze Anmerkung zu diesen Regeln ... auch wenn es nun schon etwas länger her ist:
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.ä.)
Regeln wie diese halte ich für den größten B##lsh#t überhaupt.Aus einer nicht so tollen Quelle hat geschrieben:1.) Do not write long procedures. A procedure should not have more than ten or twelve lines.
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.ä.)
Bei Fragen einfach an daniel[ät]proggen[Punkt]org
Ich helfe gerne!
----------
Wenn du ein Licht am Ende des Tunnels siehst, freu dich nicht zu früh! Es könnte ein Zug sein, der auf dich zukommt!
----
It said: "Install Win95 or better ..." So I installed Linux.
Ich helfe gerne!
----------
Wenn du ein Licht am Ende des Tunnels siehst, freu dich nicht zu früh! Es könnte ein Zug sein, der auf dich zukommt!
----
It said: "Install Win95 or better ..." So I installed Linux.
- Dirty Oerti
- Beiträge: 2229
- Registriert: Di Jul 08, 2008 5:05 pm
- Wohnort: Thurndorf / Würzburg
Re: c:tutorial:start
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?
Ich hab hier einen unvollständigen Satz beendet, kA ob du das so gemeint hattest?
Bei Fragen einfach an daniel[ät]proggen[Punkt]org
Ich helfe gerne!
----------
Wenn du ein Licht am Ende des Tunnels siehst, freu dich nicht zu früh! Es könnte ein Zug sein, der auf dich zukommt!
----
It said: "Install Win95 or better ..." So I installed Linux.
Ich helfe gerne!
----------
Wenn du ein Licht am Ende des Tunnels siehst, freu dich nicht zu früh! Es könnte ein Zug sein, der auf dich zukommt!
----
It said: "Install Win95 or better ..." So I installed Linux.
- Xin
- nur zu Besuch hier
- Beiträge: 8859
- Registriert: Fr Jul 04, 2008 11:10 pm
- Wohnort: /home/xin
- Kontaktdaten:
Re: c:tutorial:start
*thumbs up*
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
- Xin
- nur zu Besuch hier
- Beiträge: 8859
- Registriert: Fr Jul 04, 2008 11:10 pm
- Wohnort: /home/xin
- Kontaktdaten:
Re: c:tutorial:start
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.
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.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.