• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] Namensgebung von Shell-Variablen

Hi,
Möche bei meinen Scripten generell die Namensgebung "$_FILENAME" für Dateipfade verwenden. Das das funktioniert ist schon klar, aber es gibt ja geschriebene / ungeschriebene Regeln.. Ist irgendetwas gegen eine solche Namensgebung einzuwenden?

viele grüße,
tom
 
A

Anonymous

Gast
OsunSeyi schrieb:
Hi,
Möche bei meinen Scripten generell die Namensgebung "$_FILENAME" für Dateipfade verwenden. Das das funktioniert ist schon klar, aber es gibt ja geschriebene / ungeschriebene Regeln.. Ist irgendetwas gegen eine solche Namensgebung einzuwenden?

Das passt schon, solange du diese Variablen nicht exportieren musst, kannst du dir sowieso alles erlauben was dir gefällt oder deiner Dokumentation des Scriptes zugute kommt. erlaubten Zeichensatz beachten und darauf achten das du nicht in Konflikt mit exportieren und Bashvariablen kommst.

Ungeschrieben ungefähr ist folgendes, (da ungeschrieben kann ich es aber nicht beweisen :D )

Code:
Variabel=GROSS 

Variablen=_GROSS     # wenn diese ehr als Konstanten als Variablen eine Verwendung haben. (machen jedenfalls viele so) also zB wenn prinzipiell nur am Anfang einmal der Wert gesetzt weden soll, der dann bis zum Ende bleibt.  Bei vielen Bashprogrammierern haben die Variablen mit Unterstich gegenüber den Variablen ohne Unterstich also durchaus andere Eigenschaften. Ob es jetzt diese Konstanz ist oder eine andere Eigenschaft für die Unterscheidung Bedeutung hat, ist dabei zwischen den Programmieren jedoch unterschiedlich, kommt wohl auch auf den Umfang und Komplexität der zusammengehörigen Scripte an. 

Variablen=__klein        # wenn sie privat für Konstandte Gruppierte Strings verwendet wird, zB für eine Hilfsvariable mit konstanten Ausgabetext, die mit der eigentlichen Funktion des Scripts nichts zu tun hat.   

function=_klein  |  klein    # je nachdem in welcher Rangordnung der Funktionen, klein() wird direkt im Script aufgerufen; _klein()  dagegen ist eine Hilfsfunktion und soll nur innerhalb von Funktionen aufgerufen werden.

Alias=klein                 # und treffend kurz

einfach mal mit "set | more" und "env | more" nachschauen wie es bis jetzt auf der Bashumgebung ausschaut, und dort ähnlich weitermachen. Da sieht man auch gleich mal was jetzt schon alles vorhanden ist.
Prinzipiell ist wohl anzumerken, man erkennt bei größeren Scripten durchaus an der Namensgebung was der Programmierer vorher mal für andere Programmierspachen erlernt hat. ;)

robi
 
Vielen Dank!
"set" und "env" sind in der Tat aufschlussreich, und Deine Erläuterung auch!
Also komme ich auf die Art wohl nicht in Konflikte, und finde es persönlich ansprechend, wenn es der Variable "anzusehen" ist, daß sie eine Datei bezeichnet.
 
robi schrieb:
Ungeschrieben ungefähr ist folgendes, (da ungeschrieben kann ich es aber nicht beweisen :D )

Interessant. Das war mir bisher nicht bewusst.
Eine Gewissens- und Codeerforschung aber fördert zu Tage, dass ich zumindest die Unterscheidung zwischen Groß- und Kleinschreibung genau so wie von Dir beschrieben handhabe.

Irgendwie komisch, was man alles intuitiv aufgreift, ohne es zu merken ...
 
utopos schrieb:
robi schrieb:
Ungeschrieben ungefähr ist folgendes, (da ungeschrieben kann ich es aber nicht beweisen :D )

Interessant. Das war mir bisher nicht bewusst.
Eine Gewissens- und Codeerforschung aber fördert zu Tage, dass ich zumindest die Unterscheidung zwischen Groß- und Kleinschreibung genau so wie von Dir beschrieben handhabe.

Irgendwie komisch, was man alles intuitiv aufgreift, ohne es zu merken ...
Stimmt ja auch nicht, daß es ungeschrieben ist. Sowas nennt man "Style-Guide". Einen für Bash findet man hier.

Der für Python ist recht bekannt und nennt sich "PEP 8".
Für Perl gibt es neben "perldoc perlstyle" z.B. das Modul "Perl::Critic", weiterhin gibt es ein lustiges Zitat von Damian Conway:
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
;)
 
A

Anonymous

