Diskussion:Namenskonvention (Datenverarbeitung)

Zu einseitig (erl.)

Ich finde, der Artikel bezieht sich zu einseitig auf Programmiersprachen. Namenskonventionen begegnen einem überall im Leben, wo sprechende und eindeutige Namen gefordert sind, z.B. bei Telefonnummern oder den lateinischen Tier- und Pflanzennamen.
(Der vorstehende Beitrag wurde am 3.2.2006, 17:05 [MEZ] abgesendet.)

Dieser Abschnitt hier sollte wohl, spätestens mit der (Eintrags- oder auch Seiten-)Umbenennung – oder auch sogenannten Verschiebung, vor mittlerweile über zehn Jahren :-) … am 13.6.2008  – von „Namenskonvention“ nach „Namenskonvention (Datenverarbeitung)“,^[1] erledigt sein. Liebe Grüße. -- Abmühung, am 2.11.2018, 05:19 (MEZ)

Kamelhöckernotation

Der Begriff (aus den derzeit ungesichteten Änderungen) ist so im Deutschen eher unbekannt, wie auch eine Websuche offenbart. Es ist mehr eine humorige Direktübersetzung aus dem Englischen. Hier ist als Fachbegriff IMHO auch "Camel-Case" gebräuchlich (vgl. auch Artikel Binnenmajuskel). --bsd

Ungarische Notation

Microsoft rät zur Vermeidung der ungarischen Notation nicht nur in C#, sondern auch in VB .NET wird in den aktuellen Entwicklungsrichtlinien keine ungarische Notation verwendet. (nicht signierter Beitrag von 193.26.47.75 (Diskussion) 14:42, 30. Apr. 2012 (CEST))

Fortran

Auch eine Namenskonvention gab es sviw. mal im Fortran, wo z.B. doubles mit d, e und f beginnen sollten oder alles Integer war, was mit i, j, k begann, wobei man den Bereich mit dem Kommando DEFINT ausweiten oder umdefinieren konnte. Ich bin allerdings im Fortran nie fluessig gewesen und selbst das bisschen ist ziemlich verblasst, so dass ich kaum noch ein "Hello World" mit "print using" zum Laufen bekommen wuerde. Auch wenn es nicht gerade modern ist, war es dennoch eine Namenskonvention und wenn es jemand ergaenzen koennte, waere das schon gut. -- 194.8.205.13 09:22, 12. Aug. 2014 (CEST)

Einleitung usw

Hallo, in der Einleitung fällt mir einiges auf. Schon in der ersten Zeile wird die Freiwilligkeit der Anwendung und gleichzeitig 'Nomenklatur' genannt - zu der beschrieben ist, sie sei 'verbindlich'. Mein Vorschlag für die Einleitung:

Namenskonventionen sind Festlegungen/Vorschriften/Empfehlungen für Programmierer, Datenbankentwicklern etc. für die Benennung von Bezeichnern für Objekte, Variablen, Konstanten und andere Teile des Quelltextes. Damit soll anhand der Namen (Bezeichner) deren Verwendung im Programm nzw. in der Datenbank erkannt werden. Ähnliche Konventionen, die auch verbindliche Nomenklaturen sein können, gibt es zum Einrückungsstil und zum Einfügen von Kommentaren in den Quelltext von Programmen, um deren Lesbarkeit und Nachvollziehbarkeit zu erhöhen.

In der Regel gibt es für jede Entwicklungsumgebung bestimmte Namenskonventionen. Sie sind strukturell/methodisch ein Bestandteil der Programmierrichtlinien und können je nach Situation/Unternehmen verbindlich vorgegeben oder zur freiwilligen Anwendung formuliert sein.

Darüberhinaus passt in dieses Lemma auch der Aspekt 'sprechende Bezeichner' - der derzeit als Löschantrag diskutiert wird. --VÖRBY (Diskussion) 16:10, 30. Okt. 2018 (CET) Siehe folgender Abschnitt.

Zusätzlich die Reddick-Namenskonvention erwähnen und verlinken (statt siehe auch).--VÖRBY (Diskussion) 19:14, 2. Nov. 2018 (CET)

Andere Namensregeln

Textvorschlag hierfür:

Weitere, oft nur als Empfehlung gedachte Vorgaben zur Benennung von Objekten im Quelltext können sein:

