bootstrap Design

[WasserLinse]

(2. Versuch, nachdem mein 1. nicht freigeschaltet wurde)
Bootstrap gibt es für Python, tkinter und für Html/CSS. Deshalb habe ich mich damit beschäftigt. Ich programmiere eine Übermenge, die automatisch Python/tkinter wie auch Html/Css generiert. Das sieht dann so aus:

lab1 = LabelAll("| dies ist die Message 1 |")
gridAll.place(0, 0, lab1)
ent1 = EntryAll("Bitte eingeben", "123")
gridAll.place(0, 1, ent1)
statusLineAll = LabelAll("statusLine")
gridAll.place(1, 0, statusLineAll)
but1 = ButtonAll("drueck mich")
gridAll.place(1, 2, but1)

Generiert wird eine Gui per tkinter: http://www.software-loes.de/img/2024-10_gui_tkinter.png
bzw. in Html: http://www.software-loes.de/img/2024-10_gui_html.png

Viele Grüsse

[__blackjack__]

@WasserLinse: Warum enden die Namen alle mit *All? Und wo kommt `gridAll` her? `place()` erweckt bei Tk Erwartungen die nichts mit einem Grid zu tun haben.

Namenskonvention in Python ist ja klein_mit_unterstrichen, ausser für Konstanten (KOMPLETT_GROSS) und Klassen (PascalCase). Und man sollte kryptische Abkürzungen meiden und man nummeriert keine Namen. Schon gar nicht so unnötig das man überall eine 1 anhängt.

[WasserLinse]

Oh, ertappt - ich verwende Java-Konventionen. All soll hier heissen, dass später beide GUIs generiert werden.

Ansonsten ist das ein Snippet, nur zum Lesen, da ich nicht den gesamten Code zeigen kann, das ist dann doch zu viel. Wäre git eine Lösung?

[__blackjack__]

@WasserLinse: Das `All` gehört dann aber nicht in jeden Namen, das gibt keinen Mehrwert an Information. Das sieht man ja schon daran, aus welchem Modul/Package man die Namen importiert hat, dass das keine reinen Tk-Objekte sind.

[WasserLinse]

Könnte man sagen - aber ich finde, es stört auch nicht, das All
Danke jedenfalls, dass Du geantwortet hast.
- ---------------------
Python ist cool, aber die äussere Welt, die Auftraggeber, finden Kotlin auch cool.

[sparrow]

Es würde in jeder Sprache stören, weil es ein Beispiel für schlechte Namensgebung ist.
Was Kotlin jetzt damit zu tun hat, erschließt sich mir nicht. Ich hoffe, dass soll nicht der Grund für die Nichteinhaltung der Namenskonvention sein.

[__blackjack__]

@WasserLinse: So ein Anhängen (oder voranstellen) von einem Namensbestandteil ist halt üblich bei Programmiersprachen die keine Namensräume kennen, wie C beispielsweise. Aber genau weil das eben doch stört, haben die meisten neueren Sprachen Namensräume, wo gemeinsame Prä- oder Suffixe hin verschoben werden.

Kotlin mag ich auch. Und auch da würde man das nicht so machen, denn da gibt es Namensräume. Und ich halte mich bei Kotlin an die dortigen Namenskonventionen und verwende da nicht die von Python.

Was mich an dem All auch noch stört ist die Bedeutung. Tk und HTML sind ja nicht wirklich ”Alles” was es da so an GUI-Möglichkeiten gibt. `All` ist *deutlich* übertrieben an der Stelle.

[WasserLinse]

Scheins hab ich einen Profi am Anworten ät__blackjack__. Allerdings bin ich selber auch Profi, Trainer für Python-Anfänger. Da sage ich die Namenskonventionen einmal, danach darf jeder benennen, wie er will. Vielleicht wäre _both das bessere Suffix, aber es könnte ja noch eine GUI dazu kommen (finde die zwei, tkinter bootstrap und HTML/bootstrap.css aber ausreichend). Bleibt also beim All.

Jedenfalls scheit die Grundidee keine neue, weltbewegende Idee zu sein ...

[__blackjack__]

@WasserLinse: Ist aber ein schlechter Rat Namenskonventionen nicht zu folgen. Das ist ja nicht nur einfach Geschmackssache sondern in den Schreibweisen stecken Informationen drin, die dann verloren gehen, wenn man sich nicht dran hält. Ausserdem erschwert es die Zusammenarbeit.

