Theo.Spengler
Anmeldungsdatum: 4. Januar 2019
Beiträge: 56
|
In meiner Lernkurve bei meinen Programmierversuchen mit Bash habe ich fest gestellt das es Grenzen hat einfach so vor sich hin zu programmieren. Scheinbar macht es Sinn sich vorher genauer klar zu machen, was so ein Programm genau alles machen soll. Vor vielen Jahren habe ich da mal was von Programmablaufplänen und so etwas wie einm Pflichtenheft gehört. Auch werde ich mir zunehmend mal an sehen, wie man Code modularisieren kann, in dem man bestimmte Teile in eigene Dateien oder später vlt. wenn ich das besser verstehe, vlt. auch in Funktionen auf teile. Gibt es da für Bash und Python gängige Hilfsmittel ? Womit erstellt ihr unter Linux z.B. eure Programmablaufpläne, mit Office Draw, Dia oder vlt. mit einer Organigrammsoftware ?
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12834
|
Theo.Spengler schrieb:
Gibt es da für Bash und Python gängige Hilfsmittel ? Womit erstellt ihr unter Linux z.B. eure Programmablaufpläne, mit Office Draw, Dia oder vlt. mit einer Organigrammsoftware ?
Whiteboards und Papier funktionieren ganz gut. In meiner Erfahrung lenken Programme als Werkzeuge eher ab und behindern einen. Die eignen sich besser für saubere Dokumentation, aber im kreativen Prozess braucht man möglichst wenig Hindernisse. UML funktioniert auch wunderbar auf Papier.
|
Theo.Spengler
(Themenstarter)
Anmeldungsdatum: 4. Januar 2019
Beiträge: 56
|
rklm schrieb: Whiteboards und Papier funktionieren ganz gut. In meiner Erfahrung lenken Programme als Werkzeuge eher ab und behindern einen.
Nehmen wir einmal an das man im Laufe der Zeit mehr als nur Dreizeiler, wie ich es bisher tue, an Code schreibt. Bieten sich dann andere Programme zur Codeerstellung an als ein Texteditor ? Mir sind da bisher Begriffe begegnet wie Codevervollständigung, Codeverwaltung und Debugging. Wenn es da für Bash und Python gängige Open Source Software für Linux gibt, würde ich mir die gerne mal im Laufe der Zeit an sehen. Verwendet ihr soetwas und wenn ja welche Software ?
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12834
|
Theo.Spengler schrieb:
Nehmen wir einmal an das man im Laufe der Zeit mehr als nur Dreizeiler, wie ich es bisher tue, an Code schreibt. Bieten sich dann andere Programme zur Codeerstellung an als ein Texteditor ?
Klar, da nimmt man am besten eine IDE mit guter Unterstützung der Programmiersprache, die man nutzt.
Mir sind da bisher Begriffe begegnet wie Codevervollständigung, Codeverwaltung und Debugging. Wenn es da für Bash und Python gängige Open Source Software für Linux gibt, würde ich mir die gerne mal im Laufe der Zeit an sehen. Verwendet ihr soetwas und wenn ja welche Software ?
Für die Shell kenne ich da nix. Wenn Du mehr als 200 Zeilen Shell-Skript hast, ist es sowieso vielleicht besser auf eine Programmiersprache zu wechseln. Für Python scheint PyCharm recht beliebt zu sein. Du kannst aber auch Eclipse mit PyDev oder Python in VSCode nutzen.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Also ich schreibe in der Bash sehr selten Programme, die aus mehr als einer Datei bestehen. Auch würde ich empfehlen umgekehrt vorzugehen: Erst Funktionen isolieren und später - wenn überhaupt - auf mehrere Dateien verteilen. Wie isoliert man eine Funktion? Spontan fallen mir 2 Gründe ein: Code, der sich an mehreren Stellen im Programm wiederholt, lagert man in eine Funktion aus und behandelt die Unterschiede mit Parametern, simples Beispiel: | #!/bin/bash
#
# ...
echo keine Maus gefunden
# ...
echo keine Tastatur gefunden
|
wird zu
| #!/bin/bash
#
device_not_found () {
device=$1
echo keine $device gefunden
}
# ...
device_not_found Maus
# ...
device_not_found Tastatur
|
In der Praxis sind die Beispiele meist nicht ganz so schlicht. Man riecht schon die Version 2 der Funktion:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 | #!/bin/bash
#
device_problem () {
device=$1
echo $device gefunden
}
# ...
device_problem "keine Maus"
# ...
device_problem "keine Tastatur"
# ...
device_problem "kein USB-Interface"
# ...
device_problem "keine Tastatur und keinen Lautsprecher"
# ...
device_problem "2 Bildschirme"
|
Muster 2 für Funktionsextraktion: Wenn Dein Code in Abschnitte aufgeteilt werden kann, die nach Kommentaren rufen und nur wenig Interferenzen mit dem restlichen Code haben.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26 | #!/bin/bash
#
# ...
#
# Setup
#
# ...
#
# Szenario 1
#
# ...
#
# Szenarioo 2
#
#
if (...)
then
szenario1
else
szenario2
fi
#
# cleanup
# ...
}
|
Wenig Interferenzen heißt, dass man wenige Parameter übergeben muss. Lokale Variablen sind nur in der Funktion bekannt, und erleichtern so das Verständnis des restlichen Codes, in dem sie unbekannt sind und deswegen außer Acht gelassen werden können. Zwei bis 20 Zeilen Code ist eine gute, grobe Faustregel für die Größe einer Funktion, solange man sich nicht sklavisch an die Regel hält. Nach Möglichkeit sollte sie eine Aufgabe lösen (die aber wieder in mehrere Teilaufgaben zerfallen kann). Ein weiterer Vorteil von Funktionen und Prozeduren ist, dass diese separat getestet werden können. Die Rückgabe von Ergebnissen ist in der Shell nur begrenzt möglich - sie ist auf Ganzzahlen eingeschränkt, so dass man häufig Prozeduren meint, wo man von Funktionen spricht. Ein Workaround ist oft, das Ergebnis auf stdout auszugeben und es im aufrufenden Kontext dann zu extrahieren.
Dann darf die Funktion aber keine weiteren Ausgaben nach stdout schreiben oder die Extraktion der Ergebnisse bläht den Code auf, was viele Vorteile von Funktionen (Übersichtlichkeit, leichte Testbarkeit) wieder zunichte macht.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Theo.Spengler schrieb: rklm schrieb: Whiteboards und Papier funktionieren ganz gut. In meiner Erfahrung lenken Programme als Werkzeuge eher ab und behindern einen.
Nehmen wir einmal an das man im Laufe der Zeit mehr als nur Dreizeiler, wie ich es bisher tue, an Code schreibt. Bieten sich dann andere Programme zur Codeerstellung an als ein Texteditor?
Nein. Manche Editoren bieten Codevervollständigung derart an, dass sie alle Zeichenketten über 3 Zeichen oder so in der offenen Datei zur Vervollständigung vorschlagen, ohne aber Funktion in der Syntax zu erkennen. Eine kl. Hilfe wenn man sehr lange Bezeichner benutzt, aber die Dauer des Tippens wird generell von Programmierern überschätzt.
Mir sind da bisher Begriffe begegnet wie Codevervollständigung, Codeverwaltung und Debugging. Wenn es da für Bash und Python gängige Open Source Software für Linux gibt, würde ich mir die gerne mal im Laufe der Zeit an sehen. Verwendet ihr soetwas und wenn ja welche Software ?
Für die Bash: Nein. Man kann seine Skripte mit Git verwalten - bestimmt bieten da auch Editoren wiederum Schnittstellen an. Debugging in der Shell mache ich fast immer mit "echo", aber meist nutze ich eh Scala, sobald es etwas aufwendiger und komplexer wird, aber auch da arbeite ich fast nie mit dem Debugger. Richtige Programmierer schreiben keine Bugs. ☺
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11181
Wohnort: München
|
Theo.Spengler schrieb: Scheinbar macht es Sinn sich vorher genauer klar zu machen, was so ein Programm genau alles machen soll. Vor vielen Jahren habe ich da mal was von Programmablaufplänen und so etwas wie einm Pflichtenheft gehört.
Es ist leider nicht immer so einfach vorab alles festzulegen, das hängt sehr von der eigenen Erfahrung, der Stabilität der Umgebungsbedingungen und den möglicherweise im Laufe des Entwicklungsprozess wechselnden Anforderungen an das Programm ab, ob ein Top-Down Design-Ansatz zum Erfolg führt - es gibt eine lange Liste von Softwareentwicklungsprozessen, die über die Jahrzehnte erdacht wurden, die sich je nach Projekt und Umständen besser oder schlechter eignen können. Gerade für die ersten eigenen Projekte macht es oft mehr Spaß, wenn man sich die Freiheit nimmt viel zu experimentieren und mehrere unterschiedliche Lösungsansätze für ein Problem zu vergleichen. Gibt es da für Bash und Python gängige Hilfsmittel ? Womit erstellt ihr unter Linux z.B. eure Programmablaufpläne, mit Office Draw, Dia oder vlt. mit einer Organigrammsoftware ?
Ich verzichte auf die händische Erstellung von Dokumentation zum Programmablauf wo es nur geht (für die Entwurfsphase kann das natürlich sinnvoll sein, das aufzuschreiben, aber ob man sich die Mühe macht das dann noch groß aufzubereiten, wenn das in Code gegossen wurde, muss man abwägen), da es zusätzliche Arbeit ist das aktuell zu halten - es kann praktisch sein, wenn die Dokumentation automatisch aus den Kommentaren im Quelltext erzeugt wird (geht z.B. mit Doxygen, das lohnt sich aber eher, wenn man APIs anbietet, die Dritte nutzen sollen) und generell sollte der Code so klar strukturiert sein, dass man den Ablauf daraus leicht ersehen kann, ohne da zusätzliche Dokumente zu benötigen. Mit gezielt eingesetzten Kommentaren kann man dem Leser dann noch vermitteln, was bestimmte Methoden tun (wenn es komplexer ist), warum bestimmte Dinge so implementiert wurden und was der Code im großen und ganzen tun soll. Man sollte es vermeiden unnötigerweise trivialen Code zu kommentieren, wenn der geneigte Leser anhand des Codes leicht nachvollziehen kann, was da passiert - gut gewählte Variablen- und Methodennamen helfen da oft enorm. Theo.Spengler schrieb: Nehmen wir einmal an das man im Laufe der Zeit mehr als nur Dreizeiler, wie ich es bisher tue, an Code schreibt. Bieten sich dann andere Programme zur Codeerstellung an als ein Texteditor ?
Texteditor ist ein weiter Begriff, das fängt mit einfachen Programmen wie ed an und hört bei umfangreich erweiterbaren Programmen wie (neo)vim, Emacs und VS Code auf, die dann schon nahe an der Funktionalität einer ausgewachsenen IDE dran sein können.
Mir sind da bisher Begriffe begegnet wie Codevervollständigung, Codeverwaltung und Debugging.
Nicht zu vergessen statische Code-Analyse/Linting (für die Bash gibt es shellcheck, für Python u.a. pylint und mypy), die einem viel Frust durch die Markierung von Syntax-Fehlern und gängigen Stolperfallen ersparen können und Tools wie black, die einem durch eine automatische einheitliche Formatierung des Quellcode das Leben leichter machen können. Wenn es da für Bash und Python gängige Open Source Software für Linux gibt, würde ich mir die gerne mal im Laufe der Zeit an sehen. Verwendet ihr soetwas und wenn ja welche Software ?
git hat sich für meine Anforderungen als Versionsverwaltungssystem bewährt. Für kleine Sachen nehme ich vim, für größere Dinge Emacs (weil org-mode super dafür ist den Verlauf der Entwicklung und TODOs zu dokumentieren, magit ein prima Interface für git ist und die Bedienung mit dem evil-mode weitestgehend wie in vim funktioniert)
oder VS Code (mag ich für die Webentwicklung lieber als Emacs). user_unknown schrieb: Richtige Programmierer schreiben keine Bugs. ☺
Richtige Programmierer nutzen auch Schmetterlinge zum Programmieren: https://xkcd.com/378/ 😉
|
Dakuan
Anmeldungsdatum: 2. November 2004
Beiträge: 6346
Wohnort: Hamburg
|
Es ist leider nicht immer so einfach vorab alles festzulegen, ...
Das kenne ich auch. So etwas sollte man nur machen, wenn man genau weiß was man will. Im Profi Bereich ist das aber Standard. Im Hobbybereich ist das aber eher hinderlich, besonders wenn man noch nicht genau weiß wohin die Reise geht. Ich habe da festgestellt, das ich da mehrfach nach regulieren musste. Das passiert oft, wenn man in eine Materie neu einsteigt.
Ich verzichte auf die händische Erstellung von Dokumentation zum Programmablauf wo es nur geht (für die Entwurfsphase kann das natürlich sinnvoll sein, das aufzuschreiben, aber ob man sich die Mühe macht das dann noch groß aufzubereiten, wenn das in Code gegossen wurde, muss man abwägen), ...
Programmierer und Dokumentation - eine unendliche Geschichte. Ich bin da auch sehr nachlässig (als Amateur darf ich das). Aber manchmal geht es nicht ohne. In komplizierten Fällen greife ich dann auch mal auf Papier und Bleistift zurück. Hier mal ein eingescanntes Beispiel zu einem Undo/Redo Mechanismus mittels Ringpuffer (normal ist Stack). Ohne dieses Bild kann ich nach einiger Zeit meinen eigenen Programmcode nicht mehr nachvollziehen. Ich habe schon gesehen, dass solche Bilder als ASCII-Art in den Programmcode eingebunden wurden, aber das geht leider nicht immer z.B. wenn die Darstellung zu komplex ist.
- Bilder
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11181
Wohnort: München
|
Dakuan schrieb: Ich habe schon gesehen, dass solche Bilder als ASCII-Art in den Programmcode eingebunden wurden, aber das geht leider nicht immer z.B. wenn die Darstellung zu komplex ist.
Mit ditaa kann man sowas in ASCII umsetzen und bei Bedarf als hübschere Grafik exportieren lassen. Emacs hat mit dem artist-mode sogar eine recht brauchbare Methode, um ASCII-Diagramme zu zeichnen. Für komplexere Diagramme kann man auch Tools wie graphviz oder https://plantuml.com/de/ nutzen, gerade im Zusammenspiel mit dem Emacs org-mode ist das praktisch, weil sich der Quelltext für die Diagramme als Code-Block in einem org-mode Dokument einbinden lässt (Beispiele: http://doc.norang.ca/org-mode.html#OrgBabel) und daraus kann über org-babel bei Bedarf eine Bilddatei gerendert und diese kann dann von Emacs im Buffer dargestellt und in aus der org-mode Datei exportierte Dokumente (z.B. PDF oder HTML) eingebunden werden. Dakuan schrieb: Programmierer und Dokumentation - eine unendliche Geschichte. Ich bin da auch sehr nachlässig (als Amateur darf ich das). Aber manchmal geht es nicht ohne.
Ich habe ablsolut nichts gegen eine gute Dokumentation, aber ich sehe normalerweise wenig Sinn darin Programmablaufpläne für das komplette Programm hinterlegen, da sich das bei Hochsprachen normalerweise genauso gut aus dem Code herauslesen lässt - da finde ich die Probleme, die entstehen, wenn die Dokumentation nicht mehr zum Code passt viel nerviger. Für komplexe Stellen ist das natürlich sinnvoll genauer zu beschreiben, was da passiert, wobei da oft das warum und ein grober Überblick über den Gesamtzusammenhang mehr wert ist als eine kleinschrittige Auflistung, die vom eigentlichen Code ablenkt.
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29067
Wohnort: WW
|
Hallo,
Scheinbar macht es Sinn sich vorher genauer klar zu machen, was so ein Programm genau alles machen soll. Vor vielen Jahren habe ich da mal was von Programmablaufplänen und so etwas wie einm Pflichtenheft gehört.
Sagen wir mal so: das ist im gewerblichen Bereich sicherlich Standard, privat halte ich das für übertrieben. Ich bin ja auch "nur" Hobbyprogrammierer, aber mir reicht es, wenn ich mir überlege, was mein Prog können soll. Dann fange ich an zu programmieren und in der Regel kommt was strukturiertes dabei raus. Was a) sicherlich Übungssache ist und b) davon abhängt, wie strukturiert man arbeiten kann. Letzteres kann ja nicht jeder (ganz wertfrei gemeint). Wenn man das halt nicht kann, dann macht es mehr Sinn, sich vorher was aufzuschreiben / auf zu malen. Zum Programmieren benutze ich, auch für meine mittelgroßen Python / Django Projekte, einfach gedit. Klar kann man eine IDE oder so nehmen, aber damit programmierst du auf keinen Fall per se besser. Man macht vielleicht weniger Flüchtigkeitsfehler wie schließende Klammer vergessen oder so. Aber wenn du z.B. bei Python die Objektorientierung nicht verstanden hast oder nur einen Bruchteil der Module aus der Standardbibliothek kennst oder weißt, wie toll das ìtertools-Modul ist, dann nützt die eine IDE auch nichts. Bei Hobbyprogrammieren halte ich es zum Lernen immer noch für am effektivsten, wenn man seinen Code in einem Fachforum (bei Python www.python-forum.de) postet, sich die Kritik abholt und es beim nächsten Mal besser macht. Gruß, noisefloor
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12834
|
seahawk1986 schrieb:
Für komplexe Stellen ist das natürlich sinnvoll genauer zu beschreiben, was da passiert, wobei da oft das warum und ein grober Überblick über den Gesamtzusammenhang mehr wert ist als eine kleinschrittige Auflistung, die vom eigentlichen Code ablenkt.
Unbedingte Zustimmung: man sollte Mensch und Maschine das machen lassen, was sie jeweils gut können. Überblick und Zusammenhang darstellen ist auf jeden Fall etwas für Humanoide. Je nachdem, sind auch API-Spezifikationen etwas, das man den Menschen machen lassen möchte - als Vorlage, gegen die die API implementiert werden soll. Man kann die aber oft auch gut generieren; das hängt halt von der Technologie ab.
|
Dakuan
Anmeldungsdatum: 2. November 2004
Beiträge: 6346
Wohnort: Hamburg
|
Hier noch ein Nachtrag zu meinem vorigen Beitrag, wo ich erwähnt hatte, dass ich schon ASCII-Art im Programm Quelltext gesehen hatte:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33 | /*
...
* There is a complete symbol waveform in syncbuf, so that each
* sample[0..N/2-1] is very close in amplitude with the corresponding
* sample in [N/2..N-1].
*
* | ******** ******** |
* | **** **** **** **** |
* | *** *** *** *** |
* | ** ** ** ** |
* | * * * * |
* | * * * * |
* |* * *|
* |_______________________________________________________________|
* 0 N/2 N-1
*
* === or some variation of it .... ===
*
* |**** ******** *****|
* | **** **** **** **** |
* | *** *** *** *** |
* | ** ** ** ** |
* | * * * * |
* | * * * * |
* | * * |
* |_______________________________________________________________|
* 0 N/2 N-1
*
* At the end of this cycle, bitclk is pointing at a sample which will
* have the maximum phase difference, if any, from the previous symbol's
* phase.
*
*/
|
Das ist ein Auszug aus dem Programm fldigi (Modul: psk.cxx). @seahawk1986 Ich werde mir mal ansehen wieweit das auf meine Probleme anwendbar ist. Auf meine bereits gepostete Skizze ist das aber wohl nicht so einfach anwendbar, hauptsächlich wegen der begrenzten Breite meines Monitors. Ich habe meinen Monitor auf 1280 Pixel Breite begrenzt, da mir sonst die Schrift, trotz Brille, zu klein ist.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11181
Wohnort: München
|
Dakuan schrieb: @seahawk1986 Ich werde mir mal ansehen wieweit das auf meine Probleme anwendbar ist. Auf meine bereits gepostete Skizze ist das aber wohl nicht so einfach anwendbar, hauptsächlich wegen der begrenzten Breite meines Monitors. Ich habe meinen Monitor auf 1280 Pixel Breite begrenzt, da mir sonst die Schrift, trotz Brille, zu klein ist.
Eventuell lohnt es sich doch mal eine HiDPI-fähige Desktop-Umgebung und dafür ausgelegte Toolkits zu nutzen. Inhalte skalieren zu lassen statt die Auflösung künstlich zu beschränken sieht meistens deutlich besser aus. Ansonten hilft auch ein größerer Bildschirm ...
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
rklm schrieb: Theo.Spengler schrieb:
Gibt es da für Bash und Python gängige Hilfsmittel ? Womit erstellt ihr unter Linux z.B. eure Programmablaufpläne, mit Office Draw, Dia oder vlt. mit einer Organigrammsoftware ?
Whiteboards und Papier funktionieren ganz gut…
seahawk1986 schrieb: Für kleine Sachen nehme ich vim, für größere Dinge Emacs (weil org-mode super dafür ist…
Genau so mache ich das mittlerweile auch. Zunächst wird die Projektidee skizziert (Papier oder Tablet ist egal, Hauptsache "frei zeichnen"). Dort lege ich quasi die "Bausteine" an. Jeder Baustein wird dann ein TODO-Eintrag im Emacs, der kann auch TODO-Unterlisten und Abhängigkeiten 🇬🇧 einfach abbilden, zudem verfügt besagter org-mode auch über die Möglichkeit, seine Zeiten ordentlich zu planen (und zu tracken). Die Einarbeitungskurve ist dafür aber extrem hoch. Es gibt aber einige fertige Vorlagen/Konfigurationen - sowohl für Emacs selbst, als auch für org-mode. Wenn man sich mit denen anfreunden kann, braucht man die Klammer-Tasten nicht überzustrapazieren ☺ Bei Ubuntu muss man ein wenig aufpassen, welchen Emacs man erwischt. Ich empfehle die apt-Version (aktuell 26.3 im Kubuntu 20.04) und für Zusatzpakete das integrierte ELPA. Alternativ dazu könntest du auch für Python den Qt Creator und PyQT5 verwenden und die Dokumentation über Doxygen machen, falls du weniger auf Textdateien und mehr auf grafische Helfer setzt.
|