Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
Aus einer "nur mal eben schnell..."-Situation ist nun letztlich diese Seite entstanden. Bitte schaut mal drüber, ob das so ok ist. Sind die Kommentare innerhalb des Skriptes so ausführlich genug oder sollte noch mehr erklärt werden? Da ich kein Skripting-Profi bin, sind Vorschläge zur Code-Optimierung willkommen! Ich hoffe, es hilft auch anderen. Gruß,
Martin
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
richtig gut
Die meisten Funktionen sind kurz, und erledigen nur eine Sache; das ist sehr, sehr gut. Für meinen Geschmack sind die Variablennamen etwas zu lang, aber das ist viel besser als zu kurz.
weniger gut
Ein Kommentar an den Kopf des Skriptes was es macht wäre nett dagegen brauchen die Variablen version="0.5" und versionDate="07.04.2011" keinen Kommentar #Versionsinformationen. Nenn sie um in v und v_d, dann benötigen sie einen. Ähnliche Fälle findest Du selbst. Zeile 6-8: Ein Kommentar der sich feiert als sei er Fußballweltmeister geworden. Dass da Funktionen sind sieht man auch so sofort, und wer das nicht erkennt, dem hilft der Kommentar auch nicht. In absolutem Kontrast zur Wichtigkeit des Kommentars seine Hervorhebung. Hinfort der ganze Klamauk! Zeile 10, Typo Optionen: # -size Otione auswerten. Die Werte sind an die von "find" (siehe "man find") Die Funktionen haben innen eine zu weite Einrückung.
| function process_copyFiles_ext () {
function process_copyFiles_auto () {
function formatnsave_resultVars() {
|
Zeile 148: Mz. Datei: Dateien, nicht Datein Zeile 313: # Hilfetext: Pack das ganz nach oben, dann kommentiert es auch gleich den Code Zeile 385, # Meldungen: Siehe oben (WM). 388 ff: Da, wo sie verwendet werden, kommentieren solche Meldungen den Code automatisch - unten in einem Block nicht. 100x "| tee -a $LOG'" kann auch nicht richtig sein. Wenn die Meldungen nicht mehrfach verwendet werden, oder wenn sie nicht zwecks internationalisierung gruppiert werden müssen, dann ist deren Zusammenfassung ein Pseudo-Aufräumen, welches nur den Anschein von Ordnung verbreitet, so wie das Sortieren von Dateien nach Endung. 3 Dateien schwimmbad/kosten.ods, angebot.odt, kontakt.odt, rechnung.odt, mahnung.odt und prospect.pdf sowie golfplatz/kosten.ods, angebot.odt, agb.odt und prospect.pdf - da will man die Dateien nach der Projektzugehörigkeit sortiert haben. die unterschiedlichen Erweiterungen erleichtern einem im Verzeichnis die nähere Bestimmung, und man kann die Dateien intern sortieren. Die Erweiterung läßt sich ohnehin leicht erkennen - daher braucht man die nicht zusammenzufassen. So ist es auch mit den MSGs. exit 0 als letzte Zeile ist Quatsch. Was soll das bewirken? Wo lernt man sowas?
Statt:
| #get_DIRS
MSG_getDIRSready='printf "abgeschlossen.\n" | tee -a $LOG'
MSG_getDIRSresult='echo "Es wurden $dirCount Verzeichnisse mit insgesamt $totalfileCount Dateien gezählt." | tee -a $LOG'
#...
eval $MSG_getDIRSready
eval $MSG_getDIRSresult
|
hättest Du | msg () {
echo -e $1 | tee -a $LOG'
}
# ...
msg "abgeschlossen.\n"
msg "Es wurden $dirCount Verzeichnisse mit insgesamt $totalfileCount Dateien gezählt."
|
verwenden können. Dann hättest Du nur 1x dieses teealog, und wärst es rasch ganz los (denn sowas gehört dem User überlassen - u.U. erklärt man es auf einer Dokumentationsseite), und die Variablen, die die MSGes verwenden, stünden im gleichen Scope und auf der gl. Seite wie der Code, der sie verwendet. So ist es im Moment so, dass man in jeder Funktion, i.d. man eine Variable umbenennen will, erst mal alle MSGes abklappern muss, ob die nicht den Namen verwenden. Aus dem Auge, aus dem Sinn ... En detail habe ich den Code nicht angesehen - das ist einfach zu viel. Zeilenumbrüche in Dateinamen können wohl problematisch werden, aber die häufigeren Fehler mit Blanks scheinen vermieden.
|
Newubunti
(Themenstarter)
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
Also erst ein mal herzlichen Dank, für Dein Feedback. 👍 Das meiste habe ich korrigiert. Das mit dem tee... auf die Schnelle noch nicht, werde ich aber noch nachholen. user unknown schrieb: oder wenn sie nicht zwecks internationalisierung gruppiert werden müssen,
Also zusammengefasst werden müssen müssen sie nicht, aber in der Tat habe ich englisch- und andere fremdsprachige Bekannte, denen ich es übersetzen werde oder die es sich auch selbst übersetzen - daher die Blockbildung. Daraus resultieren dann auch die langen Variablen-Namen, die ich aber auch persönlich bei längerem Code schätze. Ansonsten ist das mit den kurzen und langen Namen ja wohl auch einer dieser Glaubenskriege, oder?
Wo lernt man sowas?
Wie gesagt, ich bin kein Profiprogrammierer. Insofern ist das eine dieser Dinge, die man mal irgendwo gesehen hat - und das sieht man in der Tat öfter - und das man dann übernimmt, ohne es groß zu hinterfragen. Gruß,
Martin
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Newubunti schrieb: Daraus resultieren dann auch die langen Variablen-Namen, die ich aber auch persönlich bei längerem Code schätze. Ansonsten ist das mit den kurzen und langen Namen ja wohl auch einer dieser Glaubenskriege, oder?
Kaum. Es ist allgemein bekannt, dass lange Variablennamen gut sind, wobei lang heißt: lang genug, um aussagekräftig genug zu sein. Das ist die wichtigste Aufgabe einer Variablen, wobei ein Laufindex i in einer Schleife keine weitere Aussage transportiert, und so kurz absolut richtig ist, und array_index ist nur eine Belästigung. Koordinaten x,y sind in dieser Kürze auch gut, denn andererseits will man nicht stundenlang tippen, und ständig scrollen. Es gibt also Kompromisse. Aber ich kenne niemanden, der vorschlägt alle Variablen durchzuenumerieren von a-z und dann aa-zz wenn es mehr als 26 sind. Es gibt aber Nachlässigkeiten, dass man vorläufig die Variablen a, b, c nennt, und sich vornimmt später bessere Namen zu verwenden. Das vergisst man dann, und manche Leute versuchen dass dann zu entschuldigen. Gerade bei kompliziertem, schwierigem Code zahlt sich aber kaum etwas so aus, wie richtig benannte Variablen, Methoden/Funktionen und Klassen. Wenn man eine Variable indexOfMax nennt, und nicht blos max, dann ist die Chance es 2 Wochen später nicht misszuverstehen viel größer, und wenn man während des Schreibens schon merkt, dass die Funktion nicht das macht, was ihr Name sagt, sollte man den Namen tunlichst ändern - oder das, was die Funktion tut. Beispielsweise ein getMax sollte ein Maximum zurückliefern, nicht ausgeben, oder printMax heißen. Wenn sich aus den benannten Einheiten problemlos Sätze bilden lassen, die das Programm beschreiben, ist man auf dem richtigen Weg. Von Knuth stammt, glaube ich, die Aufforderung zum literate programming.
|
Newubunti
(Themenstarter)
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
So ich habe jetzt im wesentlichen alle Vorschläge von user unknown umgesetzt. D.h. auch die Meldungen sind nun direkt im Code. Die Ausgabe erfolgt über Funktionen. Ein kleines Problem habe ich noch mit der Formatierung der Übersichtstabelle: Das rechtsbündige Anordnen funktioniert noch nicht so richtig. Hinter die Systematik des rechtsbündigen Anordnens bin ich ohnehin noch nicht so richtig gestiegen. Im Moment erhalte ich als Ergebnis z.B.: Dateityp Anzahl Dateien Größe (k)
c 31 615
desktop 1 0
exe_(141) 1 0
guess 1 41
gz 1 657
in 8 75
log 3 91
m4 2 20
man 3 100
NONE 13 899
plx 7 85
sh 15 151
sub 1 29
terms 1 0
txt 6 70
Gesamt: 112 2884
Schön wäre es halt so: Dateityp Anzahl Dateien Größe (k)
c 31 615
desktop 1 0
exe_(141) 1 0
guess 1 41
gz 1 657
in 8 75
log 3 91
m4 2 20
man 3 100
NONE 13 899
plx 7 85
sh 15 151
sub 1 29
terms 1 0
txt 6 70
Gesamt: 112 2884
Gruß,
Martin
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Und der Codeschnipsel, der das macht?
|
Newubunti
(Themenstarter)
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
Tabellen-Kopf: IFSbak=$IFS
IFS=$'\n'
cpResults[0]=$(echo -e "Dateityp\t\tAnzahl Dateien\t\tGröße ($sizeSuffix)")
IFS=$IFSbak
Tabellen-Eintrag: function formatnsave_resultVars() {
dirSize=$((dirSize/$divisor))
dirSize=$(echo -e "$dirSize" | sed -e :a -e 's/^.\{1,12\}$/ & /;ta')
fileCount=$(echo -e "$fileCount" | sed -e :a -e 's/^.\{1,19\}$/ & /;ta')
IFSbak=$IFS
IFS=$'\n'
cpResults[${#cpResults[*]}]=$(echo -e "$extension\t\t$fileCount\t\t$dirSize")
IFS=$IFSbak
} Tabellen-Fuß: totalSize=$((totalSize/$divisor))
totalSize=$(echo -e "$totalSize" | sed -e :a -e 's/^.\{1,12\}$/ & /;ta')
cpfileCount=$(echo -e "$cpfileCount" | sed -e :a -e 's/^.\{1,19\}$/ & /;ta')
IFSbak=$IFS
IFS=$'\n'
cpResults[${#cpResults[*]}]=$(echo -e "Gesamt:\t\t$cpfileCount\t\t$totalSize")
echo Und dann die Ausgabe von allem zusammen: OUTPUT=$(
for line in ${cpResults[@]};
do
echo -e "$line"
done
)
echo -e "$OUTPUT" | column -t -s"$(echo -e "\t")"
Dabei ist mir schon klar, dass ich das ganze über sed -e :a -e 's/^.\{1,19\}$/ & /;ta' kontrolliere. Mann könnte jetzt noch beim Einspeisen in cpResults die Länge des Strings ausgeben und auf dessen Grundlage den markierten Wert berechnen, anstatt ihn fix zu verwenden. Aber geht das ganze nicht auch einfacher? Gruß,
Martin
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! Wie siehts hier aus? Fertig? so long hank
|
Newubunti
(Themenstarter)
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
Also an sich ist das von meiner Seite so weit fertig. Allerdings finde ich es fragwürdig, wenn ein doch recht langer Code veröffentlicht wird, den sich kaum einer im Detail angeschaut hat. Vielleicht ist das hier ja die falsche Plattform für so etwas?! Gruß,
Martin
|
aasche
Anmeldungsdatum: 30. Januar 2006
Beiträge: 14259
|
Newubunti schrieb: Also an sich ist das von meiner Seite so weit fertig.
Ich habe noch ein paar Kommas korrigiert, ansonsten sieht der Artikel gut aus.
Allerdings finde ich es fragwürdig, wenn ein doch recht langer Code veröffentlicht wird, den sich kaum einer im Detail angeschaut hat.
Naja, immerhin hat sich wenigstens mit user unknown einer die Muehe gemacht. Allerdings koennte man noch eine Anfrage ins Unterforum "Shell und Programmieren" stellen, mit der Bitte um (Syntax-)Pruefung des Skripts.
|
Newubunti
(Themenstarter)
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
aasche schrieb: Allerdings finde ich es fragwürdig, wenn ein doch recht langer Code veröffentlicht wird, den sich kaum einer im Detail angeschaut hat.
Naja, immerhin hat sich wenigstens mit user unknown einer die Muehe gemacht. Allerdings koennte man noch eine Anfrage ins Unterforum "Shell und Programmieren" stellen, mit der Bitte um (Syntax-)Pruefung des Skripts.
Das sollte auch jetzt nicht irgend wie nach beleidigter Leberwurst klingen und ich schätze natürlich das Feedback von user_unknown, aber laut eigener Aussage hat er sich ja auch nicht alles im Detail angeschaut - kein Vorwurf - und nach meiner Meinung sollte halt Code nicht veröffentlicht werden, ohne dass er richtig gegen-gelesen wurde und wenigstens mal noch einer das Skript auch ausprobiert hat. Wenn das aus Kapazitätsgründen nicht möglich ist - was ich bei der Codelänge auch wirklich einsehen würde - dann ist es doch aber besser, solche Dinge nicht zu veröffentlichen. Das mit der Anfrage unter "Shell und Programmierung" kann man natürlich noch machen, habe ich halt bisher nicht, weil ich nicht zwei Threads zu einem Thema eröffnen wollte. Und bitte alles nicht als Vorwurf auffassen - wie gesagt, der Code ist eben auch lang und da ich das nicht professionell beherrsche unter Umständen auch nicht so leicht zu lesen. Gruß,
Martin
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! Und was soll jetzt geschehen? Scheint ja keine "Experten" zu geben, die sich hier im Wikiforum tummeln, um den Code auf Herz und Nieren zu prüfen. Mal in Shell und Programmieren nachfragen? so long hank
|
aasche
Anmeldungsdatum: 30. Januar 2006
Beiträge: 14259
|
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! Dann würde ich dafür plädieren, es unter Skripte ins Wiki aufzunehmen; "gefährlich" scheint es ja nicht zu sein... so long hank
|
Shakesbier
Anmeldungsdatum: 14. Juli 2008
Beiträge: 1165
|
Hallo ☺ Heinrich Schwietering schrieb: Dann würde ich dafür plädieren, es unter Skripte ins Wiki aufzunehmen
+1
|