[sparrow]

@WasserLinse: "Trainer" darf sich heutzutage bekanntlich jeder nennen. Wenn du bei deinen Trainings die Namenskonvention vernachlässigst ist das in meinen Augen schlicht falsch. Dann solltest du dein Training dringend überdenken.
Und bekanntlich gibt es in der Informatik 2 grundlegende Probleme: Das Invalidieren von Cache, Dinge benennen und Off-by-one-Error. Benennung ist also wichtig. Warum hat __blackjack__ schon ausgeführt. Wenn du das anders siehst, kannst du das tun. Ist aber falsch. Schade für die Anfänger, die du "trainierst".

[WasserLinse]

@WasserLinse: "Trainer" darf sich heutzutage bekanntlich jeder nennen. Wenn du bei deinen Trainings die Namenskonvention vernachlässigst ist das in meinen Augen schlicht falsch. Dann solltest du dein Training dringend überdenken.
Und bekanntlich gibt es in der Informatik 2 grundlegende Probleme: Das Invalidieren von Cache, Dinge benennen und Off-by-one-Error. Benennung ist also wichtig. Warum hat __blackjack__ schon ausgeführt. Wenn du das anders siehst, kannst du das tun. Ist aber falsch. Schade für die Anfänger, die du "trainierst".

Holla, ganz schön unfreundlich, dieses Forum. Immerhin bin ich hoch qualifiziert und die Teilnehmer benoten die Trainer, und ich mache das seit Jahren. Und deshalb weiss, ich, dass man die Teilnehmer besser motiviert, wenn man nicht dauern "Falsch, Falsch" ruft. Hauptsache ist doch, dass das selbstgeschriebene Programm läuft. Anderes kommt automatisch hinzu. Wie bei einem Kind, das weiss anfangs gar nix, und lernt einfach hochmotiviert mehr und mehr. Wenn man es lässt ...

Und nun zum Thema. Also es läuft und macht Freude, wenn zuerst in tkinter und dann in Html eine Benutzer-Oberfläche und Grafik wie Linien und Kreise erscheint. Also mache ich allein weiter, da es NICHT um Namens-Konventionen geht. Es geht nicht um Names-Konventionen.

[__blackjack__]

@WasserLinse: Da Namenskonventionen zu leicht lesbarem Code gehören, und es eigentlich immer um die Lesbarkeit gehen sollte, geht es auch immer um Namenskonventionen.

Zumal es hier ja nicht darum geht einen Anfänger mit „Das ist falsch“ zu demotivieren, sondern das ein Lehrer das wenigstens richtig vormachen sollte. Aber wenn der sich schon nicht an sinnvolle Konventionen hält und das auch nicht für wichtig hält, lernen die Schüler das auch nicht.

Anfänger die Lehrer/Dozenten benoten, benoten nicht die fachliche Kompetenz. Können sie gar nicht, denn dazu müssten sie das ja beurteilen können, dann bräuchten sie aber den Anfängerkurs nicht.

[WasserLinse]

@WasserLinse: Da Namenskonventionen zu leicht lesbarem Code gehören, und es eigentlich immer um die Lesbarkeit gehen sollte, geht es auch immer um Namenskonventionen.

Zumal es hier ja nicht darum geht einen Anfänger mit „Das ist falsch“ zu demotivieren, sondern das ein Lehrer das wenigstens richtig vormachen sollte. Aber wenn der sich schon nicht an sinnvolle Konventionen hält und das auch nicht für wichtig hält, lernen die Schüler das auch nicht.

Anfänger die Lehrer/Dozenten benoten, benoten nicht die fachliche Kompetenz. Können sie gar nicht, denn dazu müssten sie das ja beurteilen können, dann bräuchten sie aber den Anfängerkurs nicht.

Lesbarkeit ist ein wichtiges Argument, laut Bob Martin "Clean Code" macht Lesen 80 % der Zeit eines Programmierers aus. Deshalb verweise ich auf ihn "Uncle Bob, Mr. Clean-Code". Aber was ist lesbar? Für Java-Programmierer, die auf Python umsteigen, dürfte das CamelCase sein, was in meinen Augen sowieso das Logische ist.