„Sprechende“ Objektbezeichner

Die Bezeichner/Namen sollten weitgehend „sprechend“ gewählt werden und damit mehr oder weniger „selbsterklärend“ für ihre Verwendung sein. Dazu kann festgelegt werden, welche Elemente diese Bezeichner enthalten sollen, in welcher Reihenfolge diese zu benennen sind, ob einzelne Bestandteile des Bezeichners z. B. mit Bindestrichen getrennt werden, ob Abkürzungen zu verwenden sind und welche.
Derartige Empfehlungen gelten, meist unternehmens- oder projektspezifisch, im Wesentlichen für Datenfelder wie Variablen, grundsätzlich aber für alle mit einem Bezeichner zu benennenden Objekte (auch für Konstanten, Befehlstextabschnitte, Funktionen und Prozeduren u. a.).
Beispiel und Gegenbeispiel: MWSt-Betrag = RechBetragNto * MWStProzent anstatt Betrag1 = Betrag2 * Prozent.

Zu deiner Frage mit „so in den Artikel übernehmen(?)“, in der Zusammenfassung deiner vorherigen Änderung hier:^[2] Also ich denke dafür braucht eigentlich – in einem freien Wiki – niemand Fragen. Sei einfach mutig und der Rest kommt dann schon – mehr oder weniger – von alleine. :-)

Übrigens (vor allem) den abschließenden Teil in deiner letzten Zeilen hier würde ich dann aber eher wie folgt schreiben:

Beispiel – und Antimuster oder, wohl (wenigstens für mich) leichter verständlich – mit Gegenbeispiel: MWSt-Betrag = ReBetrNto * MWStProzent anstatt Betrag1 = Betrag2 * Prozent

… also ebenda hauptsächlich nur die auch sogenannten Quellcode-Teil eben mit <code>…</code> umschließen. Zudem kann dann wohl der Punkt am Zeilenende, in einem derartigen „Beispiel: …“, einfach weggelassen werden. Und was die Abkürzungen (darüberhinausgehend, auch im Allgemeinen) angehen, so wäre es wohl ratsam (wenigstens mir fremde oder auch schwer bis unverständliche) Ausdrücke wie ‚ReBetrNto‘ möglichst nahe an der zugehörigen (Erst-)Beschreibung (oder auch sogenannten [Variablen-]Deklaration) eben wenigstens einmal vollständig (vor allem auch für andere und fremde Entwickler) wenn möglich auch leicht verständlich zu be- oder auch umschreiben. Zudem fiel mir gerade auf, daß dein erster Wertebezeichner MWSt-Betr(ag) zudem wohl besser MWSt-Betrag also ohne Klammern geschrieben werden sollte, was dann aber wohl spätestens der Übersetzer (oder auch sogenannte Kompiler) bemängeln würde, da dieser dann wohl üblicherweise das eingeklammerte ‚ag‘ als ggf. zudem auch noch unbekannten Übergabewert (oder üblicherweise leider sogenannten Parameter) mißversteht.

Mit lieben Grüße. -- Abmühung, am 1.11.2018, 14:17 (MEZ)

Habe die Bezeichner im Beispiel etwas aussagefähiger gestaltet; genau sowas wird aber auch konkret in Namensregeln festgelegt. Vielleicht wäre 'Trennstriche' ein weiterer Teilaspekt, der in 'Andere Namensregeln' aufgenommen werden könnte - weil auch sowas in Namenskonventionen geregelt ist. Sicher gibt es unter dieser Überschrift weitere Anwendungsbereiche (die Programmierung betreffend).--VÖRBY (Diskussion) 16:52, 1. Nov. 2018 (CET)

Ja, und den ersten Teil aus ‚ReBetrNto‘ hatte ich mir schon mit ‚Rechenbetrag…‘ oder in diesem Beispiel hier wohl (zu)treffender mit ‚Rechungsbetrag…‘ gedacht, der anhängliche Teil ‚…Nto‘ ist mit aber nach wie vor ein Rätsel. Zudem hätte ich das Vorbild(beispiel) oder auch (vorbildhafte) Beispiel – nach einer Nacht drüber geschlafen – wohl eher (noch selbsterklärender oder auch sprechender) wie folgt geschrieben:

