Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   Oberbegriff für Enable/Disable (https://www.delphipraxis.net/204350-oberbegriff-fuer-enable-disable.html)

Rollo62 22. Mai 2020 06:49

AW: Oberbegriff für Enable/Disable
 
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 22. Mai 2020 08:00

AW: Oberbegriff für Enable/Disable
 
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 22. Mai 2020 12:11

AW: Oberbegriff für Enable/Disable
 
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 22. Mai 2020 13:59

AW: Oberbegriff für Enable/Disable
 
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 22. Mai 2020 14:53

AW: Oberbegriff für Enable/Disable
 
@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 22. Mai 2020 17:47

AW: Oberbegriff für Enable/Disable
 
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 22. Mai 2020 18:55

AW: Oberbegriff für Enable/Disable
 
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 23. Mai 2020 13:21

AW: Oberbegriff für Enable/Disable
 
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 23. Mai 2020 14:58

AW: Oberbegriff für Enable/Disable
 
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 23. Mai 2020 15:14

AW: Oberbegriff für Enable/Disable
 
Ist das mit DeepL übersetzt :shock:


Alle Zeitangaben in WEZ +1. Es ist jetzt 13:06 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz