Wie die Übersicht im Programmcode behalten

(Bitte in OT oder Talk moven)

Das Problem habe ich auch, ich fange an und dann merke ich das ich alles in eine Datei geschaufelt hab.
Schlimm wirds wenn man dauernd auf und ab scrollen muss, deshalb habe ich alles sorgfältig ausgelagert.
In einem Ordner include habe ich Unterordner die GUI, Network oder ähnlich heißen wo die ganzen GUIs einzeln in au3 Dateien sind.
Im Include Ordner habe ich hauptsächlich nur Helper Dateien die die einzelnen GUIs aus den Ordnern includen und so muss ich im Hauptscript nur die Helper Datei includen.

Ob ich eine Sache erst auf dem Papier mache hängt davon ab wie kompliziert sie ist, ab und zu ist es sehr hilfreich und verständlicher wenn man erst eine Skizze macht (bei Berechnungen z.B.).

Ich mache das meistens so:

- Kleines Skript wächst und wächst. Es wird groß, unübersichtlich, langsam, redundant, usw usw.
- Überlegen welche Teile des Skripts man zusammenfassen könnte.
- Diese Teile in eine eigene Datei auslagern und eine UDF daraus machen die als spezialfall das Problem löst welches im Skript vorkommt. (Dadurch wird die UDF relativ flexibel und kann ähnliche Probleme ebenfalls behandeln)
- Das gleiche gilt rekursiv. Sobald eine UDF mehr als einen Verwendungszweck besitzt sollte sie in mehrere UDFs aufgeteilt werden.
- Man sollte darauf achten, dass die UDFs möglichst unabhängig voneinander funktionieren und nicht redundant sind. (Schnittmengen mehrerer UDFs lagert man einfach in eine neue UDF aus)
- Ist alles so strukturiert, und bleiben die Schnittstellen zwischen den Skripten gleich, so kann man einzelne Programmteile verändern/optimieren, ohne das Gesamtwerk zu verändern, oder den Überblick zu verlieren.

lg
M

Hallo.
Ich halte es im Prinzip genau so wie Oscar. Zusätzlich habe ich erst kürzlich damit begonnen einen anderen Editor zu testen. "SciTE - RU" bietet noch ein Zusatzfenster an, indem
automatisch von dir erstellte Funktionen aufgelistet werden. Bei Doppelklick darauf springst du dann im Editor genau zu dieser Funktion. Erleichtert das Navigieren bei großen Scripts schon enorm.

Hmmm ja... noch schlimmer ist es wenn man nach Monaten was an dem Programm ändern muss....

Ich versuche sehr eisern sprechende Variablen zu deklarieren. Hinter Jede Variable kommt ein Kommentar wozu das gute Stück da ist.

Nun bin ich mir nicht sicher ob ich mir im folgenden den "Zorn" der erfahrenen hier im Forum zuziehe.....
Da ich aus einer anderen Generation komme bin ich kein Fan von exzessiven Schleifen und if then else Anweisungen. Weil ich da irgendwan immer den Überblick verliere. Also geh ich her und programiere das - was andere abfällig Spaghetti Code nennen. Ich packe manches einfach in Funktionen - eben wie man es früher mit "Subroutinen" oder goto Befehlen gemacht hat. Auch hier sprechende NAmen und viel Kommentar. Für mich ist das übersichtlicher als tief verschachtelte Schleifen.

Ich nummeriere die Versionen auch strikt mit Datum und Versionsnummer durch - wenn man auf mehreren Rechnern arbeitet verliert man schnell den Überblick.

Obwohl ich es nicht gerne mache - stelle ich fest, dass eine anständige txt Datei mit Beschreibung, was machst Du, wie denkst Du, und warummachst Du es so ... später sehr hilfreich ist, sich wieder einzudenken.

Gruß

Peter

Ich habe zumeist ein Chaos³ (gesprochen Chaos hoch drei).

Aber ich gelobe Besserung.

Ich glaube mit diesem Problem hatte bereits jeder zu kämpfen und hat da seine eigene Vorlieben entwickelt, mit denen er am besten zurecht kommt. Spannend wird das ganze, wenn mehrere Leute an einem Projekt arbeiten oder man Scripte anderer in Z.B Urlaubszeiten Supporten muss.

Da muss schon eine Lösung her mit denen die meisten zurecht kommen und leicht Verständlich und Umzusetzen ist.

Daher setzen wir komplett auf den MVC Pattern, dazu habe ich auch Tutorial erstellt, wie man diesen in Autoit umsetzten kann.

Anbei das Tutorial
http://4ern.de/autoit-mvc-pattern-tutorial/

Da hatte ich gerade heute noch die Diskussion, ob man Tabs benutzen sollte, oder Leerzeichen. Ich bin der Meinung, das Tabs sinnvoller sind, da man dann auch weniger tippen muss, wenn man zu viel Eingerückt hat,...
Wenn alle Tabs benutzen funktionierts ja auch ohne Probleme. Wie handhabt ihr das?

Was die Topic angeht: Ich programmiere, solange es keine großen Projekte sind, einfach drauf los. Funktionen und Variablen benenn ich dabei immer eindeutig (außer so temporäre). Dazu dann SciTe Jump, um die Funktionen schnell zu erreichen. Ich liebe Schleifen, etc. zum erstellen von Controls beispielsweise, ansonsten bin ich kein Freund von vielen Funktionen, gerade wenn die sehr klein sind, da ich die zur Übersicht nutze. Aber sobald ich etwas an mehr als 1-2 Stellen nutze pack ich es in eine Funktion. Woran ich noch arbeiten muss sind kommentare... Ich steig in meinem Code durch, wegen der eindeutigen benennung und weil ich mir sowas gut merken kann (auch nach 1 Jahr+), aber wenn es immer mehr werden mag das vielleicht schlechter werden

Zitat von Kanashius

heute noch die Diskussion, ob man Tabs benutzen sollte, oder Leerzeichen. Ich bin der Meinung, das Tabs sinnvoller sind, da man dann auch weniger tippen muss, wenn man zu viel Eingerückt hat,...Wenn alle Tabs benutzen funktionierts ja auch ohne Probleme. Wie handhabt ihr das?

Ich denke das sind aber eigene Vorlieben. Leerzeichen haben den Vorteil, dass das Script in Jeglichen Editoren und Websiten gleich aussieht...

Aber das erste was ich in Sublime mache wenn ich z.B eine UDF hole, ist das ganze markieren und dan 'convert to Tabs'

Wenn das Projekt überschaubar ist, fange ich meist einfach an. Mit der Zeit und der Erfahrung kommt da eine gewisse Routine rein. Ähnlich wie bereits einige male beschrieben, Includes, Optionen, GUI, Main Funktion restlichen Funktionen ist so ein Standard-Aufbau den ich nutze. Was ich häufig mache, weil es meist nicht kalkulierbar ist (für mich), dass ich an Stellen an denen ich merke hey, du könntest hier etwas anders machen, Sei es das auslagern in eine Funktion oder sowas, ich bearbeite den Code bei der Entwicklung mehrfach. Dauerhafte "Optimierung" würde ich das nennen. Wenn ein Programm erstmal läuft, gilt meist "Never change a running system".

Ich arbeite weniger mit dem auslagern in eigene Includes, da ich finde, das herumsuchen in X Dateien ist meist aufwendiger als alles in einem Skript zu haben. Das mag nun von Sprache zu Sprache anders sein, aber üblich nutze ich AutoIt nur für kleine bis "mittelgroße" Tools, und für alles größeres andere Sprachen. Je nach Art des Tools nutze ich in anderen Sprachen dann häufig eigene Bibliotheken. Sprich ich separiere dort auch. Da ich in AutoIt den Code einfach viel zu einfach zu verstehen finde, würde sich das für mich nicht lohnen. Wer AutoIt kann, sollte schnell mit einem Skript klarkommen, wo alles drinnen steht.

Durch die Zeit und Erfahrung mache ich dann kleine "remakes" immer wenn ich Tools bearbeiten muss wo es mehr als nur ein paar Zeilen sind. Ein Beispiel war eins meiner ersten AutoIt Tools. Es hatte fast 1500 Zeilen, das habe ich dann 2 Jahre später beim hinzufügen einer neuen Funktion umgebaut, hab letzten Endes nur rund 600 Zeilen gebraucht und dann einfach die neue Version unterteilt.

Ich denke einfach es gibt kein festes Vorgehen. Es gibt genügend theorien die du dir anschauen kannst, ich habe bisher jedoch nicht ein einziges mal solch eine Theorie komplett durchziehen können. Besonders meine Abschlussprüfung in der Ausbildung war ein Paradebeispiel. 40 Stunden Planung, und letzten Endes ist durch Zeitdruck daraus ein riesiges Chaos entstanden, dass man jetzt nur schwer wieder aufarbeiten kann.

Besser wird es mit jedem Projekt. Daher ist die Idee zu sagen ich Programmiere einfach mehrere kleine Tools, auch wenn ich die nicht brauche, einfach tun und versuchen den gleichen Stil im formatieren und kommentieren durchzuziehen. Wenn das bei mehreren Programmen in einer Größe von 500-800 Zeilen klappt, sollte danach nie wieder eine SChwierigkeit auftreten das auch weiterhin durchzuhalten.