Mehrwertsteuer = Handelspreis * Steueraufschlag_in_Hundertstel

… zudem Ausgelagertes/Anhängliches:

Liebe Grüße. -- Abmühung, am 2.11.2018, um 11:31 (MEZ)

Hallo, habe Deine Anmerkungen gelesen und merke an: Wenn in Namenskonventionen 'sprechende Bezeichner' festgelegt ist, heißt das meist nicht, dass jeder Bezeichner in voller Länge der natürlichen Sprache benannt wird. Meist ist in solchen Konventionen auch festglegt, WAS im Bezeichner auszudrücken ist, in welcher Reihenfolge und (zB) wie getrennt. Da gehören auch unternehmensspezifisch gängige Abkürzungen dazu. Auch müssen die Bezeichner weiteren Anforderungen genügen, z.B. dass man erkennt, zu welchem Zusammenhang (wie etwa Datenbestand) o.ä. sie gehören, welche Formate sie aufnehmen etc. Betrag (Einzelpreis) ist etwas anderes als Betrag (Rechnung) oder Betrag (Rückstand). Damit sind sie immer noch selbsterklärend/sprechend, wenn auch nicht für jeden Laien. Aber hier soll ja nur ein Beispiel gezeigt werden. --VÖRBY (Diskussion) 13:59, 2. Nov. 2018 (CET)

Textvorschlag oben dem entsprechend angepasst: --VÖRBY (Diskussion) 17:22, 2. Nov. 2018 (CET)

Ja, mir war schon klar/bekannt, daß es auch immer wieder Mitarbeiter gibt, welche eher (wohl hauptsächlich kurzsichtig, allein zu ihrem eigenen Vorteil) möglichst kurze Bezeichner bevorzugen, selbst wenn dadurch dann die (wenigstens [auch] von mir – hier, in der Wikipedia – bevorzugte Allgemein-)Verständlichkeit (oder in eben diesem Sinne auch die Selbsterklärung [der hier auch angesprochenen Bezeichner]) sowie aber auch (später hinzukommende und damit üblicherweise auch) unerfahrenere Mitarbeiter außen vor gelassen und deren (ggf. sogar erwünschte spätere) Mitarbeit unnötig erschwert wird – wobei ich da auch wieder die Wartung (auch über die Anwendungsentwicklung hinaus gesehen) im Sinn habe und zudem den Umstand, daß auch selbst sehr gut( erscheinend)e langjährige Mitarbeiter, beispielsweise durch einen (üblicherweise unbeabsichtig) tödlichen Autounfall oder auch durch andere Umstände, dahin-/ausscheiden könn(t)en. Zudem müssen die hier sogenannten Konventionen ja auch keine festen/unveränderlichen Gebilde sein. Wenn die Mitarbeiter(-Gemein)schaft groß genug ist (um einzelne Ausscheidungen, egal welcher Art :-) auszugleichen) und entscheiden, den Rest der Welt (und damit auch mögliche Nachfolger) außen vor zu lassen, nunja, dann muß das wohl der Rest der (freien oder auch einfach nur andere Fachbereichs-)Welt(en – im fachübergreifenden/ganzheitlichen/interdisziplinären/polytechnischen Ansatz gesehen) einfach aushalten.

Ausgelagertes/Anhängliches:

Mit lieben Grüße. -- Abmühung, am 3.11.2018, um 08:03 (MEZ)

Da will ich nichts mehr dazu sagen, Du hast sicher schon in zahlreichen großen Projekten praktisch gearbeitet/programmiert!!? Was soll HIER das breite Erklären von 'Ausscheiden'? Allerdings wird mir dadurch Die 'Denke' etwas klarer, nach der man Links auf WLS wie sprechende Variablennamen (siehe LD dazu) unbedingt verteidigst. Ich stell das jetzt mal im Artikel ein.

(Der vorstehende Beitrag wurde von VÖRBY verfaßt und am 3.11.2018, 12:16 [MEZ] abgesendet.)

