Procedurbezeichnung

[bernau]

@Luckie: Workfile (Arbeitsdatei) ist die Datei, die grade bearbeitet wird und ist eine Funktion innerhalb einer Klasse.

@Jumpy: Hast recht. WorkFileName wäre eigendlich besser.

@DeddyH: An eine Aufzählung habe ich auch schon gedacht. Dann wieder verworfen. Denke aber, das ist die besste Lösung. Wäre interessant zu wissen, ob so ein Type schon irgendwo definiert ist.

[r2c2]

Mit der Benennung stimmt da so einiges nicht. "WorkFile" heißt "ArbeiteDatei". Das ist unverständlich. Wenn du "Arbeitsdatei" ausdrücken wolltest. so wäre das WorkingFile oder (mehr oder weniger) CurrentFile. Aber auch das ist nichts für eine Funktion. Eine Funktion sollte i.d.R. ein Verb im Namen haben, denn sie ist nichts, sondern tut etwas. Und das mit File und FileName wurde ja schon gesagt. Also wenn dann getWorkingFileName oder getCurrentFileName.

Boolean-Parameter halte ich für eine ganz schlechte Idee. Die Dinger sind Kontrollkopplunten und zudem schlecht lesbar. Siehe hier: http://www.christian-rehn.de/2011/09...sie-vermeiden/ und hier: http://martinfowler.com/bliki/FlagArgument.html

Auch enum-Parameter halte ich nicht für gut. Das sind nämlich immer noch Kontrollkopplungen und zeugen davon, dass die Funktion etwas tut, was eigentlich nicht ihre Aufgabe ist. ==> SingeResponsibilityPrinciple

Ich würde deshalb immer, wenn cih mit Datennamen arbeite den kompletten Pfad zurück geben und ggf. ExtraxtFileXY anwenden. Wenn du das immer so tust, ist auch immer klar, was passiert. Wenn es Ausnahmen gibt (was giobt die Funktion nochmal zurück?) entstehen unnötige Leichtsinnsfehler.

mfg

Christian

[Luckie]

Und wie heißt die Klasse? Wie wäre es mit CurrentFilename und CurrentFilePath als Bezeichnungen für die Properties? Und wenn die dahinter liegende Methode sicherstellt, dass CurrentFilePath sicherstellt, dass der Pfad mit einem Backslash endet, dann kann man das ganze ohne Probleme zusammensetzen.

[bernau]

Zitat von Luckie:

Und wie heißt die Klasse?

OK, jetzt muss ich etwas ausholen

Die Klasse nennt sich "TccParamStr". Die Klasse kapselt Funktionen um die Komandozeilenparameter (gelesen mit ParamStr(x)) besser auswerten zu können.

Komoandozeilenparameter gibt es in der Regel in drei verschieden Arten. (Bei mir zumindest.)

1) Parameter ohne Wert: z.B. "debug" oder "ShowError"

2) Parameter mit Wert: z.B. "Value=1"

3) Dateinamen. (z.B. weil über den Explorer eine Datei auf die EXE gezogen wurde)

Die Parameter können in einer beliebigen Reihenfolge erscheinen.

Wenn ein Dateiname übergeben wurde, dann ist das in der Regel die Datei die bearbeitet werden soll. Deshalb der Name "WorkFile". (Jetzt WorkingFileName )

D.h. die Funktion sucht aus allen übergebenen Parametern den heraus, der einen Dateinamen beinhaltet. Der wird in "WorkingFileName" zurück gegeben.

[Luckie]

Spar dir das Working. Oder gibt es noch Dateinamen, die nicht bearbeitet werden? Es kann doch immer nur eine Datei geben.

[bernau]

Nur "Filename" ist mir zu pauschal. Könnte ja auch die Datei gemeint sein, die sich in ParamStr(0) befindet

[Luckie]

Zitat von bernau:

Nur "Filename" ist mir zu pauschal. Könnte ja auch die Datei gemeint sein, die sich in ParamStr(0) befindet

Aber der Parameter wird ja nicht so in der Klasse rumfliegen als Property oder? Und wenn doch, dann würde ich die Bezeichnung ParamFilename wählen.

[bernau]

Zitat von r2c2:

Mit der Benennung stimmt da so einiges nicht. "WorkFile" heißt "ArbeiteDatei". Das ist unverständlich. Wenn du "Arbeitsdatei" ausdrücken wolltest.

Na ja. Man sagt ja auch Workflow. Und das heist ja auch nicht "ArbeiteAblauf" sondern "ArbeitsAblauf".

Zitat von r2c2:

Eine Funktion sollte i.d.R. ein Verb im Namen haben, denn sie ist nichts, sondern tut etwas. Und das mit File und FileName wurde ja schon gesagt. Also wenn dann getWorkingFileName oder getCurrentFileName.

Dann müsste ja jede Function ein "Get" im Namen beinhalten, weil Sie ja immer etwas macht und zurückgibt. Ein WorkingFilename finde ich leserlicher als GetWorkingFilename.

Es gibt auch Funktionen, die geben einfach einen Zustand zurück. Da schreibe ich doch eher "IsHot" als "GetIsHot". Da ist nichts mit Verb.

Zitat von r2c2:

Boolean-Parameter halte ich für eine ganz schlechte Idee. Die Dinger sind Kontrollkopplunten und zudem schlecht lesbar. Siehe hier: http://www.christian-rehn.de/2011/09...sie-vermeiden/ und hier: http://martinfowler.com/bliki/FlagArgument.html

Hast mich überzeugt.

Zitat von r2c2:

Auch enum-Parameter halte ich nicht für gut. Das sind nämlich immer noch Kontrollkopplungen und zeugen davon, dass die Funktion etwas tut, was eigentlich nicht ihre Aufgabe ist. ==> SingeResponsibilityPrinciple

Warum sollte es nicht Aufgabe der Funktion sein, eine Rückgabeeigenschaft auszuwerten.

Zitat von r2c2:

Ich würde deshalb immer, wenn cih mit Datennamen arbeite den kompletten Pfad zurück geben und ggf. ExtraxtFileXY anwenden. Wenn du das immer so tust, ist auch immer klar, was passiert. Wenn es Ausnahmen gibt (was giobt die Funktion nochmal zurück?) entstehen unnötige Leichtsinnsfehler.

Auch das sehe ich anders. Wenn ich oft Funktionen verschachteln muss, dann mache ich daraus eine neue Funktion. Was kann man besser lesen.

Code:

result:=comparetext(ExtractFileDir(WorkingFileName),ExtractFileDir(EineAndereDatei))=0;

result:=comparetext(WorkingFileDir,EineAndereDateiDir)=0;

Ich finde, das Zweite Beispiel ist besser zu lesen.

[Luckie]

Meinen Beitrag hast du gelesen?

[bernau]

Zitat von Luckie:

Meinen Beitrag hast du gelesen?

Hey, ich bin ein alter Mann. Ich bin nicht so schnell

CurrentFilename und CurrentFilePath ist OK, aber auch die muss man zusammensetzen. DAnn finde ich eine weitere Funktion CurrentFileFullPath besser