Oberbegriff für Enable/Disable

[API]

Wie könnte ich eine Funktion benennen, welche ein Objekt entweder enabled oder disabled?

Variante 1:
// true, false als value übergeben

Delphi-Quellcode:

function enableobject(value)
begin

end;

Variante 2:
// true, false als value übergeben

Delphi-Quellcode:

function setenabled(value)
begin

end;

oder....?

[scrat1979]

Ich nenne solche Funktionen immer "Toggle" wie

Delphi-Quellcode:

procedure ToggleVisibility(AVisible : Boolean);
begin
[...]
end;

[himitsu]

Wie wäre es ganz klassisch mit einem Property "Enabled", inkl. SetEnabled und GetEnabled?

PS: Ob die Funktion Prozedur Enable/Activate/Visible/Show/... oder Disable/Deactivate/Hide/... im Namen hat, das hägt davon ab, was die Funktion Prozedur bei True macht.



"Toggle" und "Switch" ist für mich etwas, welches einen Status umschaltet, ausgehend vom aktuellen Zustand,
und das Andere würde ich eher "Set" benennen. (oder "Do", "Update", "Make", ...)

[API]

ich denke setEnabled(value: Boolean) passt.

[scrat1979]

Alles nette Vorschläge. Wie man sieht scheint es doch ordentlich auch Geschmacksache zu sein :)

Schönen Feiertag zusammen.

[Benmik]

Vermutlich ist Englisch hier Pflicht, aber bei mir heißt das

Delphi-Quellcode:

procedure SetzeAktiv(Aktiv:Boolean);

. Ich würde den Parameter auch sprechender machen, "If Aktiv" erscheint mir eingängiger als "If Value".

[Der schöne Günther]

Grade für Booleans bietet es sich generell an, die Namen mit dem Prefix "Is" oder "Has" zu versehen, also z.B. "IsEditable" oder "HasFluxcompensator"

Delphi-Quellcode:

TMyObject = class
   private var
      isActive: Boolean;
   public
      procedure setIsActive(const isActive: Boolean);
      function getIsActive(): Boolean;
end;

[jaenicke]

Zitat:

Zitat von scrat1979 (Beitrag 1465002)

Ich nenne solche Funktionen immer "Toggle" wie

Mit Toggle ist im Englischen aber eine Umschaltung in den jeweils anderen Zustand gemeint und nicht das Setzen eines bestimmten Wertes. Von daher passt das dafür nicht wirklich.

Zitat:

Zitat von Der schöne Günther (Beitrag 1465019)

Delphi-Quellcode:

TMyObject = class
   private var
      isActive: Boolean;
   public
      procedure setIsActive(const isActive: Boolean);
      function getIsActive(): Boolean;
end;

Und streng nach Styleguide:

Delphi-Quellcode:

type
  TMyObject = class
  private 
    FIsActive: Boolean;
    procedure SetIsActive(const AIsActive: Boolean);
    function GetIsActive: Boolean;
  public
    property Active: Boolean read GetIsActive write SetIsActive;
  end;

Der Unterschied zwischen Active und Enabled ist streng genommen:
Aktiv / active ist z.B. ein laufender Dienst oder Server. Aktiviert / enabled ist ein Dienst z.B., wenn er per Konfiguration auf automatisches Starten eingestellt ist (unabhängig davon, ob er gerade aktiv ist).

[himitsu]

Zitat:

Zitat von Benmik (Beitrag 1465009)

Vermutlich ist Englisch hier Pflicht, aber bei mir heißt das

Delphi-Quellcode:

procedure SetzeAktiv(Aktiv:Boolean);

. Ich würde den Parameter auch sprechender machen, "If Aktiv" erscheint mir eingängiger als "If Value".

Nee, eigentlich nicht, ABER

Wenn du eine Bibliothek hast, die ausschließlich verwendet wird, womit dann "nahezu" alles Deutsch ist, dann geht das schon.
So gab es schon mehrere Bibliotheken, um in der Schule totalen NOOBS das Programmieren beizubringen.
Haben die Schüler aber auch nur mal bissl Ahnung oder haben im Film/Internet schonmal was von QuellCodes gesehn, dann schreckst die mit Deutsch-Pascal extremst ab und Delphi stirbt mal wieder.

