Hallo zusammen!
Neulich habe ich zwar schon einmal auf mein letztes Geschreibsel aufmerksam gemacht, aber außer dem Hinweis, dass ein Absätzchen zu viel ist, gab es hier kein Echo.
Es wäre schön, wenn sich mal jemand das hier durchlesen und Bescheid geben könnte, ob da was flasch ist oder fehlt. Tippfehler sollten keine mehr drin sein.
Danke vorweg!
Gregor
Moin,
Im Wiki unter Programmablaufplan steht: "Spezielle Programme bieten oft zusätzliche Fähigkeiten wie zum Beispiel automatisches Entflechten („kreuzungsfrei machen“) von Pfeilen und Verknüpfungslinien, oder das Prüfen auf Korrektheit entsprechend der DIN."
Gibt's so was als Freeware?
Lieben Gruß,
Chris
gregorss:
Neulich habe ich zwar schon einmal auf mein letztes Geschreibsel aufmerksam gemacht, aber außer dem Hinweis, dass ein Absätzchen zu viel ist, gab es hier kein Echo.
Naja, ich halte es da wie Dieter Nuhr.
Finnlay:
Naja, ich halte es da wie Dieter Nuhr.
Was meinst Du damit?
Gruß
Gregor
Nicht persönliches oder so... ich kenne dich ja nicht. Also bitte auch nicht persönlich nehmen.
Dieter Nuhr prägte einst den Satz, "Wenn man keine Ahnung hat, einfach mal Fresse halten".
Wenn also jemand der Meinung ist, zu einem Thema auch lieber die Fresse halten zu wollen, sollte man ihn nicht herausfordern doch etwas dazu zu sagen. Das ist meine Interpretation.
Das hast du aber nunmal doch getan...
Darum diese meine Antwort.
Ob ein Quellcode "schön" ist oder nicht, liegt wie Kunst im Auge des Betrachters. Ich bin froh eine Lebenspartnerin gefunden zu haben, die auf die Frage: "Ist das Kunst, oder kann das weg?", zu über 90% meiner Meinung ist, es kann wech.
Du erwünschst eine Antwort auf deinen "Blog" zur Schönheit von Quellcode. Das war meine.
Quellcode muss nicht schön sein, er muss lebar und im Nachhinein weiterhin interpretierbar sein.
Kannst du damit leben? Ich hoffe und wünsche dir nicht zu nahe getreten zu sein.
MfG
IMHO, hast du in vielen Sätzen zusammengefasst: drückt STRG-T
soll heißen. Ist MIR etwas zu obeflächlich.
Warum:
Code nicht breiter als 80 Zeichen. ... das kommt aus dem Jahre Schnee, heute sind meine Monitore wesentlich breiter. Außerdem gibts in der Arduino IDE noch keinen Spaltenzähler, also weis ich gar nicht wo 80 aufhört.
In der Praxis kann ich nur sagen, selbst die alten (auch die ganz alten) Host Entwickler bei uns drucken kaum mehr Code (auf Zeilenfinder) [und die Jungen wissen eh nicht mehr wie sie einen Druckjob aus der Entwicklungsumgebung ans Durckzentrum senden ;-)]
Funktionen sollten vollständig auf eine Bildschirmseite passen... du weist nicht wie groß mein Monitor ist, du weist nicht wie groß ich das Compile-Fenster brauche, also kannst du mir auch nicht Regeln geben wie viel ich im SourceCode Fenster sehen soll.
Gestrüpp aus dem Weg räumen. ... in Tabs lege ich Sachen die Zusammengehören und "irgendwann" mal eine Compilierbare Einheit bilden sollen. Also weniger "ich will es nicht sehen" sondern "gehört thematisch zusammen".
Hinweise zu diesem Thema würde ich eher geben:
Naming Things (z.B. Variablen-Namen, sprechende Funktionsnamen ...)
Querverweise auf Notationen, (was du mit den geschweiften Klammern beispielhaft nur angerissen hast).
noiasca:
IMHO, hast du in vielen Sätzen zusammengefasst: drückt STRG-T
Einfach nur Strg-T zu drücken hat zu dem Zeitpunkt, als ich die erste Fassung geschrieben habe, dazu geführt, dass eigene Formatierungen zerstört wurden. Das ist inzwischen wohl nicht mehr so.
noiasca:
Code nicht breiter als 80 Zeichen. ... das kommt aus dem Jahre Schnee, heute sind meine Monitore wesentlich breiter.
Den ursprünglichen Grund dafür habe ich ja geschrieben. Zudem: Ich (und auch andere) arbeite gerne auf Papier und formatiere den Code vor dem Ausdrucken mit „a2ps“, das den Code mit der Schriftart Courier formatiert. Zeilen, die breiter als 80 Zeichen sind, werden dann umbrochen, was Einrückungen „zerstört“.
noiasca:
Außerdem gibts in der Arduino IDE noch keinen Spaltenzähler, also weis ich gar nicht wo 80 aufhört.
In der IDE wird die Stelle, an der die Schreibmarke steht, in der Statuszeile angegeben. Da stehen IIRC sowohl Zeile als auch die Stelle innerhalb der aktuellen Zeile.
noiasca:
In der Praxis kann ich nur sagen, selbst die alten (auch die ganz alten) Host Entwickler bei uns drucken kaum mehr Code (auf Zeilenfinder) [und die Jungen wissen eh nicht mehr wie sie einen Druckjob aus der Entwicklungsumgebung ans Durckzentrum senden ;-)]
Was ein „alter“ Entwickler ist, ist eine Frage der Interpretation. Ich habe noch auf Bernstein-Monitoren gearbeitet (auch damals gingen nur 80 Zeichen in eine Zeile).
noiasca:
Funktionen sollten vollständig auf eine Bildschirmseite passen... du weist nicht wie groß mein Monitor ist, du weist nicht wie groß ich das Compile-Fenster brauche, also kannst du mir auch nicht Regeln geben wie viel ich im SourceCode Fenster sehen soll.
Klar kannst Du auf Deinem Monitor viele Zeichen pro Zeile und viele Zeilen pro Monitorseite darstellen. Mein xterm schafft 240 Zeichen/Zeile und >60 Zeilen, ohne dass ich scrollen muss. Ich kann dort auch Umlaute und sonstwas darstellen. Wenn ich ausschließlich mit meinem eigenen Code zu tun habe, stört sowas nicht. Sobald ich aber Code schreibe, den jeder auf nahezu jedem Gerät ungestört lesen können soll, halte ich mich an Dinge, die möglichst den geringsten Ansprüchen genügen (ich benutze zum Beispiel grundsätzlich keine Umlaute, auch nicht in Kommentaren).
noiasca:
Gestrüpp aus dem Weg räumen. ... in Tabs lege ich Sachen die Zusammengehören und "irgendwann" mal eine Compilierbare Einheit bilden sollen. Also weniger "ich will es nicht sehen" sondern "gehört thematisch zusammen".
Wie Du Deinen Code organisierst, ist natürlich Deine Sache. Mir kommt es auf Übersichtlichkeit an. Wenig scrollen zu müssen (auch horizontal), hilft dabei.
noiasca:
Hinweise zu diesem Thema würde ich eher geben:
Naming Things (z.B. Variablen-Namen, sprechende Funktionsnamen ...)
Querverweise auf Notationen, (was du mit den geschweiften Klammern beispielhaft nur angerissen hast).
Das mit den sprechenden Variablennamen ist ebenfalls Deine Sache. Manche kommen prima mit Variablennamen wie „AnalIn“ zurecht, andere denken da an ihr Rektum 
Schönheit liegt im Auge des Betrachters. Und solange ich der Einzige bin, der sich mit meinem Code befassen muss, ist das mit den Umlauten, Einrückungen usw. natürlich nur für mich relevant. Problematisch kann es werden, wenn man im Team arbeitet (muss oder möchte).
Danke für Deine Anmerkungen!
Gregor
Moin,
Im Wiki unter Programmablaufplan steht: "Spezielle Programme bieten oft zusätzliche Fähigkeiten wie zum Beispiel automatisches Entflechten („kreuzungsfrei machen“) von Pfeilen und Verknüpfungslinien, oder das Prüfen auf Korrektheit entsprechend der DIN."
Gibt's so was als Freeware?
Lieben Gruß,
Chris
themanfrommoon:
Moin,Im Wiki unter Programmablaufplan steht: "Spezielle Programme bieten oft zusätzliche Fähigkeiten wie zum Beispiel automatisches Entflechten („kreuzungsfrei machen“) von Pfeilen und Verknüpfungslinien, oder das Prüfen auf Korrektheit entsprechend der DIN."
Gibt's so was als Freeware?
Lieben Gruß,
Chris
Frag' das besser in einem separaten Thread.
Gruß
Gregor
Okay, aber spätestens damit hat sich der Sinn dieses Threads erledigt. Wenn nicht mal Fragen zum Thema erlaubt sind, dann ist das hier nix wert. Was soll das? Es interessiert niemanden, niemand schreibt was, dann wir extra nachgehakt und dargestellt, dass es wenig sinnvoll ist, dann wird zum Thema was gefragt und geantwortet dass man dafür einen eigenen Thread aufmachen soll.
Wenn du mich fragst, dann wäre es besser gewesen wenn du nix geschrieben hättest, weder auf deiner Website, noch hier im Forum. Das ist ein einziges Fishing for compliments, sonst nix, bei aller Liebe. Das braucht ausser dir keiner. Das ist komplett überflüssig, und kann gelöscht werden. Lächerlich! Und deswegen bin ich jetzt raus. Tschüss
Hallo Gregor,
da mir der Beitrag über mir nicht gefällt, schreibe ich nun auch was dazu.
Die Weekender sind, wie ich meine, für Anfänger gedacht und nicht für Könner.
Ich habe schon ein paar von dir gelesen und fand sie hilfreich für mich und ich habe auch schon Teile davon in meine Programme eingearbeitet.
Dafür danke ich dir.
Mit dem letzten konnte ich nicht viel anfangen. Als Anfänger kämpft man mit scheinbar wichtigeren Problemen, da ist dir Formatierung nicht so im Vordergrund.
Je besser ich mich mit dem Arduino anfreunde, um so mehr merke ich, dass eine gute Formatierung die Fehlersuche unterstützt.
Ist eine Zeit vergangen und man macht Änderungen am Programm, dann freut man sich auch über eine gute Formatierung und vielen Kommentare im Programm.
Allgemein gültige Regeln für die Formatierung finde ich sehr schwierig, da die eigenen Vorlieben und die Gegebenheiten bei jedem anders sind.
Mach weiter mit den Weekender.
Hmm, ich tu mich damit etwas schwer.
Denn es gibt in vielen Sprachen zahlreiche (unterschiedliche und sogar gegenseitig ausschließende) Coding-Conventions.
Meist ergeben diese sich aber erst mit der Zeit und als Anfänger oder Jemand, der noch nicht auf Problem X gestoßen ist, erscheint es teilweise willkürlich.
Mein Mantra dabei ist, wenn man nicht selbst auf einen Fehler stößt, versteht man auch nicht wie man ihn verhindert. Das einfache büffeln von Regeln ist da zu müßig.
Also wer eine monolithische Gott-Funktion schreibt, die aus 300 Zeilen Code besteht, wird den Nachteil bemerken, wenn es etwas wiederverwenden möchte. Oder bei der Fehlersuche auf Deinen Fluch-Eintrag stoßen.
Schaut man nach einem Jahr in seinen Code, wird man sich ärgern, weshalb die Methoden nicht sprechend benannt wurden. Oder der Name nicht mehr dem entspricht, was die Methode nun eigentlich macht.
Es ist ein Prozess, der über Jahre wächst. Und da hilft es am besten, wenn man sich durch sauberen Code von Anderen inspirieren lässt.
Ehrlich gesagt bin ich persönlich in der Arduino-Welt noch weit von Clean-Code entfernt. Nicht weil ich die Prinzipien nicht kenne, sondern weil ich aus anderen Sprachen komme, wo andere Regeln gelten.
Klar, Länge und Benennung von Funktionen sind generelle Dinge. Aber alleine die Kleinschreibung ist für mich ein Graus!
Ebenfalls finde ich die Geschweiften Klammern deutlich übersichtlicher, wenn diese auf einer Höhe eingerückt sind. Aber weiß denn jemand überhaupt, weshalb in manchen Sprachen die Klammer hinter den Methodennamen muss?
Vermutlich kaum noch einer! Das sind Dinge, die sind "historisch gewachsen" und werden dennoch weitergetragen. Gruselig!
Deshalb probiere ich in der Adruino-Welt Variablen und Funktionen verständlich zu benennen. Funktionen nicht zu groß werden und nur eine Aufgabe übernehmen zu lassen.
Das Ganze einigermaßen sinnvoll in Tabs aufteilen und das war es schon mehr oder weniger.
Dinge die ich in .Net, JavaScript oder anderen Sprachen beherzige, funktionieren hier einfach nicht.
themanfrommoon:
... wird zum Thema was gefragt ...
Du stellst eine Frage zum Wikipedia-Artikel. Das hat mit meinem Weekender nichts zu tun.
Gruß
Gregor
So, hab auch noch was zu verbreiten
Ich finde jegliche Arbeit die sich jemand macht grundsätzlich schon mal lobenswert. Warum andere das stellenweise zerreißen ist mir schleierhaft, zumindest wenn nichts Falsches drinsteht. Und selbst dann wäre es besser, auf Fehler hinzuweisen.
Ich schaue mir Gregors Weekender gerne an - wenn ich was davon lernen kann ist das prima, wenn ich andere Ansichten habe darf ich weiter bei denen bleiben.
Also Gregor: weitermachen, danke.
Klaus_ww:
So, hab auch noch was zu verbreiten
Danke für Deine Meldung!
Man kann natürlich denken, dass ich hier nach Komplimenten fische. Mir ging es aber tatsächlich nur um die Frage, ob sich im ersten Thread dazu keiner gemeldet hatte (außer jemandem, der mich auf einen Fehler hinwies), weil mein Getexte (ansonsten) fehlerfrei ist. Es hätte ja auch sein können, dass einfach nur alle in Urlaub waren (das war kurz nach Silvester).
Gruß
Gregor
gregorss:
außer jemandem, der mich auf einen Fehler hinwies
Gern geschehen!
Gruß Fips