Update: Das einzige was ich immer tue, Stift + Papier und alles mögliche notieren/skizzieren und versuchen weitestgehend alles zu planen, besonders kleine eigene Funktionen wie das loggen von Infos, oder eine ordentliche Fehlerbehandlung.

@Kanashius

Also Leerzeichen solang es weniger als fünf Stellen sind, danach setzt man ein Tab. So habe ich es gelernt und ich glaube ich schreibe an vielen Tagen mehr als jeder andere hier.
Meine beruflich und nicht "hier" im Forum.

Hallo,
ich verwende, für alle meine Scripte, immer die gleiche Struktur und trenne die einzelnen Blöcke mit einer Leerzeile voneinander.
Ausserdem spare ich nicht mit Kommentaren im Script, sodass ich auch nach einem Jahr noch einfach erkenne, was in diesem Programmschritt eigentlich passiert.
Zudem habe ich mir einige Funktionen geschrieben, die ich in fast jedem Script verwende damit ich bestimmte Zeilen nicht immer wieder wiederholen muss.
Funktionen, die nur in dem Script verwendet werden, schreibe ich

Hier mal ein Script von mir (Installationsscript für "Opera":
Install (Opera).au3

MfG:
BigRox

Zitat von Kanashius

Wenn alle Tabs benutzen funktionierts ja auch ohne Probleme. Wie handhabt ihr das?

kannst du dank dem hier getrost ad acta legen...

Zitat von Oscar

Meist füge ich auch Kommentare ein, damit ich später (nächstes Jahr) auch noch weiß, warum ich dieses oder jenes gemacht habe.

Meist........*rofl* ...ohne Kommentare wäre in einem seit 3-4 Jahren laufenden Script keinerlei sinnvolles Edit möglich!!

Zitat von Yaerox

Besser wird es mit jedem Projekt. Daher ist die Idee zu sagen ich Programmiere einfach mehrere kleine Tools, auch wenn ich die nicht brauche, einfach tun und versuchen den gleichen Stil im formatieren und kommentieren durchzuziehen. Wenn das bei mehreren Programmen in einer Größe von 500-800 Zeilen klappt, sollte danach nie wieder eine SChwierigkeit auftreten das auch weiterhin durchzuhalten.

Genau so funktioniert es!
Imho gibt es keine "Regeln" und da ist auch gut so! Jeder, der sich bspw. in größeren Firmen an bestimmte Vorgaben halten MUSS, hat mit Einschränkungen zu kämpfen und somit auch zwangsläufig mit Einschränkungen der Kreativität....wie sage ich immer so schön, wenn mich ein Mitarbeiter anstrahlt weil ich mich wieder mal über "Regeln" hinweggesetzt habe um Abläufe zu optimieren: "Separates the boys from the men!"
Dicke Eier bekommt man nicht, die HAT MAN!
Ich kannte begnadete Programmierer bei IBM (ist allerdings schon 20-30 Jahre her), die sind an ihrem eigenen System kaputtgegangen. Die waren dermaßen genial, da träumt Otto-Normalprogrammierer davon...aber leider wurden die vorgegebenen Einschränkungen zu ihrem Verhängnis....letztendlich sind sie zu Function-C&P-Deppen verkommen, weil "Kreativität und Individualität" in diesen Systemen völlig kontraproduktiv ist....
Systeme werden in den seltensten Fällen von Kreativen erstellt, sondern von Analytikern...wer mal mit diesen Leuten in Entscheider-Positionen zu tun hatte, dem wird der Abgrund an Kreativität offenbar!
Analytiker gehören an den Anfang eines Prozesses und nicht ans Ende!

Daher sollte jeder versuchen, sein eigenes "System" zu entwickeln! Inclusive des Maximums an Kreativität und Optimierung!
C&P-Deppen gibts genug da draußen, die sollten kein Maßstab sein.
Ich halte nicht viel von Hypes, aber in letzter Zeit hatte ich versucht, mittels "Agiler" Entwicklung zu arbeiten. Sehr motiviert angegangen, wurde ich schnell eines besseren belehrt...gute und kreative Umsetzungen (selbst wenn diese besser als die etablierten Verfahren funktionieren) werden strikt abgelehnt bzw. behindert!

Fortschritt ist die Aufgabe von Einzelnen, daher ist es an jedem, sich selbst an der Nase zu fassen und eigene Verfahren zur Verbesserung und Optimierung zu entwickeln!
Der Blick über den Tellerrand ist dabei unumgänglich und vor Betriebsblindheit ist NIEMAND gefeit!