Da die Grundstrukturen der Syntax, sowie die komplette RTL und VCL englisch sind, passt da nunmal Englisch auch am Besten rein.

Ich hatte es auch mal zwanghaft mit Deutsch versucht, aber es ist einfach zu hässlich, so dass es mich schmerzte.


Ob ich nun Kommentare und InCode-Dokumentation in Deutsch oder Englisch mache, das kommt auf die Zielgruppe an.

• Code nur für dich -> deine Muttersprache ist kein Problem (du bist ja der Einzige)
• in einer Firma nur mit deutschen Mitarbeitern -> joar, geht schon (bis dann mal ein Nichtdeutschverstehender mitmachen will, außer man legt einfach Deutsch als Amtssprache fest)
• Code für öffentliche Komponenten -> tja, da Herr H. nicht weltweit Deutsch einführen konnte und das mit dem Esperanto leider auch nicht funktionierte, bleibt nur noch die Weltsprache Chinesisch ähhhh Englisch :stupid:,
  was auch wieder praktisch ist, da die Funktion dann in der Dokumentation gleich heißt

[scrat1979]

@Jaenicke

Der Vollständigkeit halber möchte ich erwähnen, dass ich bei eigenen Klassen selbstverständlich mit entsprechenden Properties inkl. Getter und Setter arbeite. Außerhalb davon mache ich es wie oben erwähnt um zum Beispiel auf der MainForm Buttons zu Enablen/Disablen. Streng genommen lautet Toggle umschalten. Das ist richtig. Hat sich bei mir aber so über die Jahre etabliert...

[Rollo62]

Zitat:

Zitat von jaenicke (Beitrag 1465020)

Der Unterschied zwischen Active und Enabled ist streng genommen:
Aktiv / active ist z.B. ein laufender Dienst oder Server. Aktiviert / enabled ist ein Dienst z.B., wenn er per Konfiguration auf automatisches Starten eingestellt ist (unabhängig davon, ob er gerade aktiv ist).

Für mich ist das nicht unbedingt mit "Automatisch" verknüpft.

Enabled - Erlaubt erstmal das Starten generell (automatisch oder manuell)
Active - Mache es dann wirklich, aber kann nur wenn es Enabled ist

[Hobbycoder]

Also ich würde, wenn es geht, immer dem Object die Property "enabled" geben und diese dann im Programm setzen/abfragen. Dann ist es immer ähnlich allen anderen Objekten, die es so gibt.

Wenn das nicht geht, dann würde ich die Funktion immer äquivalent zum Einsatzzweck des Objekts benennen.
z.B.

Delphi-Quellcode:

enableBottomPanel(value: Boolean);

Wenn ich aber zusätzlich zur bereits vorhandenen Property "enabled" noch eine weiter Eigenschaft benötige, die nicht direkt das Enable des Objekts verändern soll, dann nehme ich als neue Property "usable" hinzu, die nur kennzeichnen soll, ob das Object innerhalb des Codes verwendet werden soll (sonst aber Enabled bleiben soll).

[jaenicke]

Zitat:

Zitat von Hobbycoder (Beitrag 1465037)

Also ich würde, wenn es geht, immer dem Object die Property "enable" geben

Du meinst Enabled, oder? Denn enable ist ja ein Verb und somit der Befehl etwas zu aktivieren. Genauso ist enableBottomPanel zum Deaktivieren per Parameter nicht intuitiv.

Du sagst ja auch nicht zu jemandem:
Schalte mal bitte den Lichtschalter ein und setze den Wert auf aus. ;-)

Um hier unnötige Irritationen und damit unnötigen Aufwand zu vermeiden ist es wichtig, dass man darauf achtet, dass die Benennung auch sprachlich korrekt ist und nicht nur Worte aus dem Englischen verwendet.

Besser wäre also z.B. SetBottomPanelEnabled(AValue).

[Hobbycoder]

Zitat:

Zitat von jaenicke (Beitrag 1465049)

Zitat:

Zitat von Hobbycoder (Beitrag 1465037)

Also ich würde, wenn es geht, immer dem Object die Property "enable" geben

Du meinst Enabled, oder?

Ja, das war ein Tippfehler