Es gibt Camel Case, Snake Case und Kebab Case. Python normal Snake Case, was mehr Anschläge erfordert, aber _____ weniger Umschalt-Taste. Kebab-Case geht nur in CSS, das ist schonmal raus. Konstanten in Grossbuchstaben ANSWER = 42 ist programmsprachen-übergreifend, also auch in Python. Ebenso Klassen "WildAnimal". this_is_a_constant_for_the_universe : Nee. PEP 8 : Wer liest das schon. Naja, vielleicht liest es ja doch jemand.

[Sirius3]

@WasserLinse: auch wer zuerst Deutsch Schreiben gelernt hat (großgeschriebene Substantive sind ja das Logische) wird in anderen westeuropäischen Sprachen die meisten Substantive klein schreiben. Da legen die Lehrer oft Wert drauf.
Dass Du damit persönlich noch ein Problem hast, sollte Deine Qualität als Trainer nicht beeinträchtigen. Der lehrt auch Dinge, die ihm nicht so liegen, einfach deshalb, weil sie richtig sind.
Als Anfänger muß man PEP8 nicht gelesen haben, aber der Lehrer sollte sich strikt daran halten.

[__blackjack__]

@WasserLinse: Lesbar ist das auf das man sich in einem Umfeld geeinigt hat. Wie Du ja richtig geschrieben hast ist das für Java-Programmierer camelCase. Und bei Python halt snake_case.

Wie würdest Du das denn umgekehrt sehen — Python-Programmierer (oder C, …) die auf Java umsteigen und snake_case gewohnt sind: Wäre das okay da Namen dann einfach in snake_case zu schreiben, entgegen den Konventionen bei Java? Hast Du das schon mal gesehen und kannst auf ein Beispiel verweisen?

Was ist an CamelCase denn ”logischer” als an klein_mit_unterstrichen?

Anzahl der Anschläge ist IMHO heutzutage nicht mehr wirklich ein Grund. Selbst simple Texteditoren haben heute eine Autovervollständigung, die auf dem Inhalt der offenen Datei(en) basiert. Man muss also selten wirklich komplette Namen eintippen.

Ich habe den Eindruck Du siehst den Vorteil an Konventionen selbst bei dem Beispiel von Konstanten, die in vielen Sprachen KOMPLETT_GROSS geschrieben werden. Man weiss dann was einen erwartet wenn man so einen Namen liest und wie man selber Konstantennamen schreiben sollte. Wobei auch nicht in allen Sprachen diese Konvention gilt. In Lisp gibt es beispielsweise die Konvention Konstanten mit + anzufangen und zu beenden aber ansonsten bei kleingeschriebenen Worten die durch - getrennt sind zu bleiben, also so etwas wie ``(setconstant +the-answer+ 42)`` um die Konstante +the-answer+ zu definieren.

[noisefloor]

Hallo,

Als Anfänger muß man PEP8 nicht gelesen haben, aber der Lehrer sollte sich strikt daran halten.

+1 - das bringt es genau auf den Punkt.

Gruß, noisefloor

[WasserLinse]

Na gut, es scheint wichtig zu sein und so füge ich mich der Lesbarkeit. the_answer_to_everything = 42. Snake Case. Glaube zwar nicht, dass es sich langfristig durchsetzt, wegen:

wildAnimal = new WildAnimal() versus wild_animal = WildAnimal() ---- da ist ein Bruch - aber was solls, wild_animal ist es. Ob es didaktisch schlau ist, ist eine andere Frage.

[noisefloor]

Hallo,

Glaube zwar nicht, dass es sich langfristig durchsetzt, wegen:

Äh... da hast du dann wohl leider die letzten 23 Jahre bei Python verpasst. Die Namenskonvention basiert auf der PEP8 und die PEP8 datiert auf Juli 2001.

Gruß, noisefloor

[WasserLinse]

@noiseflor
Stimmt, Python fängt für mich erst mit Py3 an, und also am 3.12.2008. Davor nahm ich es nicht ernst. Aber man kann debattieren, ob Python 0bjekt-Orientierung nicht überspringen hätte sollen. Gleich zu funktionaler Programmierung, wer OO will, soll Java oder TypeScript machen.

[sparrow]

@WasserLinse:
Ein bisschen Geschichte:
Java ist 1995 erschienen.
TypeScript 2012.
Python 1991.

Ich verstehe auch nicht, warum funktionale Programmierung "nach" Onjektorientierung kommt. Das eine schließt das andere ja nicht aus. Und in Python hast du die Freiheit zu wählen, was zum Problem passt