Bennennung von Prozeduren

Diskussionen über Programmierstil (Code-Formatierung, Namenskonventionen, ...)

Bennennung von Prozeduren

Beitragvon Josef Pötzl » Do 25. Mär 2010, 17:55

Hallo!

Für die Namen von public Prozeduren (in einem Modul oder einer Klasse) schlage ich vor, auf Präfixe wie "f", "fnc" "sub" usw. zu verzichten. Das schränkt meiner Ansicht nach nur ein, dass man später eine Sub nicht mehr zu eine Function machen kann, da sonst das Präfix keinen Sinn mehr macht - und eine Umbenennung ist bedenklich, da sonst alle abhängigen Module Probleme bekommen, falls der alte Name nicht mehr verfügbar ist.
Außerdem sehe ich keinen Vorteil bei so einem Präfix. Das sind für mich nur Zeichen, die ich vollständig eintippen muss, um erst dann Unterstützung von IntelliSense zu bekommen.

Präfixe die eine "Gruppe" vorgeben, halte ich allerdings durchaus für sinnvoll.
z. B. für die Ersatzfunktionen für DLookup:
DaoLookup ... die DAO-Variante von DLookup
AdoLookup ... die ADODB-Variante


Was meint ihr dazu?
Josef Pötzl
Moderator
 
Beiträge: 764
Registriert: Mo 30. Nov 2009, 10:08
Wohnort: Klagenfurt
Accessversion: 2010 (2013)

Re: Bennennung von Prozeduren

Beitragvon Michael Sapich » So 11. Apr 2010, 16:56

Hallo zusammen,

auf Präfixe wie "f", "fnc" "sub" usw. zu verzichten
ist meiner Meinung nach ok, da ja jeder bei Verwendung einer Funktion resp. Prozedur wissen sollte, was er da aufruft.
So wie Josef geschrieben hat, kommt man dann per IntelliSense schneller zum "getippten" Ergebnis.

später eine Sub nicht mehr zu eine Function machen kann
finde ich nicht so toll. Wenn eine Prozedur als Prozedur festgelegt worden ist, sollte dies auch zukünftig so bleiben. Ein "neuer" Rückgabewert kann ja auch als Optional Parameter festgelegt werden bzw. kann eine neue Funktion dann als "Wrapper" über die Prozedur gelegt werden, welche dann den gewünschten Rückgabewert liefert.
Michael Sapich
 
Beiträge: 1
Registriert: Mi 31. Mär 2010, 20:58
Wohnort: Dobel
Accessversion: von 95 bis 10

Re: Bennennung von Prozeduren

Beitragvon Josef Pötzl » Mo 12. Apr 2010, 09:28

Hallo!

[etwas OT]

Wenn eine Prozedur als Prozedur festgelegt worden ist, sollte dies auch zukünftig so bleiben.

Warum sollte man eine Sub nicht zu einer Function ändern dürfen?
Ich sehe da keinen Schnittstellenkonflikt, da sich für jene Prozeduren, die zuvor die Sub verwendeten, nichts beim Aufruf ändert. (Die Funktionalität der Prozedur muss natürlich erhalten bleiben.)
Eine Erweiterung per optionalen Parameter ist zwar auch möglich, hat aber den Nachteil, dass man dann für den Rückgabewert immer eine Hilfsvariable benötigt.

Beispiel (nur Prinzip):
Angenommen es existiert so eine Prozedur:
Code: Alles auswählen
Private Sub UpdateData(ByVal IdWert As Long, ByVal WertVonXYZ as Variant)
   strSQL = "update ...."
   db.Execute strSQL, dbfailonerror
End Sub


Nun kommt jemand beim überarbeiten des Code auf die Idee, dass es vielleicht ganz praktisch wäre, wenn man als Rückgabe die Anzahl der geänderten Datensätze erhält.
Code: Alles auswählen
Private Function UpdateData(ByVal IdWert As Long, ByVal WertVonXYZ as Variant) as Long
   strSQL = "update ...."
   db.Execute strSQL, dbfailonerror
   UpdateData = db.RecordsAffected
End Function

Damit kann diese Function-Prozedur so verwendet werden:
Code: Alles auswählen
if UpdateData(123, "abc") = 0 then
   InsertData 123, "abc"
end if


Ein weiteres Beispiel wäre, wenn man den Erfolg einer Aktion mittels True/False als Rückgabewert mitteilen möchte.

Die Rückgabe mit Function finde ich übersichtlicher als:
Code: Alles auswählen
Private Function UpdateData(ByVal IdWert as long, byval WertVonXYZ as variant, Optional ByRef RecordsAffected as long)
   strSQL = "update ...."
   db.execute strSQL, dbfailonerror
   RecordsAffected = db.RecordsAffected
end Function

mit
Code: Alles auswählen
dim lngRC as long
UpdateData 123, "abc", lngRC
if lngRC  = 0 then
   InsertData 123, "abc"
end if


Die letzte Variante ist natürlich ebenso möglich. Da mit der Function-Prozedur aber die Schnittstelle der Sub-Prozedur nicht verletzt wird, fällt mir kein Grund ein, warum eine Sub immer eine Sub bleiben muss.

Übersehe ich etwas?

mfg
Josef
Josef Pötzl
Moderator
 
Beiträge: 764
Registriert: Mo 30. Nov 2009, 10:08
Wohnort: Klagenfurt
Accessversion: 2010 (2013)

Re: Bennennung von Prozeduren

Beitragvon Dmitry » Mi 25. Jun 2014, 18:56

Ist zwar altes Beitrag, aber wollte noch etwas dazu schreiben.

Um "Coden" zu erleichtern, ich persönlich benutzte überhaupt keine Subs. (außer temporär für Testfälle mit F8 und Debugger)
und immer mit klammer aufrufen (mit Call FunctionName(params) , falls Rückgabe nicht interessiert)
Damit hat man keinen "mal so mal so" also mit klammer oder ohne klammer Functionsaufrufe.
Je weniger Regeln/Typen desto leichter ist alles zu merken und lesen => leichter programmieren.

Und noch dazu die Methoden/Funktionen benenne ich mit Großbuchstaben am Anfang, weil VBE irgendwie die Namen auf Andere Objekte überträgt, und selbst ändert.
D.h. Wenn ich myObject.removeAll habe, und dictionaryObj.RemoveAll aufrufe, dann wird auf ein mal mein Methodenaufruf von dem Dictionary Object mit .removeAll ersetzt.
Damit kommen auch Probleme mit Versioncontrol, weil das ständig mal groß mal kleingeschrieben wird.
Und alle Access Objekte haben auch alle Methoden mit Großbuchstabe am Anfang.

Vielleicht kennt jemand eine VBE Feature, wo mit diese automatische Änderung abschalten kann?
Dmitry
 
Beiträge: 14
Registriert: Fr 9. Mai 2014, 11:15
Wohnort: Nürnberg
Accessversion: 2007, 2010
Access-Erfahrung: Experte

Re: Bennennung von Prozeduren

Beitragvon Sten Schmidt » Do 26. Jun 2014, 16:03

Hallo,


Dmitry hat geschrieben:Vielleicht kennt jemand eine VBE Feature, wo mit diese automatische Änderung abschalten kann?


Dieses "Feature" lässt sich IIRC leider nicht deaktivieren.
Sten Schmidt
Entwickler
 
Beiträge: 140
Registriert: Do 18. Mär 2010, 22:24
Accessversion: 2007, 2010
Access-Erfahrung: Experte


Zurück zu Programmierstil

cron