Zitat:

Zitat von jaenicke (Beitrag 1465049)

Genauso ist enableBottomPanel zum Deaktivieren per Parameter nicht intuitiv.

Jain. Wenn es z.B.

Delphi-Quellcode:

enableBottomPanel:=False

oder

Delphi-Quellcode:

 SetEnableBottomPanel(False)

geben würde, wüßte ich nicht was man daran nicht verstehen sollte.

Es ging mir um's Prinzip, und nicht die richtige Grammatik. Das kann doch wohl am Ende jeder für sich entscheiden.

[Moombas]

@Hobbycoder: Wäre dann nicht (um bei deinem Beispiel zu bleiben) folgendes schöner:

Delphi-Quellcode:

BottomPanel.Enable
BottomPanel.Disabel

Oder wie es aktuell in Delphi auch schon existiert:

Delphi-Quellcode:

BottomPanel.Enabled := TRUE; //Bzw. FALSE

[HeZa]

Hallo Hobbycoder,

Zitat:

Zitat von Hobbycoder (Beitrag 1465059)

Jain. Wenn es z.B.

Delphi-Quellcode:

enableBottomPanel:=False

oder

Delphi-Quellcode:

 SetEnableBottomPanel(False)

geben würde, wüßte ich nicht was man daran nicht verstehen sollte.

Es ging mir um's Prinzip, und nicht die richtige Grammatik. Das kann doch wohl am Ende jeder für sich entscheiden.

Wenn es dir um das Prinzip geht, dann hat die Grammatik eine Bedeutung. Wenn du der Meinung bist, dass kann am Ende jeder für sich entscheiden, dann ist die Grammatik und auch das Prinzip egal. Dann kannst du dein Property/Methode auch Hurz nennen und damit funktionierenden Code für ein tolles Programm schreiben. Das ist, wenn mal alleine programmiert und seine Quellen nicht rumzeigen will auch völlig in Ordnung.

Möchtest du leicht verständlichen Code im Kontext von Delphi schreiben, dann sollte ein Property BottomPanelEnabled und ein Setter SetBottomPanelEnabled heißen, weil dass Delphi Programmierer so aus den Standard-Delphi-Libs und den Libs von Drittanbietern kennen.

Beispiele
(Delphi)
Application.Terminate - Prozedur, beendet die Anwendung
Application.Terminated - Eigenschaft, gibt an ob die Anwendung schon im runterfahren begriffen ist

(IBDAC)
Connection.Connect - Prozedur, baut ein Datenbankverbindung auf
Connection.Disconnect - Prozedur, baut ein Datenbankverbindung ab
Connection.Connected - Eigenschaft, gibt an ob eine Datenbankverbindung besteht
Connection.Connected := True, baut ein Datenbankverbindung auf
Connection.Connected := False, baut ein Datenbankverbindung ab

Schau in die Libs die du nicht selbst geschrieben hast und du wirst noch mehr Beispiele finden. Bestimmt gibt es aber auch irgendeine Fremdbibliothek die das anders machen. Können wir nicht verhindern, aber wir können darauf achten es selbst besser zu machen. Zumal es einfach ist.

für deinen Fall wäre follgendes alles in Ordnung (wenn es um das Prinzip geht):
BottomPanelEnabled := True;
BottomPanelEnabled := False;
SetBottomPanelEnabled(True);
SetBottomPanelEnabled(False);
EnableBottomPanel;
DisableBottomPanel;

Für die IsEnabled Variante wird dich auch keiner schlagen, BottomPanleEnable := True würde ich natürlich auch verstehen (ich würde auch raus finden was BottomPanelHurz macht :-) ), würde aber beim ersten Lesen erst einmal prüfen, ob dass das tut was ich erwarte und mir dann dann denken, können sich die Leute nicht mal an die einfachsten Prinzipien halten. :-D

Es gibt aber auch Wörter, bei denen es einfach nicht so gut passen will und dann sind wir noch nicht mal native english speaker.

Connect, Disconnect, Connected - super
Enable, Disable, Enabled - auch gut
Show, Hide, Visible - hm, ging das nicht schöner? Drei ganz verschieden Wörter die sich um die selbe Sachen drehen, muss das sein (Ja)

