Hallo,
seit zwei Jahren pflege ich meine Programming-Guidelines, damit ich mich selbst bessere daran halte :-)
Falls es jemanden interessiert:
https://github.com/guettli/programming-guidelines
Feedback ist willkommen.
Gruß, Thomas
Thomas Güttler schrieb am 24.10.19 um 09:56:
seit zwei Jahren pflege ich meine Programming-Guidelines, damit ich mich selbst bessere daran halte :-)
Das ist ja ein ganz schön ausführliches Dokument geworden. Ich stimme nicht mit allen Punkten überein, die du genannt hast. Vermutlich, weil es auch Geschmackssache ist.
Das Buch "Code Complete" hat ähnliche Listen, ist deutlich umfangreicher und reichhaltig mit Studien belegt. Vielleicht magst du auch da mal einen Blick hinein werfen.
https://en.wikipedia.org/wiki/Code_Complete
Beste Grüße, der Marco.
Am 24.10.19 um 15:25 schrieb Marco Bakera:
Thomas Güttler schrieb am 24.10.19 um 09:56:
seit zwei Jahren pflege ich meine Programming-Guidelines, damit ich mich selbst bessere daran halte :-)
Das ist ja ein ganz schön ausführliches Dokument geworden. Ich stimme nicht mit allen Punkten überein, die du genannt hast. Vermutlich, weil es auch Geschmackssache ist.
Schön. Vielleicht kann ich ja noch etwas dazu lernen.
Bisher ist deine Aussage etwas zu abstrakt für mich.
Ich würde mich sehr über konkretes Feedback freuen.
Hier auf der Liste, per github issue oder lieber direkter Mail an mich. Wie es dir lieber ist. Das wäre sehr nett.
Das Buch "Code Complete" hat ähnliche Listen, ist deutlich umfangreicher und reichhaltig mit Studien belegt. Vielleicht magst du auch da mal einen Blick hinein werfen.
Danke für den Hinweis. Ich schaue es mir an!
Gruß, Thomas
Thomas Güttler schrieb am 25.10.19 um 08:24:
Schön. Vielleicht kann ich ja noch etwas dazu lernen.
Bisher ist deine Aussage etwas zu abstrakt für mich.
Ich würde mich sehr über konkretes Feedback freuen.
Ich finde etwa den Punkt "Avoid the GPL" sehr meinungsbelastet und zu knapp begründet.
In eine ähnliche Kategorie fällt der folgende Punkt:
"I don't say that SQL is always the best solution. Of course http based APIs are better in general."
Der Punkt "Version Control" ist sehr knapp, enthält nur eine Meinung und beleuchtet auch nur den Platzhirsch git.
Ansonsten habe ich den Eindruck, dass sich viele der Gedanken aus einer speziellen Sicht speisen. Zum Beispiel könnten einige der Argumente im Kontext von Embedded-Systemen wieder ganz anders ausfallen.
Irgendwo in der Mitte habe ich abgebrochen. Das Dokument könnte in Abschnitt 3 etwas Struktur vertragen.
Gut hat mir dein Gedanke gefallen, CRUD auf CRD zu reduzieren und U durch DC zu ersetzen.
Auch der Abschnitt "Love your docs" hat mir gut gefallen.
Ich hoffe, du kannst mit meiner Meinung etwas anfangen.
Das Buch "Code Complete" hat ähnliche Listen, ist deutlich umfangreicher und reichhaltig mit Studien belegt. Vielleicht magst du auch da mal einen Blick hinein werfen.
Danke für den Hinweis. Ich schaue es mir an!
Alleine das Inhaltsverzeichnis ist schon einen Blick wert. Ich war mir gar nicht bewusst, auf wie vielen Ebenen man Quelltext betrachten kann und wie viel Forschung bereits dazu existiert.
Beste Grüße, der Marco.
Am 25.10.19 um 09:49 schrieb Marco Bakera:
Der Punkt "Version Control" ist sehr knapp, enthält nur eine Meinung und beleuchtet auch nur den Platzhirsch git.
Ich sehe keine etablierte Alternative zu git. Am Stackoverflow Tag-Trend sieht man sehr gut was genutzt wird, und was nicht:
http://sotagtrends.com/?tags=%5Bgit,mercurial,bazaar,svn%5D
Welche Alternative zu git siehst du?
Gruß, Thomas
Thomas Güttler schrieb am 28.10.19 um 08:35:
Am 25.10.19 um 09:49 schrieb Marco Bakera:
Der Punkt "Version Control" ist sehr knapp, enthält nur eine Meinung und beleuchtet auch nur den Platzhirsch git.
Ich sehe keine etablierte Alternative zu git. Am Stackoverflow Tag-Trend sieht man sehr gut was genutzt wird, und was nicht:
http://sotagtrends.com/?tags=%5Bgit,mercurial,bazaar,svn%5D
Welche Alternative zu git siehst du?
Bei Wikipedia wird eine Reihe von Beispielen gelistet und kategorisiert. Da könnte man mal anfangen. Sicher gibt es noch weitere Systeme - mir würde etwa noch das Image-basierte Versionieren in Smalltalk einfallen.
https://de.wikipedia.org/wiki/Versionsverwaltung#Beispiele
Beste Grüße, der Marco.
On 2019-10-28 08:35, Thomas Güttler wrote:
Am 25.10.19 um 09:49 schrieb Marco Bakera:
Der Punkt "Version Control" ist sehr knapp, enthält nur eine Meinung und beleuchtet auch nur den Platzhirsch git.
Ich sehe keine etablierte Alternative zu git. Am Stackoverflow Tag-Trend sieht man sehr gut was genutzt wird, und was nicht:
Wenn ich ein Werkzeug wähle, dann nicht nur aufgrund der Verbreitung. :-)
Ich selbst bevorzuge Mercurial, weil es einfacher ist. Dadurch kann ich entspannter arbeiten. Ich brauche bei Mercurial weniger "Brain Cycles", obwohl ich mich mit Git und Mercurial ungefähr gleich gut auskenne. Für mich entspricht die Verwendung von Mercurial dem von dir gelobten "Keep it simple."
Ich denke, es hängt vom Kontext ab, welches Versionskontrollsystem man einsetzt. Die Verbreitung ist nur ein Teil des Kontexts.
Davon abgesehen, ist "Verbreitung" aus meiner Sicht auch kein "Wert an sich." Interessanter ist, welche Gründe die geringere Verbreitung hat und welche Nachteile daraus entstehen könnten. Ich habe mir die Situation für Mercurial angesehen und es sieht nicht so aus, als müsse ich mir über die geringere Verbreitung Sorgen machen. :-)
Viele Grüße Stefan
Am 28.10.19 um 18:59 schrieb Stefan Schwarzer:
Ich selbst bevorzuge Mercurial, weil es einfacher ist. Dadurch kann ich entspannter arbeiten. Ich brauche bei Mercurial weniger "Brain Cycles", obwohl ich mich mit Git und Mercurial ungefähr gleich gut auskenne. Für mich entspricht die Verwendung von Mercurial dem von dir gelobten "Keep it simple."
Ich habe auch lange mercurial benutzt. Aber "git rebase -i" und "git gui " sind für mich eine Killer-Funktion. Das benutze ich oft, um einen Haufen unordentlicher Commits aufzuräumen, damit nicht 20 Mini-Changes da sind, die nichts zum Verständnis der Änderung beitragen.
Kann mercurial sowas?
On 2019-10-29 10:12, Hartmut Goebel wrote:
Am 28.10.19 um 18:59 schrieb Stefan Schwarzer:
Ich selbst bevorzuge Mercurial, weil es einfacher ist. Dadurch kann ich entspannter arbeiten. Ich brauche bei Mercurial weniger "Brain Cycles", obwohl ich mich mit Git und Mercurial ungefähr gleich gut auskenne. Für mich entspricht die Verwendung von Mercurial dem von dir gelobten "Keep it simple."
Ich habe auch lange mercurial benutzt. Aber "git rebase -i" und "git gui " sind für mich eine Killer-Funktion. Das benutze ich oft, um einen Haufen unordentlicher Commits aufzuräumen, damit nicht 20 Mini-Changes da sind, die nichts zum Verständnis der Änderung beitragen.
Kann mercurial sowas?
Eine Entsprechung von `git rebase -i` ist `hg histedit`. Das gibt es auch schon lange und ich benutze das auch gerne hin und wieder. https://www.mercurial-scm.org/wiki/HisteditExtension
Wenn ich die Manpage zu `git gui` richtig interpretiere, könnte das hier etwas entsprechendes für Mercurial sein: https://www.logilab.org/project/hgview
Daneben gibt es natürlich auch noch `hg serve`, das ein Web-Interface zum Browsen des Repositorys anbietet. Das sieht etwa so aus: https://hg.sschwarzer.net/ftputil
Nach Ausführen von `hg serve` kann man auch das entsprechende Repository per http klonen oder "pullen", womit man einem Kollegen auf einem anderen Rechner mal schnell die Änderungen in einem eigenen lokalen Repository anbieten kann.
Viele Grüße Stefan
Am 29.10.19 um 11:27 schrieb Stefan Schwarzer:
Wenn ich die Manpage zu `git gui` richtig interpretiere, könnte das hier etwas entsprechendes für Mercurial sein: https://www.logilab.org/project/hgview
hgview scheint mir eher "gitk" zu entsprechen: Man kann die Log-Historie ansehen und durchsuchen, die Diffs ansehen (und durchsuchen), etc.
"git gui" hat eher den Fokus auf dem Erstellen von commits, push zum Repository, etc. Aber für mich der wichtigste Punkt ist, dass man einzelnen Zeilen zum Änderungssatz hinzufügen oder herausnehmen kann. Damit kann ich, nachdem ich eine Änderung entwickelt habe, schöne Commit daraus erstellen, insb. nicht zusammengehörendes in unterschiedliche Commits packen.
On 2019-10-29 13:47, Hartmut Goebel wrote:
Am 29.10.19 um 11:27 schrieb Stefan Schwarzer:
Wenn ich die Manpage zu `git gui` richtig interpretiere, könnte das hier etwas entsprechendes für Mercurial sein: https://www.logilab.org/project/hgview
hgview scheint mir eher "gitk" zu entsprechen: Man kann die Log-Historie ansehen und durchsuchen, die Diffs ansehen (und durchsuchen), etc.
"git gui" hat eher den Fokus auf dem Erstellen von commits, push zum Repository, etc. Aber für mich der wichtigste Punkt ist, dass man einzelnen Zeilen zum Änderungssatz hinzufügen oder herausnehmen kann. Damit kann ich, nachdem ich eine Änderung entwickelt habe, schöne Commit daraus erstellen, insb. nicht zusammengehörendes in unterschiedliche Commits packen.
Ach so, das geht mit `hg ci -i <dateien>` (`-i` steht für "interactive"). Ich hoffe jedenfalls, dass das ist, was du meinst.
Das kannst du sowohl wie bei `git ci -p` mit Abfragen haben als auch mit einer Curses-Schnittstelle. Siehe auch https://stackoverflow.com/a/37376024/8854750 .
Viele Grüße Stefan
Am 28.10.19 um 18:59 schrieb Stefan Schwarzer:
On 2019-10-28 08:35, Thomas Güttler wrote:
Am 25.10.19 um 09:49 schrieb Marco Bakera:
Der Punkt "Version Control" ist sehr knapp, enthält nur eine Meinung und beleuchtet auch nur den Platzhirsch git.
Ich sehe keine etablierte Alternative zu git. Am Stackoverflow Tag-Trend sieht man sehr gut was genutzt wird, und was nicht:
Wenn ich ein Werkzeug wähle, dann nicht nur aufgrund der Verbreitung. :-)
Ich schon. Ich bin ein Herdentier. Dort wo keine anderen sind, dort ist auch keine Entwicklung und man steht allein da, wenn man Fragen hat. Sicherlich, wenn es gute Gründe gibt, dann lohnt es sich einen anderen Weg einzuschlagen.
Ich selbst bevorzuge Mercurial, weil es einfacher ist. Dadurch kann ich entspannter arbeiten. Ich brauche bei Mercurial weniger "Brain Cycles", obwohl ich mich mit Git und Mercurial ungefähr gleich gut auskenne. Für mich entspricht die Verwendung von Mercurial dem von dir gelobten "Keep it simple."
Ich denke, es hängt vom Kontext ab, welches Versionskontrollsystem man einsetzt. Die Verbreitung ist nur ein Teil des Kontexts.
Davon abgesehen, ist "Verbreitung" aus meiner Sicht auch kein "Wert an sich." Interessanter ist, welche Gründe die geringere Verbreitung hat und welche Nachteile daraus entstehen könnten. Ich habe mir die Situation für Mercurial angesehen und es sieht nicht so aus, als müsse ich mir über die geringere Verbreitung Sorgen machen. :-)
Viele Grüße Stefan _______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
On 2019-10-29 10:23, Thomas Güttler wrote:
Am 28.10.19 um 18:59 schrieb Stefan Schwarzer:
Wenn ich ein Werkzeug wähle, dann nicht nur aufgrund der Verbreitung. :-)
Ich schon. Ich bin ein Herdentier. Dort wo keine anderen sind, dort ist auch keine Entwicklung und man steht allein da, wenn man Fragen hat. Sicherlich, wenn es gute Gründe gibt, dann lohnt es sich einen anderen Weg einzuschlagen.
In Bezug auf die "mangelnde Verbreitung" hatte ich zeitweilig ähnliche Bedenken, aber habe bei meiner Recherche gelernt, dass die Nachteile, die man mit "mangelnder Verbreitung" normalerweise verbindet, nicht gegeben sein müssen:
Das Mercurial-Projekt veröffentlicht regelmäßig neue Releases mit neuen Features (nicht nur Bugfixes). https://www.mercurial-scm.org/wiki/
Facebook und Mozilla setzen viel Mercurial ein. Viele Erweiterungen (oder deren Vorläufer) in Mercurial stammen von Facebook. Daneben weiß ich auch von Leuten, bei denen Mercurial als Standard-VCS am Arbeitsplatz verwendet wird.
Zu Fragen kann man sich an die Mercurial-Mailingliste wenden: https://www.mercurial-scm.org/wiki/MailingLists#The_Mercurial_list
Bei Mercurial gibt es auch sehr interessante Entwicklungen, zum Beispiel https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-changes-in-mercuri... https://www.mercurial-scm.org/doc/evolution/user-guide.html
Nach meinen Recherchen dachte ich mir, dass ich mir wohl erst mal keine Sorgen um das baldige Ableben von Mercurial machen muss. ;-) Und notfalls kann ich meine Mercurial-Repositorys später immer noch mit wenig Aufwand auf Git migrieren.
Ich selbst bevorzuge Mercurial, weil es einfacher ist. Dadurch kann ich entspannter arbeiten. Ich brauche bei Mercurial weniger [...]
Lösch doch bitte die Abschnitte, auf die du gar nicht antwortest. :-) Dann muss man nicht nutzlos bis zum Ende der Mail scrollen, um zu sehen, dass da nichts mehr kommt.
Viele Grüße Stefan
Hallo Marco,
danke für den Feedback.
Am 25.10.19 um 09:49 schrieb Marco Bakera:
Thomas Güttler schrieb am 25.10.19 um 08:24:
Schön. Vielleicht kann ich ja noch etwas dazu lernen.
Bisher ist deine Aussage etwas zu abstrakt für mich.
Ich würde mich sehr über konkretes Feedback freuen.
Ich finde etwa den Punkt "Avoid the GPL" sehr meinungsbelastet und zu knapp begründet.
Ja, das ist meinungsbelastet. Mittels open source software entwickle ich kommerzielle closed source software für meinen Arbeitgeber. Das hat den Vorteil, dass ich einen spannenden Job habe, und dass immer mal wieder dabei open source Tools von mir etwas verbessert werden. Sicherlich ist das ein Verhältnis von 95% zu 5%. Also hauptsächlich wird das eigene Produkt verbessert. Da passt die GPL nicht rein. Danke für den Hinweis. Das werde ich ergänzen.
Gruß, Thomas
Am 28.10.19 um 08:44 schrieb Thomas Güttler:
Ja, das ist meinungsbelastet.
Ja, sehr :-)
Mittels open source software entwickle ich kommerzielle closed source software für meinen Arbeitgeber. Das hat den Vorteil, dass ich einen spannenden Job habe, und dass immer mal wieder dabei open source Tools von mir etwas verbessert werden. Sicherlich ist das ein Verhältnis von 95% zu 5%. Also hauptsächlich wird das eigene Produkt verbessert. Da passt die GPL nicht rein. Danke für den Hinweis. Das werde ich ergänzen.
Ich stehe auf der anderen Seite und entwickle in meiner Freizeit Open Source Software. In der Regel zahlen die Firmen, die mit meiner Software Profil machen, mir dafür keinen Pfennig, siehe auch https://github.com/pyinstaller/pyinstaller/issues/4404. Darum nehme ich nur GPL oder AGPL, denn die Software soll dann wenigstens frei ein. (Prüfen kann ich das eh nicht.)
Am 29.10.19 um 10:11 schrieb Hartmut Goebel:
Am 28.10.19 um 08:44 schrieb Thomas Güttler:
Ja, das ist meinungsbelastet.
Ja, sehr :-)
Mittels open source software entwickle ich kommerzielle closed source software für meinen Arbeitgeber. Das hat den Vorteil, dass ich einen spannenden Job habe, und dass immer mal wieder dabei open source Tools von mir etwas verbessert werden. Sicherlich ist das ein Verhältnis von 95% zu 5%. Also hauptsächlich wird das eigene Produkt verbessert. Da passt die GPL nicht rein. Danke für den Hinweis. Das werde ich ergänzen.
Ich stehe auf der anderen Seite und entwickle in meiner Freizeit Open Source Software. In der Regel zahlen die Firmen, die mit meiner Software Profil machen, mir dafür keinen Pfennig, siehe auch https://github.com/pyinstaller/pyinstaller/issues/4404. Darum nehme ich nur GPL oder AGPL, denn die Software soll dann wenigstens frei ein. (Prüfen kann ich das eh nicht.)
Es ist natürlich sehr wahrscheinlich, dass GPL/AGPL Software deutlich weniger Nutzer hat. Genau aus diesem Grund. Man will sich ja keinen Virus einfangen.
Hätten Python, PostgreSQL oder Django eine GPL Lizenz, dann würde ich es nicht verwenden.
Gruß, Thomas
Am 29.10.19 um 10:26 schrieb Thomas Güttler:
Es ist natürlich sehr wahrscheinlich, dass GPL/AGPL Software deutlich weniger Nutzer hat.
Auf was stützt Du diese Behauptung?
Genau aus diesem Grund. Man will sich ja keinen Virus einfangen.
Was hat das eine mit dem anderen zu tun?
Verbreitest u
Am 29.10.19 um 10:52 schrieb Hartmut Goebel:
Am 29.10.19 um 10:26 schrieb Thomas Güttler:
Es ist natürlich sehr wahrscheinlich, dass GPL/AGPL Software deutlich weniger Nutzer hat.
Auf was stützt Du diese Behauptung?
Bisher war das eine Vermutung. Wenn ich mir jetzt die github Repos mit den meistenn Sternchen anschaue, dann sehe ich dort hauptsächlich MIT und BSD artige Lizenzen. Keins mit GPL/AGPL.
Welche GPL/AGPL Projekte sind aus deiner Sicht häufig im Einsatz (außer dem Kernel)?
Thomas Güttler schrieb am 29.10.19 um 14:29:
Am 29.10.19 um 10:52 schrieb Hartmut Goebel:
Am 29.10.19 um 10:26 schrieb Thomas Güttler:
Es ist natürlich sehr wahrscheinlich, dass GPL/AGPL Software deutlich weniger Nutzer hat.
Auf was stützt Du diese Behauptung?
Bisher war das eine Vermutung. Wenn ich mir jetzt die github Repos mit den meistenn Sternchen anschaue, dann sehe ich dort hauptsächlich MIT und BSD artige Lizenzen. Keins mit GPL/AGPL.
Welche GPL/AGPL Projekte sind aus deiner Sicht häufig im Einsatz (außer dem Kernel)?
Hier gibt es eine Liste mit Gnu-Projekten - vermutlich viele unter der GPL.
Ein paar prominentere Projekte: grep, emacs, gimp, gv, gzip.
Vielleicht ist github nicht die beliebteste Repoquelle für GPL-Projekte?!
Beste Grüße, der Marco.
On 2019-10-30 16:21, Marco Bakera wrote:
Am 29.10.19 um 10:52 schrieb Hartmut Goebel:
Am 29.10.19 um 10:26 schrieb Thomas Güttler:
Es ist natürlich sehr wahrscheinlich, dass GPL/AGPL Software deutlich weniger Nutzer hat.
Auf was stützt Du diese Behauptung?
Bisher war das eine Vermutung. Wenn ich mir jetzt die github Repos mit den meistenn Sternchen anschaue, dann sehe ich dort hauptsächlich MIT und BSD artige Lizenzen. Keins mit GPL/AGPL.
Welche GPL/AGPL Projekte sind aus deiner Sicht häufig im Einsatz (außer dem Kernel)?
Hier gibt es eine Liste mit Gnu-Projekten - vermutlich viele unter der GPL.
Ein paar prominentere Projekte: grep, emacs, gimp, gv, gzip.
Siehe auch https://en.wikipedia.org/wiki/Category:Software_using_the_GPL_license , worunter sich einige bekannte Namen finden:
AbiWord Audacity Drupal Geany Gedit Git GCC Jedit Joomla Konqueror MariaDB MoinMoin MySQL
Weitere Beispiele (nach meiner Recherche):
Bash Calibre FFMPEG Ghostscript Gnome Grub (Linux-Bootmanager) Inkscape Linux Kernel Mailman Mercurial NetworkManager VirtualBox (die Open-Source-Teile) VLC wget
Vielleicht ist github nicht die beliebteste Repoquelle für GPL-Projekte?!
Denke ich auch.
Viele Grüße Stefan
Noch ein paar die mir so einfallen
Sharelatex Blender MoinMoin GR Framework
Stefan Schwarzer sschwarzer@sschwarzer.net schrieb am Mi., 30. Okt. 2019, 20:42:
On 2019-10-30 16:21, Marco Bakera wrote:
Am 29.10.19 um 10:52 schrieb Hartmut Goebel:
Am 29.10.19 um 10:26 schrieb Thomas Güttler:
Es ist natürlich sehr wahrscheinlich, dass GPL/AGPL Software deutlich weniger Nutzer hat.
Auf was stützt Du diese Behauptung?
Bisher war das eine Vermutung. Wenn ich mir jetzt die github Repos mit den meistenn Sternchen anschaue, dann sehe ich dort hauptsächlich MIT und BSD artige Lizenzen. Keins mit GPL/AGPL.
Welche GPL/AGPL Projekte sind aus deiner Sicht häufig im Einsatz (außer dem Kernel)?
Hier gibt es eine Liste mit Gnu-Projekten - vermutlich viele unter der
GPL.
Ein paar prominentere Projekte: grep, emacs, gimp, gv, gzip.
Siehe auch https://en.wikipedia.org/wiki/Category:Software_using_the_GPL_license , worunter sich einige bekannte Namen finden:
AbiWord Audacity Drupal Geany Gedit Git GCC Jedit Joomla Konqueror MariaDB MoinMoin MySQL
Weitere Beispiele (nach meiner Recherche):
Bash Calibre FFMPEG Ghostscript Gnome Grub (Linux-Bootmanager) Inkscape Linux Kernel Mailman Mercurial NetworkManager VirtualBox (die Open-Source-Teile) VLC wget
Vielleicht ist github nicht die beliebteste Repoquelle für GPL-Projekte?!
Denke ich auch.
Viele Grüße Stefan _______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
Also Wikipedia sagt, dass selbst LibreOffice unter GPL lizensiert wird, und das ist schon recht beliebt (wenn ich mich richtig erinnere, über 20% Marktanteil bei Office-Software)
Am 29. Oktober 2019 14:29:38 MEZ schrieb "Thomas Güttler" guettliml@thomas-guettler.de:
Am 29.10.19 um 10:52 schrieb Hartmut Goebel:
Am 29.10.19 um 10:26 schrieb Thomas Güttler:
Es ist natürlich sehr wahrscheinlich, dass GPL/AGPL Software
deutlich
weniger Nutzer hat.
Auf was stützt Du diese Behauptung?
Bisher war das eine Vermutung. Wenn ich mir jetzt die github Repos mit den meistenn Sternchen anschaue, dann sehe ich dort hauptsächlich MIT und BSD artige Lizenzen. Keins mit GPL/AGPL.
Welche GPL/AGPL Projekte sind aus deiner Sicht häufig im Einsatz (außer dem Kernel)?
-- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines _______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
On 2019-10-24 09:56, Thomas Güttler wrote:
seit zwei Jahren pflege ich meine Programming-Guidelines, damit ich mich selbst bessere daran halte :-)
Falls es jemanden interessiert:
https://github.com/guettli/programming-guidelines
ich bin beeindruckt, wie sehr das Dokument inzwischen gewachsen ist. Mir gefallen besonders auch die "semi-technischen" Punkte (zum Beispiel Dokumentation) und die nicht-technischen (zum Beispiel nicht über andere lästern und Stress vermeiden)!
Ich habe aber noch eine Anmerkung zur UML. In bestimmten Situationen bin ich sehr froh, dass es die UML gibt. Ich verwende sie, wenn ich ein kniffliges Design-Problem vor mir habe (dann aber in einem Modellierungs- und weniger als in einem reinen Zeichen-Werkzeug) sowie zur Dokumentation für andere.
In einem Treffen mal eben eine (Nicht-UML-)Skizze aufs Whiteboard zeichnen ist super. Wenn etwas unverständlich ist, kann man es sofort erklären. Aber für Dokumentation, die später ohne Rückfrage-Möglichkeit von anderen gelesen wird, ist mehr Standardisierung sehr nützlich. Das gilt erst recht, wenn sich ein Design nicht einfach mit ein paar Kästchen und Verbindungslinien erklären lässt.
Ich denke auch, dein Vergleich mit Esperanto hinkt. Bei allgemeinen Sprachen gibt es Alternativen, die noch mehr Leute verstehen (zum Beispiel Englisch), aber mir ist keine alternative grafische Notation für Software-Systeme bekannt, die auch nur annähernd so verbreitet wäre wie UML. Natürlich muss man kein kompliziertes Diagramm zeichnen wenn es auch ein einfacheres tut, aber das gilt unabhängig von UML. :-)
Viele Grüße Stefan
On 2019-10-24 09:56, Thomas Güttler wrote:
seit zwei Jahren pflege ich meine Programming-Guidelines, damit ich mich selbst bessere daran halte :-)
Falls es jemanden interessiert:
https://github.com/guettli/programming-guidelines
eine Frage zum Thema CRUD -> CRD: Wie hältst du es, wenn der zu löschende Datensatz eine Id enthält, die von anderen Objekten referenziert wird?
Viele Grüße Stefan
On 2019-10-28 19:19, Stefan Schwarzer wrote:
On 2019-10-24 09:56, Thomas Güttler wrote:
seit zwei Jahren pflege ich meine Programming-Guidelines, damit ich mich selbst bessere daran halte :-)
Falls es jemanden interessiert:
https://github.com/guettli/programming-guidelineseine Frage zum Thema CRUD -> CRD: Wie hältst du es, wenn der zu löschende Datensatz eine Id enthält, die von anderen Objekten referenziert wird?
Mit "Objekten" meinte ich andere Datensätze, also unabhängig von einer bestimmten Programmiersprache oder OOP.
Viele Grüße Stefan
Am 28.10.19 um 19:19 schrieb Stefan Schwarzer:
On 2019-10-24 09:56, Thomas Güttler wrote:
seit zwei Jahren pflege ich meine Programming-Guidelines, damit ich mich selbst bessere daran halte :-)
Falls es jemanden interessiert:
https://github.com/guettli/programming-guidelineseine Frage zum Thema CRUD -> CRD: Wie hältst du es, wenn der zu löschende Datensatz eine Id enthält, die von anderen Objekten referenziert wird?
Die ID kann ja recycled werden. Also das neu angelegte Objekt hat die Id des alten Objekts.
participants (6)
-
Hartmut Goebel -
kb1000 -
Marco Bakera -
Reimar Bauer -
Stefan Schwarzer -
Thomas Güttler