Gast
abgdf schrieb:
Stimmt ja auch nicht, daß es ungeschrieben ist. Sowas nennt man "Style-Guide". Einen für Bash findet man hier.
;) ;) ;)
genau das was ich vermeiden wollte, Spielregeln aus der Oberliega .....
Aber bitte, wer mehr als 5 Beispiele aus diesem "Guide" verseht, darf sich gerne bei den Variabelnamen auch an dieses Guide halten
Einzige Aussage zum Thema ist folgende:
Für Variablen sind grundsätzlich sinntragende, selbstdokumentierende Namen zu verwenden (wie zum
Beispiel eingabedatei). Bei Namen werden die ersten 31 Zeichen unterschieden. Lange Namen werden
durch Unterstriche gegliedert um die Lesbarkeit zu verbessern. Wenn ein Name nicht selbstdokumen-
tierend ist, dann ist die Bedeutung und Verwendung beim ersten Auftreten durch einen Kommentar
zu beschreiben.
alle Variabelnamen sind in allen Beispielen natürlich klein, obwohl in 99% aller Bücher Bashvariablen dagegen GROSS sind. Und wer Variablenamen länger 31 Zeichen gestaltet damit sie ja ausreichend sinntragend und selbstdokumentierend sind, aber gleichzeitig auf eine Zeilenlänge (inklusive Kommentar) von 80 oder 88 pochen will, kann so schön schreiben und dokumentieren wie er will, das kann oder will so oder so niemand fremdes verstehen.
Code:
for interne_schleifen_variable_i in A B C D; do
  echo $interne_schleifen_variable_i
done
der Rest bleibt trotzdem ungeschrieben, hat bei der Übersetzung gelitten oder ist oft zwischen den Autoren so widersprüchlich, dass man sich vielleicht doch dem anschließt was in 95% der Scripte innerhalb Linux und in 50% oder mehr der guten Scripte in Internet praktziert wird.


robi
 
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Ja, so oder ähnlich ist es wohl, man wird ja auch nicht jünger und versteht zuletzt selber nicht mehr, was man da zusammengebastelt hat :ugly:

Aber das ist etwas persönliches, was nicht unbedingt die Lesbarkeit für Aussenstehende betrifft. Ich halte es so, daß Variablennahmen (ähnlich wie Unix-Befehle) nicht unbedingt selbsterklärend, sondern eher kurz und prägnant sind:

Code:
#			Label in der Quelldatei finden, bei mehreren Fundstellen wird nur
#			die erste genommen ("grep -m NUM").

			LABEL=`egrep -m 1 "$EXPR" $FILE | sed 's|^[^\t]\+\t\(.*\)$|\1|g'`
			VALUE=`egrep -m 1 "$EXPR" $FILE | sed 's|\t.*$||g' | egrep '^\s*[0-9]+([.,][0-9]{2})?'`

#			Fehlerausgabe:

			if [ -z "$LABEL" ] ; then echo -e 'Label not found line '$N': "'$EXPR'"\t'$FILE ; continue ; fi
			if [ -z "$VALUE" ] ; then echo -e 'Value not found line '$N': "'$EXPR'"\t'$FILE ; continue ; fi

Was beweisen soll, warum gleichlange Variablennahmen ("LABEL", "VALUE") die Lesbarkeit verbessern können.
Ein Name wie Das_ist_ein_ganz_tolles_Label_was_jeder_sofort_begreifen_kann würde das eher nicht leisten...
 
robi schrieb:
genau das was ich vermeiden wollte, Spielregeln aus der Oberliga .....
;) Macht ja nichts, bei einem einfachen Shell-Skript ist das vielleicht auch nicht so wichtig. Bezieht sich mehr auf größere Programme, die ggf. von mehreren oder vielen geschrieben oder gewartet werden sollen.
Das, was ich für Bash ausgegraben hatte, ist auch nicht gerade offiziell. Bei "PEP 8" usw. sieht das schon anders aus. "perldoc perlstyle" ist dagegen ziemlich zurückhaltend und läßt dem einzelnen also recht viel Freiheit.
Natürlich wirkt ein Style-Guide zunächst mal einengend. Aber wenn man sich einen Stil angelernt hat, und dann z.B. nach einem halben Jahr ein Skript nochmal anguckt und sofort sieht, "Aha, großgeschrieben, also Konstante" und das auch bei Skripten anderer sofort erkennt, kann einem das schon helfen, sich schneller in ein Skript einzuarbeiten. Hat grundsätzlich also eine gewisse Berechtigung, bei Skripten mit nur wenigen Zeilen (< 100 oder so) natürlich weniger als bei größeren.
 
Oben