In solchen Fälle, überlege ich ob es da etwas etabliertes gibt, bevor ich selber kreativ werde. Ich habe schon vielen englischen Begriffen ein Mehrzahl s gegönnt, die es nicht verdient hätten. Heute schaue ich vorher lieber mal bei https://www.leo.org/englisch-deutsch vorbei oder besser https://www.linguee.de/, da gibt es dann meistens auch Verwendungsbeispiele in verschieden Kontexten.

Ciao Heinz

[Delbor]

Hi zusammen

Gesucht ist hier ein Oberbegriff für Enabled. Also etwa: Wie könnte eine Prozedure/Funktion genannt werden, die entsprechende Umschaltungen an verschiedenen Komponenten vornimmt. Zum Bleistift ein Edit, ein Memo und diverse Buttons/Menues, um besagte Komponenten zu bearbeiten.
Klar kann man jetzt eine Klasse bauen, die diese Umschaltungen vornimmt und damit sind auch die Setter- und Getter-Methoden klar. Aber was ist mit einer Methode ausserhalb einer speziellen Klasse, die eine bestimmte Komponentengruppe(n) übernimmt und bearbeitet? diese Methode dürfte sollte weder mit dem Präfix 'Set' noch mit 'Get' beginnen.

Es ist mir auch schon passiert, dass ich nach der Klasse eines vermeintlichen Setters gesucht habe. Seither gibts keine Methode 'SetEditVisible' mehr - es sei denn, als Setter in einer Klasse - sondern allenfalls ein 'Displayedit', auch wenn Display für 'Anzeigen' nicht unbedingt das richtige Wort ist.

Gruss
Delbor

[Benmik]

Zitat:

Zitat von himitsu (Beitrag 1465021)

Nee, eigentlich nicht, ABER

Allem, was du sagst, kann ich zustimmen. Naja, fast. Ich bin in der glücklichen Lage, dass niemand anderes je meinen Code lesen wird, also bin ich völlig frei. Das geht anderen nicht so, und das kann und muss man akzeptieren.
Ich denke aber, dass der Gedanke eine große Rolle spielt, dass alles andere als Englisch auch unprofessionell wirken könnte, nein, würde. Viele hier glauben sicherlich an Englisch und an nichts anderes, aber selbst wenn sie es nicht täten, würden die meisten es nicht wagen, öffentlich deutschen Code zu verwenden. Auch wenn sie, was man immer wieder sieht, im Englischen nicht gerade firm sind.

Zitat:

...mit Deutsch versucht, aber es ist einfach zu hässlich, so dass es mich schmerzte.

Diese Aussage über die eigene Muttersprache ist sehr deutsch-spezifisch. Hierzu und insbesondere zu Englisch hätte ich viel zu sagen, aber dazu ist ein Programmierforum definitiv eins der falschesten Foren, die man sich dazu aussuchen kann.

[himitsu]

Neee neee, nicht das "Deutsche" war daran so grässlich unschön, sondern der Mischmasch des Denglischen.

Schade dass es keinen Precompiler geben kann, sonst könnte man die Syntax des Pascal und die Units der RTL/VCL/... entsprechend der geliebten Sprache anpassen. :stupid:

Delphi-Quellcode:

Prozedur MeineWelt(DerParameter: Zahl);
Variable
  schön: Zweierdingens;
Anfang
  schön := DerParameter > 0;
  Wenn schön und MeinFenster.IstSichtbar dann
    MeinFenster.ZeigeAn(DerParameter);
Ende;

Aber das hat wieder andere Probleme (außer der Compiler/Interpreter unterstüzt alle Sprachen gleichermaßen und kann es übersetzen)
wie z.B. Basic des MS-Office, wo man sie Scripte in seine Sprache schreiben konnte, aber das Teilen dieser Scripte ist echt bescheiden,
denn was will ein Russe in seinem russischen Excel mit deinem deutschen Basic, wo weder er noch sein Excel das verstehen?

Und für das, was du grade brauchst, gibt es ein Tutorial mit Codebeispiel, aber blöder weise immer in der falschen Sprache, womit du die genannten Funktionen/Befehle bei dir nicht findest.

[Rollo62]

Ist das mit DeepL übersetzt :shock: