Procedurbezeichnung

[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

[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

[r2c2]

Zitat von 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".

Sry, aber Workflow ist ein feststehender Begriff.

Zitat:

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.

Dann lies mal, was Luckie geschrieben hat. Über ne Property kriegst du genau diesen Bezeichner. Properties sind nämlich i.d.R. Substantive.

Zitat:

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

Also ich weiß ja nicht, wo du Grammatik gelernt hast, aber bei mir ist "is" definitiv ein Verb. 3. Person Singular. Präsens Aktiv von "to be".

Zitat:

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.

Ich gebe zu, dass das hier ein Grenzfall ist. Der Punkt ist jedenfalls, dass es ein Warnsignal ist, wenn Probleme hast, einen sinnvollen Namen zu vergeben.

Zitat von r2c2:

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.

Deshalb verwendet man Variablen um Werte mit passenden Namen zwischen zu speichern.

mfg

Christian

[Jumpy]

Also alle Meinungen über einen Kamm geschoren mental zusammenfassend, würde ich glaube ich der Klasse die Funktion als private und mit get im Namen spendieren und die Ergebnisse als nur lesbare Properties (Name dann ohne Get) nach aussen geben. Von aussen sieht das dann ja wie eine Variable aus (zumindest in Sprachen, wo hinter Funktionen immer noch ein () gehört).

[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.

[p80286]

Zitat von Jumpy:

Also alle Meinungen über einen Kamm geschoren mental zusammenfassend, würde ich glaube ich der Klasse die Funktion als private und mit get im Namen spendieren und die Ergebnisse als nur lesbare Properties (Name dann ohne Get) nach aussen geben. Von aussen sieht das dann ja wie eine Variable aus (zumindest in Sprachen, wo hinter Funktionen immer noch ein () gehört).

Das ist ja eigentlich nicht der Sinn der Sache, auch wenn eine "sprechende" Schnittstelle nicht zu verachten ist.
Wesentlicher ist ja eigentlich, daß der vollständige Sourcecode leicht lesbar und verständlich ist.

Gruß
K-H

[bernau]

Zitat von r2c2:

Sry, aber Workflow ist ein feststehender Begriff.

<scherz an>Wenn ich oft genug WorkFile schreibe, dann ist es bald auch ein feststehender Begriff<scherz aus>

Zitat von r2c2:

Dann lies mal, was Luckie geschrieben hat. Über ne Property kriegst du genau diesen Bezeichner. Properties sind nämlich i.d.R. Substantive.

OK, ich könnte ein Nur-Lese-Property verwenden statt einer Funktion.

Zitat von r2c2:

Also ich weiß ja nicht, wo du Grammatik gelernt hast, aber bei mir ist "is" definitiv ein Verb. 3. Person Singular. Präsens Aktiv von "to be".

Ähm... Ich werde mich bei meiner Schule beschweren.

Zitat von r2c2:

Zitat:

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.

Deshalb verwendet man Variablen um Werte mit passenden Namen zwischen zu speichern.

Du findest also folgendes besser zu lesen?

Code:

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

(Kratz am Kopf)

[p80286]

Delphi-Quellcode:

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

Delphi-Quellcode:

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

No soo schlimm ist das auch nicht.

Gruß
K-H

[bernau]

Zitat von 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.

ParamFilename ist auch ne Gute Idee.