Eigentlich erübrigt sich jede weitere Diskussion mit diesem Argument. Mit ordentlich implementierten Unit-Tests sollten keine Fehler, insbesondere dieser Art, auftauchen.
Der Sinn der Unterroutine war die beiden Changing-Parameter aus den lokalen Variablen zu füllen. Für ein Gültigkeitspräfixing kenne ich die übliche Verwendung "g_" für global, "m_" für Gültigkeit in einer Klasse, "l_" für lokale Gültigkeiten. Eins der 3 Präfixe kann man sich schenken, wenn die anderen beiden nur konsequent durchgeführt werden und man für das 3. Präfix nur verbietet im Namensraum der beiden anderen zu sein. Z.B. könnte man lokale Variablen in der Bezeichnung fast frei wählbar lassen wenn man nur verbietet mit g_ oder m_ zu beginnen. Dies alles kann recht einfach mit der Standardauslieferung des Codeinspektors eingestellt werden.
Irgend etwas an dieser Art Aussage kommt mir bekannt vor.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
qyurryus
@Ralf: Ich mache das leider auch viel zu oft, aber diese Benamung gehört dem Entwickler um die Ohren gehauen.ralf.wenzel hat geschrieben: ↑08.05.2019 17:05name_warenempf = get_name_from_lifnr( lifnr_warenemfp ).
So sehr ich auch gegen die HN bin, halte ich diese Begründung dennoch für falsch. In meiner Jugendzeit habe ich viel Basic programmiert, auf dem C64, dem Schneider CPC, dem Amiga. In keinem Basic-Dialekt habe ich jemals HN gesehen.Daniel hat geschrieben: ↑07.05.2019 18:00This kind of prefixing is a relic from the early days of programming, when code was printed out and read on paper, and you didn't want to flip around just to find some variable's type. Modern development environments give easy access to data types, signatures, and object navigation, such that it is no longer needed to get readable code.
Kann man nicht oft genug wiederholen.
Code: Alles auswählen.
result = (table_instance)->read( selkrit ).
Dann hast Du unterschiedliche Aufrufstellen. Ein SELECT ist ein Befehl. Ein Aufruf des gemeinsamen SELECTs ist ein Befehl. Du ersetzt also einen Befehl durch einen anderen, spart nichts, fügst aber eine Abstraktionsschicht hinzu, die die Sache unübersichtlicher macht. Da haste nichts gewonnen.Nun sind viele dieser Tätigkeiten aber (abstrakt betrachtet) einer gewissen Ähnlichkeit unterworfen. Praktisch jede DB-Selektion endet in einem SELECT und der hat immer denselben schematischen Aufbau. Was also liegt näher als ein (!) generischer SELECT, der von allen verwendet wird?
Ich weiß, dass du kein Freund davon bist - ich habe die Vorteile einer einheitlichen Persistenzschicht kennengelernt und wurde davon überzeugt. Einen Vorteil habe ich genannt: Im Grunde interessiert mich das Medium nicht, auf dem Daten gespeichert sind, wenn ich auf Ebene der Geschäftsobjekte hantiere.DeathAndPain hat geschrieben: ↑20.05.2019 13:02Dann hast Du unterschiedliche Aufrufstellen. Ein SELECT ist ein Befehl. Ein Aufruf des gemeinsamen SELECTs ist ein Befehl. Du ersetzt also einen Befehl durch einen anderen, spart nichts, fügst aber eine Abstraktionsschicht hinzu, die die Sache unübersichtlicher macht. Da haste nichts gewonnen.
Doch, du gewinnst was. Nämlich die Möglichkeit, den SELECT durch einen festen Datensatz (oder Datensätze) für Unit-Tests zu ersetzen:DeathAndPain hat geschrieben: ↑20.05.2019 13:02Das von Dir angeführte Beispiel mit dem SELECT finde ich freilich nicht gut gewählt:Dann hast Du unterschiedliche Aufrufstellen. Ein SELECT ist ein Befehl. Ein Aufruf des gemeinsamen SELECTs ist ein Befehl. Du ersetzt also einen Befehl durch einen anderen, spart nichts, fügst aber eine Abstraktionsschicht hinzu, die die Sache unübersichtlicher macht. Da haste nichts gewonnen.Nun sind viele dieser Tätigkeiten aber (abstrakt betrachtet) einer gewissen Ähnlichkeit unterworfen. Praktisch jede DB-Selektion endet in einem SELECT und der hat immer denselben schematischen Aufbau. Was also liegt näher als ein (!) generischer SELECT, der von allen verwendet wird?