Manchmal tue ich mich schwer mit der Wahl von Namen für Variablen und
Funktionen. Ich habe beispielsweise ein eindimensionales Numpy Array mit
Einsen und Nullen. Es ist ein binärer Code.
Da fängt es schon an. Was ist das jetzt genau? Ein bin_array? bin_vec?
bin_record? bin_data? bin_input?
Es ist der Input für eine Assoziativmatrix.
bin_array wäre technisch orientiert, ich weiß dann um was es sich
technisch handelt, ein Array mit binären Werten. Aber der Name sagt
nichts darüber aus wozu es in der Anwendung dient.
Und wenn ich bin_vec wähle? Dann orientiere ich mich mehr an einer
mathematischen Namensgebung. Was mache ich dann wenn ich
mehrdimmensionale Datensätze habe? bin_vec1d, bin_vec2d, bin_vec3d?
bin_matrix? bin_tensor? Dann habe ich tolle mathematische Begriffe, die
mir aber nichts darüber sagen um was es sich im Kontext der Anwendung
handelt.
Oder ich vergesse technische und mathematische Begriffe und orientiere
mich allein am Kontext der Anwendung und den abstrakten Konzepten? Also
bin_record? bin_data? bin_input? bin_signal?
Dann habe ich eine ungefähre Vorstellung davon um was es sich im Kontext
der Anwendung handelt aber verliere den Bezug auf die technische
Beschaffenheit.
bin_record oder bin_signal kann alles sein. In Python kann es ein numpy
array sein, eine Liste, eine Zahl, ein Objekt.
Ich bin also mit keiner Namensgebung wirklich zufrieden. Und so was wie
bin_signal_array ist doch auch schlecht. Davon fühlt sich keines richtig
an ... :D
Gibt es nicht irgendwelche hilfreichen Richtlinien wann man wie vorgehen
sollte?
Irgendwer muss doch darüber schon mal tief nachgedacht haben und zu
hilfreichen Erkenntnissen gekommen sein? :D
Massenhaft! Goggel kaputt?
Z.B. „Weniger schlecht programmieren“
(Ja, sorry. Das ist ein Buch.)
Und (imho): weniger_unterstriche_in_Bezeichnern.
Aber das ist sicherlich auch Geschmacksfrage. IchBinEherDerCamelCaseTyp…
Vor allem sollten es sprechende Namen sein. Dabei halte ich das "Was ist
es, wofür wird es verwendet" für am wichtigsten. Daraus und in
Verbindung mit Kommentaren, was man da programmiert hat, ergeben sich
dann auch wieder die technischen Aspekt, wie man z.B. etwas abgelegt
hat.
ManPy schrieb:> Es ist der Input für eine Assoziativmatrix.
Dann nenne die Variable doch einfach input_für_assoziativmatrix oder
inputFürAssoziativmatrix (wahlweise auch "ue" statt "ü"). Falls die
Assoziativmatrix nicht generisch ist, sondern eine ganz bestimmte
Funktion erfüllt, kannst du den Variablennamen noch weiter verfeinern.
Überleg doch mal, was du als Kommentar dahinterschreiben würdest. Und
mach daraus einen (vernünftigen) Variablennamen :-)
Es kommt öfters vor, dass man länger über den Namen einer Funktion oder
Variablen nachdenkt, als die eigentliche Implementierung des Ganzen
dauert.
ManPy schrieb:> Gibt es nicht irgendwelche hilfreichen Richtlinien wann man wie vorgehen> sollte?> Irgendwer muss doch darüber schon mal tief nachgedacht haben und zu> hilfreichen Erkenntnissen gekommen sein? :D
Willst es einfacher haben? Programmiere in FORTRAN77, Bezeichner sind da
in Länge Begrenzt und es herrscht Ordnung. Was die Sprache nicht vorgibt
ist durch jahrzehntelang organisch gewucherten Konventionen
diszipliniert...
Lies fremden Code und merke Dir was Dir davon gefällt und was dich
gruselt/verwirrt. Es muss ja nicht gleich IOCCC sein.
Werden deine Daten nach einer allgemein bekannten Formel verarbeitet?
(z.B. y[i]=a*x[i]+b) dann nenne deine Variablen so, besonders wenn es
lokale Variablen und/oder Funktionsparameter sind. Mach auf benannte
Funktionsparameter, gerne auch bei Aufrufe der Funktionen.
Da es hier im besonderen um Python geht: aliasing geht so gut wie
immer insbesondere bei strukturierten Datentypen und zwar mit
irrelevantem Overhead/Penalty.
Obendrein gibt es beim Import aus Modulen (und ähnlich bei
Kontext-Manager, s. with ) die Form
1
frompprintimportpprintaspp
2
3
pp([1,2,"drei",[pp,print]])
Mach also ein Modul, das kann auch als billige/simple/minimale Variante
einer Klasse angesehen werden.
Lerne DocStrings von Python dann bekommst mühelos von Code&Kommentare
abgeleitete Doku (z.B. HTML) genau so wie Python selbst es nutzt und
jeder weiss wie darin zu lesen u. navigieren.
Danach kommst Du auf den Geschmack selber Klassen zu schreiben, und sei
es nur der Kommentarmöglichkeiten in DocString-Manier wegen, auch wenn
Du nur 1 lokale Instanz davon machst.
Generell: schnuppere dich durch die PEPs von Python welche Style von
Code&Kommentare betreffen. DAS SIND DIE Standard wonach Du suchst.
Zuletzt: zum Glück geht es hier um Python! Du kannst jeder deiner
Instanzen mit
1
meineVariable.setattr("__doc__","""Beliebige Beschreibung worum wieso es hier gehen soll""")
um eine individuelle Beschreibung ergänzen.
Spiele interaktiv mit der Standardfunktionen "help()" und "dir()" an
deinen Variablen herum.
Random .. schrieb:> Überleg doch mal, was du als Kommentar dahinterschreiben würdest. Und> mach daraus einen (vernünftigen) Variablennamen :-)
Ja. Und besser: schreibe den Kommentar hin, den Du selbst erwartest
vorzufinden.
Dann mach daraus einen gescheiten Variablen-/Funktionsnamen.
> Es kommt öfters vor, dass man länger über den Namen einer Funktion oder> Variablen nachdenkt, als die eigentliche Implementierung des Ganzen> dauert.
Ja. Und das sitzt selten auf Anhieb, benötigt durchaus mehrere Runden
(in mehreren Sessions bei denen an Code&Kommentar gearbeitet wird)
(frühes) Code Refactoring kann auch aus bloss besserer Benennung
bestehen.
(aber aufpassen bei APIs u. ähnlichen "Vertragsschnittstellen", diese
sollen eher von Anfang an sitzen, gut sein und langlebig werden)
Laaaange Bezeichner sind kein Thema: renaming und aliasing auf kurze,
passende Bezeichner helfen um am Verwendungsort dem Code "Knackigsität"
zu verleihen.
Inder mit Tröte vorm Korb schrieb:> Willst es einfacher haben? Programmiere in FORTRAN77, Bezeichner sind da> in Länge Begrenzt und es herrscht Ordnung.
Ja, ich habe den weggelassenen Smiley gesehen :)
Trotzdem hier mal ein kleines Rätsel aus der Fortran-Welt. Was machen
die folgenden Funktionen:
DGESV, SGESV, DGTSVX, CPPSVX, ZSPSV, DPPSVX, SPTSVX, SSYSV, SPOSVX,
CPTSVX, ZGBSVX, SPPSV, ZGBSV, CHPSVX, SGESVX, CPTSV, SPTSV, CGTSV,
ZPOSV, CGBSV, SPBSV, SSYSVX, CPBSVX, CGBSVX, ZSYSVX, DGESVX, SPPSVX,
DGBSVX, ZHESV, DPOSVX, CPOSV, SGTSV, CSYSVX, DPPSV, ZGESVX, ZSYSV,
SSPSVX, ZHPSV, ZPTSV, DPBSV, ZSPSVX, ZGTSVX, DSYSV, ZPBSVX, CPBSV,
ZPOSVX, SPBSVX, CSPSV, DPTSV, DPTSVX, SSPSV, CGTSVX, SGBSV, ZGTSV,
DSYSVX, SPOSV, SGBSVX, CHPSV, DPBSVX, CSPSVX, ZHESVX, CSYSV, ZPTSVX,
ZGESV, ZHPSVX, CPOSVX, ZPPSVX, CGESV, CHESVX, CPPSV, DPOSV, DGTSV,
DSPSV, ZPPSV, ZPBSV, SGTSVX, DSPSVX, CHESV, CGESVX, DGBSV
Ja, ist doch klar: Sie lösen lineare Gleichungssysteme ;-)
Die Funktionen sind Teil der weltberühmten LAPACK-Bibliothek.
Inder mit Tröte vorm Korb schrieb:> Zuletzt: zum Glück geht es hier um Python! Du kannst jeder deiner> Instanzen mit>> meineVariable.setattr("__doc__", """Beliebige Beschreibung > worum wieso es hier
gehen soll""")
>> um eine individuelle Beschreibung ergänzen.
Wirklich jede?
Probieren wir es doch gleich mal damit:
ManPy schrieb:> Ich habe beispielsweise ein eindimensionales Numpy Array mit> Einsen und Nullen.
1
>>> meineVariable = np.array([1, 0, 1])
2
>>> meineVariable.setattr("__doc__", """...""")
3
Traceback (most recent call last):
4
File "<stdin>", line 1, in <module>
5
AttributeError: 'numpy.ndarray' object has no attribute 'setattr'
Danke für die Antworten. Ich denke ich werde versuchen wie folgt
vorzugehen: Funktionen die man auch in eine eigene Bibliothek auslagern
und in verschiedenen Projekten nutzen könnte, werde ich technisch
benennen.
Eine Funktion die einen bestimmten binären numpy Array erzeugt heißt
demnach bin_arr() weil es an sich nur das ist/macht. Im Kontext einer
Anwendung kann das erzeugte Array dann verschiedene Funktionen
verkörpern und unterschiedliche Anwendungsbezogene Namen erhalten wie
query = bin_arr() oder response = bin_arr().
Und Funktionen deren unveränderte Verwendung in anderen Projekten sehr
unwahrscheinlich ist bekommen Namen die sich auf ihre abstrakte Funktion
beziehen. Wollte man etwa einen sehr spezifischen Query erzeugen kann
die Funktion create_query() oder query() heißen.
Wobei mit Variablennamen bzw. Datenstrukturen verhält es sich etwas
anders. Da kann man ja nicht überlegen ob man bestimmte Variablen
auslagert um sie in anderen Projekten zu nutzen :D
Bis auf wenige Ausnahmen wie Konstante Werte oder so.
Eine Variable die einen Numpy Array mit Einsen und Nullen verkörpert
sollte in der Anwendung nicht bin_arr heißen.
Sagen wir man verwendet die selbe Datenstruktur als query und response.
Dann müsste man ja so was wie bin_arr_que und bin_arr_res machen. Mega
hässlich.
So was sollte dann lieber nur query und response heißen. Man kann diese
Namen durch ein prefix oder suffix weiter spezifizieren.
Während die Funktion die diese Numpy Datenstruktur anhand bestimmter
Parameter erzeugt also bin_arr() heißen kann, sollte der Rückgabewert
lieber einen Namen tragen, der sich auf die abstrakte Funktion innerhalb
des Programms bezieht.
Aber es bleibt in vielen Fällen dennoch schwierig die richtigen Namen zu
geben.
Die Funktion bin_arr() nimmt übrigens einen Tupel als Parameter an worin
die Indices angegeben sind die festlegen welche Stellen im Array eine
Eins sein sollen. Der Rest ist Null.
query = bin_arr((2, 5), 10)
Der Tupel enthält die Indices und der zweite Parameter gibt die Länge
des Array an. query[2] und query[5] sollen also Eins sein und der Rest
Nullen.
Wie würdet ihr den Tupel bennnen?
def bin_arr(indices, length):
...
indices? target_indices? one_indices? ones? set_map? ... beschreiben
kann man den Verwendungszweck der Tupel ja nicht wirklich. Ein
target_indices, set_map oder ones kann alles mögliche sein.
Erst wenn man den Funktionsrumpf gelesen hat weiß man um was es sich
handelt. Ich finde es manchmal unmöglich in einer Variable komplexe oder
abstrakte Verwendungszwecke zum Ausdruck zu bringen.
Ich habe einfach indices gewählt, so weiß man wenigstens was die Zahlen
im Tupel sind. Wozu dass dann genau dient erfährt man in der Funktion.