Das war nur ein ja im grunde nebensächliches Wortspiel, Hilfsmittel oder eine Krücke, um eben – neben den rein technischen und oft sehr selbstständigen oder auch einzelkämpferischen – zudem auch die (zwischen)menschlichen Zusammenhänge (vor allem in der Gemeinschaftsarbeit) zu verdeutlichen. Übrigens, laß bitte künftig deine rechtschreiblichen Nachbesserungsversuche (wie diesen) an fremden oder wenigstens meinen Diskussions-Beiträgen sein, auch wenn sie gut gemeint sind. Wenn mir echte Mängel auffallen, dann kümmere mich da schon selber drum. Ansonsten würde es wohl, bei echten/nennenswerten Mängeln, auch ein gut gemeinter Hinweis darauf oder (spätestens) bei (schwerwiegenden) Mißverständnissen eine möglichst sachliche Nachfrage tun. Liebe Grüße. -- Abmühung, am 3.11.2018, um 13:46 (MEZ)

Nachtrag: Die Anbindung zum Eintrag „Gegenbeispiel“ habe ich übrigens soeben, neben weiteren kleinen Nachbesserungen nebenan, einfach (wie sonst auch, nur vorschlagsweise) entfernt, da dieses Wort wohl zur hier üblichen Umgangssprache gehört – im Gegensatz zum anfänglich von dir oben vorgeschlagenen und zwischenzeitlich ersetzten Antimuster. Liebe Grüße. -- Abmühung, am 3.11.2018, um 14:36 (MEZ)

Alles ist gut. Ich denke nur, dass der 'Siehe-Auch'-Link noch entfernt werden muss: Denn dies Hier sollte aus dem Programmierabschnitt aus Sprechende Namen als Hauptartikel verlinkt werden, weil es strukturell der detailliertere Artikel ist, während SN allgemeingültiger ist (Programmierung nur ein Teilkapitel). Ich werde mir das demnächst mal vornehmen. Schönen Sonntag!--VÖRBY (Diskussion) 19:09, 3. Nov. 2018 (CET)

Ja, das habe ich, nach deinem Beitrag hier, auf den ersten Blick auch (fast/annähernd/ähnlich) so gesehen, VÖRBY (und Mitlesende), und den betreffenden Verweis dann entsprechend entfernt (sowie nebenher u.a. auch noch den im angefügten Beispiel eigentlich verwendeten Unterstrich genannt).^[3] Auf den zweiten Blick kam mir dann aber auch wieder eben der auch sogenannte Blick über den Tellerrand (oder auch hinaus aus dem Elfenbeinturm) in den Sinn, und dahingehend (war und) ist es wohl doch besser, den betreffenden Verweis (wieder einzufügen und) beizubehalten, um eben ggf. auch später mal (leichter oder benutzerfreundlicher) zu sehen, was denn die Anderen (außerhalb der Datenverarbeitung) so treiben oder (zwischenzeitlich) getrieben haben. Zudem könnte so auch eher mehr zu den sogenannten sprechenden Variablennamen zusammenkommen, also der Eine mag dazu womöglich lieber eben unter dem genannten Siehe-auch-Verweis (unter Sprechender Name#Sprechende Namen in der Programmierung) erst nur nachlesen und anschließend auch gleich was dazu ergänzen, und der Nächste dann womöglich hier (nebenan, im anhaftenden Eintrag) oder wo die (freie Gedanken-)Reise eben so hingeht. Und irgendwann könnte dazu dann auch mal hier, in der Wikipedia, doch noch genug oder gar zu viel (überall, frei[willig] verstreut) angesammelt worden sein, um es dann besser in einem eigenen (und eindeutiger benannten) Eintrag, wie eben beispielsweise unter „sprechender Variablenname“ (anstatt auch immer weiter zu allen anderen „sprechenden Namen“) auszulagern – und, eigentlich selbstverständlich, auch unter Beibehaltung oder Nachführung aller zugehörigen (Siehe-auch-)Verweise. Schließlich ist so ein „Siehe auch“ kein (gegenwärtig gefühloser Maschinen-)Befehl (oder eine auch sogenannte Instruktion), sondern letztlich wohl nur eine gut gemeinte (Menschen…/menschliche) Empfehlung (an – hoffentlich auch möglichst lange – freie Mitmenschen sowie auch – im Allgemeinen/Umgangssprachlichen – an frei[willig]e Mitarbeiter) – jedenfalls hier, in der freien(!) Wissenssammlung. namens Wikipedia. Liebe Grüße. -- Abmühung, am 4.11.2018, um 08:09 (MEZ)