mikrocontroller.net

Forum: PC-Programmierung Notation (Ungarische Notation)


Autor: Peter (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo

Ich habe mich in den letzten Wochen mit der C Programmierung
beschäftigt. Verwendet Ihr im Code Notaionen wie z.B die Ungarische
Notation? Die Anwendung von Notationen kenne ich von der
Softwareentwicklung mit Delphi, oder Visual Basic, wo ich sie sehr
hilfreich fand, den Code quasi besser "lesbar zu gestalten".

Gibt es hier auch einen Standard für C mit der aktuellen Lib des
WinAvr.

Beispiel:

viele deklarieren Variabeln z.B. so:

  unsigned char Counter;


mit Notation könnte das evtl. so aussehen:

  unsigned char ucCounter;    /* das "uc" steht für unsigned char */


ist die Variable global deklariert könnte man sie evtl. so nennen:

  unsigned char gucCounter;   /* das "g" steht für global */


bei WinAvr Lib:

  uint8_t Counter;

könnte das so aussehen:

  uint8_t uiCounter;

oder global:

  uint8_t guiCounter;


Was haltet davon, oder benutzt Ihr bereits einen Standard?

Gruß

Peter

: Verschoben durch Admin
Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

ich verwende ebenfalls die Ungarische Notation. Sie deckt eine Menge
ab, aber eben nicht alles. Da kann man sich halt etwas ausdenken. Z.B.
für die Definition einer Struktur: strucMeineStruktur.

Grüße
Oliver

Autor: Andreas Jäger (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Ich neige sogar dazu zu sagen: Die Benutzung von Notationen
unterscheitet den Profi vom Hobbyprogrammierer... ;-)

MfG
Andreas Jäger

Autor: Andre Groß (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter
Ich verwende auch die ungarische Notation, nur mit einem Unterstrich
dazwischen..

also:

struct meinStruct_str
{
  unsigned char uc_meinChar;
} t_struct1;

Ich finde das macht die Sache noch ein bißl leslicher, auch wenn man
NOCH ein Zeichen mehr hat. ;-)

@Andreas

Da gebe ich dir vollkommen recht..

Andre

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Andreas S. (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
9 lesenswert
nicht lesenswert
Mir ist die ungarische Notation bisher nur in Visual-C++-Programmen
begegnet, ansonsten ist sie kaum verbreitet. Ich finde sie sinnlos und
unpraktisch, ist doch Unsinn dass wenn man den Typ einer Variable
ändert man auch den Namen ändern muss.

Autor: Ralf (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

ich halte die ungarische Notation für sehr wichtig und hilfreich.
Sobald die Projekte größer werden und man mit mehreren Leuten an eines
Software arbeitet hilft es, den Code schnell zu verstehen und man
blickt auch nach einiger Zeit noch durch den eigenen Code. Wenn man
gekappselt Programmiert, ist es auch kein Problem, wenn man einen Namen
ändern muß, da sowieso alles in einer Datei steht und man alles mit
Textersatz machen kann. Ich gehe persönlich und auch auf der Arbeit
noch einen Schritt weiter, und nehme ein Modulkürzel noch mit in den
Namen auf (bei statischen Modulvariablen und auch Funktionen). So weiß
man immer gleich, wo was zu finden ist und der Code ist leicht
verständlich.

Viele Grüße,
Ralf

Autor: Andreas Jäger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas Schwarz

Also für kleine überschaubare Programme (...1000 Codezeilen) lässt sich
darüber streiten. Aber wenn die Sache etwas umfangreicher wird
(>1000000 Codezeilen) ist es sehr Hilfreich, wenn der Typ einer
Variable schon am Namen zu erkennen ist und man nicht immer wieder
'nachsehen' muss. Insbesondere, wenn mehrere Programmierer an einem
Projekt arbeiten, ist es schon fast zwingend (wenn nicht sogar interne
Vorschrift) eine Notation zu verwenden.

Andersrum könnte ich ja sagen: Warum nicht die Variablen a1, a2, a3,
a4... nennen? Macht (fast) keiner, weil sprechende Namen halt das
Schreiben und Warten(!) eines Programmes einfacher machen. Und wenn die
Namen schon sprechen, dann doch bitte deutlich!

MfG
Andreas Jäger

Autor: Andreas S. (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Wie Jörg schon im "Parallelthread"
(http://www.mikrocontroller.net/forum/read-2-37134.html) geschrieben
hat, wurde diese Notation von MS erfunden, und wird auch fast nur in
MS-Programmen verwendet. Ich habe sie jedenfalls noch nirgendwo außer
in MS-Beispielen und Visual-C++-Büchern gesehen, weder in großen Open
Source Projekten wie MySQL (>1000000 Zeilen Code) oder Linux, noch in
Appnotes von Compilerherstellern oder API-Dokus von anderen
kommerziellen Programmen.

Autor: Sven (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Hallo Zusammen,

wenn ich heutzutage noch SW ohne Notation sehe, überkommt mich gleich
Gänsehaut. Wenn dann auch noch Einzelbuchstaben für Variable ( also ohne 
Andeutung was die Variable eigentlich macht ) benutzt werden, weis ich 
gleich das hier früher oder später ich die Hände über dem Kopf 
zusammenschlagen muß. Ich mache C-Software seit 20 Jahren und habe 
einiges gesehen. Und ich kann sagen wenn ein Programmierer der von 
vornherein ungarische Notation verwendet ( auch wenn das Programm noch 
so klein sei  sollte ) wird grundsätzlich eine überdachtere Lösung und 
daher weniger fehlerträchtige Software abliefern. Die Zeiten von ganz 
quick und richtig dirty sind vorbei da die SW-Systeme mittlerweile 
Ausmaße annehmen das selbst gestandenen Programmierern Angst und Bange 
wird. Deshalb ist Disziplin und da gehört ungarische Notation zum 
tagesgeschäft einfach dazu.
Das sieht man vorallem wenn es um Software geht die richtig 
Verantwortung übernimmt ( Automobil, Luftfahrt, Medizin ). Hier ist 
ungarische Notation erst der Anfang von weiteren Bestimmungen und 
Vorgaben um ein klares strukturiertes Systemm zu bekommen.

Autor: P. S. (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Ohne ungarische Notation geht die Welt unter. Das muss mal ganz klar 
gesagt werden.

Autor: Andreas S. (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Toll, einen 6 Jahre alten Thread wieder ausgegraben...

Für jede Variable ist in C mit der Deklaration klar festgelegt welchen 
Typ sie hat. Wieso will man diese Information nocheinmal von Hand im 
Namen der Variable wiederholen? Sie ist bereits fest der Variable 
zugeordnet, und kann von einer modernen IDE auf Wunsch eingeblendet, 
farblich hervorgehoben, oder sonstwie interpretiert werden.

Wenn C-Programme mit ungarischer Notation weniger chaotisch sind, dann 
liegt das wohl weniger an der Notation selbst, als daran dass der 
Programmierer der sie verwendet offensichtlich irgend einem Coding 
Standard folgt, statt einfach wild drauflos zu programmieren.

Autor: P. S. (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Vor Allem zeigen die Beispiel oben schon, wie das Chaos nur vergroessert 
wird:

---
könnte das so aussehen:

  uint8_t uiCounter;

oder global:

  uint8_t guiCounter;
---

ui ist die Abkuerzung fuer user interface und gui fuer graphical user 
interface. Oder steht es doch fuer uint16 oder uint32?

Ich sitze hier an Code mit mehreren Millionen Zeilen Code und meine 
Probleme werden sicher nicht durch die ungarische Notation geloest...

Autor: Karl H. (kbuchegg) (Moderator)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
Ich habe auch eine zeitlang ungarische Not. verwendet (so wie sie heute 
gerne verstanden wird *), habe sie aber wieder aufgegeben. Wenn eine 
Funktion chaotisch ist, dann ist sie es auch mit ungarischer Not. Das 
liegt in der überwiegenden Mehrzahl der Fälle aber nicht daran, dass die 
Datentypen der verwendeten Variablen nicht bekannt sind sondern an 
anderen bekannten Gründen: Funktionen zu lang, keine vernünftigen 
Variablennamen, inkonsistente Einrückengen, keine Blockkommentare, etc. 
Kurz und gut: Saustall im Code.

* ung. Not. so wie sie heute oft verstanden wird, also mit dem Datentyp 
als Präfix, ist eigentlich ein Missverständnis. Die ursprüngliche Idee 
war es, den Verwendungszweck bzw. welcher Art die Variable ist, als 
Präfix zu verwenden. Das hat aber nicht unmittelbar etwas mit dem 
Datentyp, also int long double etc. zu tun, sondern vielmehr mit dem 
logischen Kontext, in dem die Variable existiert, ob sie ein Pointer 
ist, ein Handle, ob der in dieser 3D-Punkt Variablen gespeicherte Punkt 
in absoluten Koordinaten ist oder in lokalen Koordinaten, ob ein Preis 
mit oder ohne Steuer dargestellt ist etc.
Diese Verwendung der ung. Not. hingegen ist sinnvoll und die setze ich 
auch liebend gerne und oft ein. Hier hat mir die ung. Not. schon oft den 
Tag gerettet, wenn es wieder mal galt auseinanderzuklamüsern, warum eine 
Geometrieoperation schief geht und sich herausstellte, dass wieder mal 
Äpfel mit Birnen, also Vektoren in verschiedenen Kooridnatensystemen 
miteinander verrechnet wurden.

Aber die Kennzeichnung uiIndex ist m.E. eine sinnlose Verschlechterung 
der Lesbarkeit, deren Nutzwert gegen 0 geht.

Autor: Fabian D. (fabi06)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Bei uns in der Firma wird die ungarische Notation im embedded Bereich 
immer noch verwendet, um den Rückgabedatentyp einer Funktion und den 
Datentyp einer Variablen zu kennzeichnen. Als Argument dafür wird immer 
angegeben, dass man dadurch ja sehen könnte, was eine Funktion zurück 
gibt und was für Werte man den Variablen zuweisen darf.

Ich persönlich finde die ungarische Notation unnötig und einfach nur 
nervig. Wenn ich eine Funktion oder eine Variable verwende, muss ich 
mich sowieso mit dieser auseinandersetzen und in der Dokumentation 
nachlesen, was ich da eigentlich tue. Dann sieht man den Datentyp auch 
schon, spätestens mit dem Tooltip einer vernünftigen IDE.

Vor Allem bei der Verwendung von C++, wo alles auf Klassen basiert, 
finde ich es erst recht unnötig, überall 'c' oder weiß der Geier was 
vorzuschreiben. Dann haben auf einmal alle Variablen den gleichen 
Präfix.

Wie seht ihr das?

Gruß

Autor: Uncle Bob (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Andreas Jäger schrieb:
> Ich neige sogar dazu zu sagen: Die Benutzung von Notationen
> unterscheitet den Profi vom Hobbyprogrammierer... ;-)

Was einen qualifizierten Software-Entwickler von einem sog. "Profi" 
unterscheidet, ist, dass er (oder meinetwegen auch sie oder es) die 
Standardwerke der Software-Entwicklung kennt und nicht nur gelesen, 
sondern auch verstanden und sich kritisch damit auseinandergesetzt hat. 
Im vorliegenden Fall also beispielsweise den Abschnitt "Avoid Encodings" 
in "Clean Code".

Aber gut, im Jahre 2003 waren im IT-Bereich doch teilweise noch sehr 
spezielle "Profis" unterwegs. In anderen Bereichen hätte man sie eher 
als "angelernte Hilfsarbeiter" bezeichnet.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
10 lesenswert
nicht lesenswert
Im Zeitalter der teilweise wirklich guten IDEs ist die Ungarische 
Notation vollkommen sinnlos: mit der Maus über das Symbol hovern und man 
bekommt alles wichtige angezeigt. Lieber aussagekräftige Namen verwenden 
also irgendwelche Typ-Info o.ä. in den namen zu kodieren.

Autor: Oliver S. (oliverso)
Datum:

Bewertung
11 lesenswert
nicht lesenswert
Ist ja dann doch beruhigend, daß sich in den 15 Jahren seit Eröffnung 
dieses Threads was weiterentwickelt hat.

Oliver

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Fabian D. schrieb:
> Wie seht ihr das?

So sinnvoll wie ein Kropf (in der von unter anderem Microsoft falsch 
verstandenen Variante).
Wie es oben vor 9 Jahren Karl Heinz (wo ist der eigentlich geblieben?) 
wie immer sehr treffend schrieb:

Karl H. schrieb:
> ie ursprüngliche Idee
> war es, den Verwendungszweck bzw. welcher Art die Variable ist, als
> Präfix zu verwenden. Das hat aber nicht unmittelbar etwas mit dem
> Datentyp, also int long double etc. zu tun, sondern vielmehr mit dem
> logischen Kontext, in dem die Variable existiert, ob sie ein Pointer
> ist, ein Handle, ob der in dieser 3D-Punkt Variablen gespeicherte Punkt
> in absoluten Koordinaten ist oder in lokalen Koordinaten, ob ein Preis
> mit oder ohne Steuer dargestellt ist etc.

Der Klassiker ist ein Winkel. Da ist es gut zu wissen, ob er in Grad 
oder im Bogenmaß angegeben ist. Das ist dann was, das beim Lesen und 
Bearbeiten des Code wirklich weiter hilft. Dass er vom Typ float ist, 
sehe ich an der Definition, wenn ich es denn unbedingt wissen muss. Und 
sollte ich das mal auf double ändern wollen, muss ich nicht erst an 
allen Stellen, wo die Variable benutzt wird, ihren Namen ändern.

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Android verwendet m als Präfix für Membervariablen in Klassen. Damit 
vermeidet man Namensdopplungen (z.B. bei Konstruktorparametern), wenn 
man nicht gerade auf Unterstriche steht oder andere Krücken steht.

Ansonsten ist es nicht verkehrt, (Achtung, C++!) rohe Zeiger mit p zu 
markieren. Besser wäre allerdings, ganz darauf zu verzichten.

Weitere, situationsabhängige Präfixe wurden schon genannt und sind je 
nach Kontext extrem sinnvoll - oder eben auch nicht. Universell sind sie 
natürlich nicht.

Autor: bastel_ (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nix gegen den Unterstrich, da steh ich drauf :) Leichter schreibbar als 
m_ und unauffälliger als m :P

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
S. R. schrieb:
> Android verwendet m als Präfix für Membervariablen in Klassen.

Das mache ich auch gerne, aber eigentlich hauptsächlich aus dem Grund, 
das dann die Member bei der Autovervollständigung sofort angezeigt 
werden in der completion-list, wenn man "m" tippt ;-)

> Damit
> vermeidet man Namensdopplungen (z.B. bei Konstruktorparametern),

braucht man nicht, weil eindeutig

> Ansonsten ist es nicht verkehrt, (Achtung, C++!) rohe Zeiger mit p zu
> markieren.

Warum? Konfiguriere Deine IDE so, dass sie daraus ein hässliche Farbe 
macht.

> Besser wäre allerdings, ganz darauf zu verzichten.

Wenn man eine reine Benutzungsrelation und keine Eigentümerschaft 
ausdrücken will, benötigt man sie aber - sofern man keinen Vokabular-Typ 
wie observer_ptr<> o.ä. verwenden will.

Autor: Weissbescheid (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
> Ansonsten ist es nicht verkehrt, (Achtung, C++!) rohe Zeiger mit p zu
> markieren. Besser wäre allerdings, ganz darauf zu verzichten.

Pointer sind fantastisch, aber man muss es beherrschen. Daran scheitern 
die meisten.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bastel_ schrieb:
> Nix gegen den Unterstrich, da steh ich drauf :) Leichter schreibbar als
> m_ und unauffälliger als m :P

Aber nicht am Anfang, da ist er verboten.

Also nicht _bla, sondern nur bla_.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> bastel_ schrieb:
>> Nix gegen den Unterstrich, da steh ich drauf :) Leichter schreibbar als
>> m_ und unauffälliger als m :P
>
> Aber nicht am Anfang, da ist er verboten.
>
> Also nicht _bla, sondern nur bla_.

Nein, er ist nur verboten, wenn darauf ein Großbuchstabe oder ein 
zweiter Unterstrich folgt. _bla ist in Ordnung.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch als Anmerkung: Beispiele wären _Bool oder __attribute__.
Übrigens sind auch die sehr häufig anzutreffenden include guards im 
Stile von __MY_HEADER_included__ eigentlich nicht erlaubt.

Autor: Uli (Gast)
Datum:

Bewertung
-9 lesenswert
nicht lesenswert
Im Embeded Bereich (Medizin & Steuerungen) kenne ich nichts anders als 
die Ungarische Notation.
Wenn jemand was anderes abliefern würde, würde der Code spätestes bei 
der Versionskontrolle auffliegen, da läuft ein Checker vorher drüber.
Auch wenn ich was für Kunden Schreibe dann ist immer die Notation fest 
geschrieben.

Wenn man Später mal aus einem unsigned char ein signed long machen muss 
ist das auch kein Hexenwerk, eigentlich jeder Editor bietet dafür 
passende Funktionen.

Im Internet finde ich meistens nur Notationsfreien Code und wenn dann 
doch mal mit, dann ist das meistens fehlerhaft.
Das meistens auch noch alles ohne vernünftigen Kommentar abgeliefert 
wird ist dann nur noch der krönende I-Punkt.

Mein Tipp einfach einsetzen und wenn jemand sagt ist das ein Dreck den 
Typen einfach ignorieren, der hat keine Ahnung!

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Uli schrieb:

> Mein Tipp einfach einsetzen und wenn jemand sagt ist das ein Dreck den
> Typen einfach ignorieren, der hat keine Ahnung!

Viel Spaß bei generischem Code ... ;-)

Autor: dunno.. (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Wer irgendwo in einer codeeinheit so viele variablen hat, dass er sich 
den typ nicht merken kann, und er sich auch nicht aus dem namen ergibt, 
sollte imho den code überdenken..

Ansonsten gibt's zur not ja immernoch intellisense oder wie auch immer 
es in der ide der wahl heißt.

iIndex oder cInputCharacter braucht kein mensch..

Autor: Da D. (dieter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uli schrieb:
> Mein Tipp einfach einsetzen und wenn jemand sagt ist das ein Dreck den
> Typen einfach ignorieren, der hat keine Ahnung!

<ironie> Guter Tipp! Das zeugt von einer guten und sachlichen 
Argumentationsweise. Wann immer jemand eine andere Meinung als man 
selber vertritt, unterstell ihm dass er keine Ahnung hat, und ignoriere 
ihn! </ironie>

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da D. schrieb:
> Das zeugt von einer guten und sachlichen Argumentationsweise.

Eigentlich findet sich im ganzen Posting kein einziges Argument, außer 
"weil der Precommit-Hook und der Kunde das verlangen".

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
7 lesenswert
nicht lesenswert
Das letzte Mal, wo ich gezwungenermaßen in Variablennamen den jeweiligen
Datentyp kodieren musste, war vor knapp 40 Jahren auf dem Apple II in
Applesoft-Basic.

Da es in den damaligen Basic-Dialekten weder Variablendeklarationen noch
dynamische Typisierung gab, ermittelte der Interpreter den Datentyp
anhand des Variablennames:

  Suffix    Beispiel    Datentyp
  ———————————————————————————————————————————
   ohne     BREITE      40-Bit-Floating-Point
    %       ANZAHL%     16-Bit-Integer
    $       TEXT$       Textstring
  ———————————————————————————————————————————

Apple II und Applesoft-Basic sind schon lange im Museum, und meiner
Meinung nach gehören sämtliche Typpräfixe und -suffixe ebenfalls
dorthin.

Wenn jemand trotzdem an den alten Gepflogenheiten festhalten möchte,
sollte er es wenigstens konsequent tun und dafür sorgen, dass nicht nur
Primitivtypen wie char, int und double sowie Zeiger auf dieselben,
sondern auch alle anderen Typen wie Arrays, Funktionszeiger und
Funktionen einen eindeutigen Präfix erhalten.

Man braucht dazu nicht einmal etwas Neues zu erfinden, sondern kann
bspw. die Typkodierung aus dem C++-Mangling von GNU verwenden und die
Variablen- oder Funktionsnamen nach dem Schema

  i<typcode>_<name>

bilden. Das "i" am Anfang stellt dabei sicher, dass alle Identifier
unabhängig vom Typcode mit einem Buchstaben beginnen, und durch den
Underscore ist das Präfixende festgelegt.

Damit kann aus dem Identifier eindeutig dessen Typ ermittelt werden, so
dass sogar eine Prüfung des Präfix durch einen entsprechend erweiterten
Compiler möglich wäre. Inkonsistenzen zwischen Präfix und tatsächlichem
Typ gehörten somit der Vergangenheit an.

Beispiel:

Es soll eine Tabelle mit 3 Funktionen angelegt werden, die jeweils einen
C-String als Argument erwarten und einen Wert des benutzerdefinierten
Typs ResultType zurückliefern.

Nichts einfacher als das:

struct ResultType (*iA3_PF10ResultTypePKcE_tab[3])(const char *) = {
  iF10ResultTypePKcE_foo,
  iF10ResultTypePKcE_bar,
  iF10ResultTypePKcE_baz
};

Ein Aufruf einer Funktion aus der Tabelle könnte so aussehen:

  struct ResultType i10ResultType_qux;
  int ii_index = 2;
  i10ResultType_qux = iA3_PF10ResultTypePKcE_functab[ii_index]("irgendwas");

Da durch die gepräfixten Variablen- und Funktionsnamen deren Bedeutung
direkt ins Auge springt, ist obiger Programmcode selbst für einen
Außenstehenden ohne weitere Kommentare sofort verständlich.

Oder auch nicht ;-)

Autor: Michael R. (fisa)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Oder auch nicht ;-)

dem ist eigentlich nichts mehr hinzuzufügen ;-)

Autor: Uli (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Das hier kaum sachlich Argumentiert wird sollte jedem klar sein.
Dazu sind die Standpunkte zu fest gefahren, da könnte man auch gleich 
wieder über LINUX und Windows Diskutieren.
Wie gesagt im Medizinbereich kenne ich das nur, aber auch da wird es 
andere Firmen geben.

Sinn macht das ganze schon, alleine nur an einem kleinen Beispiel zu 
erkennen:

unsigned char Test1;
unsigned long Test2;
-- 200 Zeilen später
Test2 = 2000;
-- 100 Zeilen später
Test1 = Test2-1; // da mekert nicht jeder Kompiler drüber!


Wenn man aber gleich sieht ucTest = ulTest-1 dann wird einem beim 
schreiben schon was auffallen.
Wenn man wenigstens u8Test und u32Test nehmen würde, dann würde das auch 
auffallen.
Um mehr geht es hier doch nicht und das sollte jeder der ernsthaft 
programiert drauf haben und machen. Genauso wie hoffentlich jeder eine 
Versionskontrolle benutz, bei allem anderen wünsche ich viel spaß.

VG, Uli

Autor: mh (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Uli schrieb:
> Um mehr geht es hier doch nicht und das sollte jeder der ernsthaft
> programiert drauf haben und machen.

Und "jeder der ernsthaft programiert" weiß, dass man Variablennamen wie 
Test1 und Test2 nicht benutzt und dass Funktionen mit mehr als 300 
Zeilen keine gute Idee sind.

Autor: Kaj (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Uli schrieb:
> jeder der ernsthaft programiert
sollte "Clean Code" gelesen haben!

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Projekt "R" gab's mal einen lustigen Fall mit der Präfixnotation. Es 
ging um eine Integer-Variable, die den Anfang einer verketteten Liste 
wiedergeben sollte.

Da stand dann iGiveHead. LOL

Autor: Achim S. (achs)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Uli schrieb:
> Wenn man aber gleich sieht ucTest = ulTest-1 dann wird einem beim
> schreiben schon was auffallen.

Vermutlich war Medizintechnik Mal ein Vorreiter mit fortschrittlichen 
Standards in SW. Aber seit 30 Jahren ist das durch IDEs und statische 
Analyse überholt.

Je größer ein Programm, je wichtiger die Namensschemata. Aber ui oder 
ul? In den meisten Fällen: nein.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Uli schrieb:
> Das hier kaum sachlich Argumentiert wird sollte jedem klar sein.
> Dazu sind die Standpunkte zu fest gefahren, da könnte man auch gleich
> wieder über LINUX und Windows Diskutieren.

Vor allem deiner, wenn man das liest:

Uli schrieb:
> Mein Tipp einfach einsetzen und wenn jemand sagt ist das ein Dreck den
> Typen einfach ignorieren, der hat keine Ahnung!

Und da beschwerst du dich über fehlende sachliche Argumente…

> Wie gesagt im Medizinbereich kenne ich das nur, aber auch da wird es
> andere Firmen geben.

Das alleine macht es nicht zum heiligen Gral.

Autor: Tek (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dunno.. schrieb:
> iIndex oder cInputCharacter braucht kein mensch..

und InputCharacter ist besser als cInput?

Wenn Du den Typ im Variablennamen ausschreibst darfst Du dich über 
Notation nicht beschweren...

Autor: Nop (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Tek schrieb:

> und InputCharacter ist besser als cInput?

Nein, das heißt einfach "ch" und fertig. Genauso wie ein Schleifenindex 
einfach "i" heißt. Quell- und Zielpointer sind src und dst.

Lediglich, wenn das keine lokale Wegwerf-Variable ist, sondern einen 
größeren Scope hat, dann sollte es anders heißen. Oder wenn es eine 
tiefere Bewandtnis damit hat.

Autor: Adam P. (adamap)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also bei mir gibt es keine "Ungarische Notation" und erst recht kein 
"CamelCase" - ob eine Variable nun uint8_t oder char oder bool ist, kann 
man in der Deklaration einsehen, falls man es wissen möchte und wenn der 
Name ansich schon nichtssagend ist, dann liegt (sitzt) das Problem vor 
dem PC :-D

Kleines Zitat:

"Encoding the type of a function into the name (so-called Hungarian 
notation) is brain damaged - the compiler knows the types anyway and can 
check those, and it only confuses the programmer. No wonder MicroSoft 
makes buggy programs. "

(Found in Documentation/CodingStyles in the Linux kernel sources)
Quelle: https://slurm.schedmd.com/coding_style.pdf

Dort ist auch nicht alles Gold, aber da sollte sich jeder das 
Zusammensuchen was Sinn ergibt und kein Mehrauffand erzeugt.

Autor: Junge (Gast)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Also ich benutze und fahre damit prima im Embedded Bereich:

uX = uintX_t
sX = intX_t
f = float
d = double
o = Objekt wie aus einem struct
g_ = global
s_ = struct
p = pointer
a = array

Maximal Beispiel:
g_apu16Variables => Globales Array über Pointer auf uint16_t

Oder Einfach:

struct{
} s_Auto;

s_Auto oAuto1, oAuto2, oAuto3;

Autor: Vincent H. (vinci)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
auto tupiccptupdarri3_test {std::make_tuple(
      42, "hello_world", std::make_tuple(42.42), std::array{1, 2, 3})};

Keine Ahnung was ihr alle habts...
hungarian notation macht meine Programme alle viel leserlicher!

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Junge schrieb:
> struct{
> } s_Auto;
>
> s_Auto oAuto1, oAuto2, oAuto3;

Hat keinen Vorteil gegenüber

struct Auto {
};

struct Auto auto1, auto2, auto3;

Autor: Achim S. (achs)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
Junge schrieb:
> g_apu16Variables => Globales Array über Pointer auf uint16_t

alles was nicht sinnvoll aussprechbar ist, ist m.E. murks. Dabei kann es 
ruhig abkürzungen geben, solange sie eindeutig sind, z.B. wie oben:

dst = Destination
src = Source
ch  = char.

aber "apu" ist es nicht, g_apu auch nicht. Und ja, man sollte erkennen, 
ob etwas global ist oder nicht, aber nicht an noch einem Zungenbrecher 
davor. Sondern z.B. an der Schreibweise. Ich habe nichts dagegen, wenn 
für das Modul (C-File) "XXX" und der Funktionalität "YYYY" (was immer 
das sein soll), z.B vereinbart wird:

XxxYyyy:  globale Funktion
xxxYyyy: globale Variable
XXX_YYYY: Makro
Yyyy:     lokale Funktion
yyyy:     lokale Variable
_yyyy:    lokal Variable innerhalb eines Blocks

Wenn ich dann "CanInit" lese, weiss ich, dass es die Globale 
Init-Funktion des Can-Moduls ist. Und wenn ich irgendwo adcValueList 
lese, dann habe ich (nach obiger Konvention) eine globale Liste (Array) 
der Werte des ADC-Moduls.

Ob diese Liste nun direkt die gesampelten Werte enthält (array of 
uint_16t), oder Pointer auf die Leseregister (wie in Deinem Beispiel) 
enthält, ist völlig egal! Beim Lesen sehe ich es in der Verwendung:
uint16 v0 = adcValueList[0];
vs.
uint16 v0 = *adcValueList[0];
Die IDE zeigt es mir auch an. Verwechsle ich das, meckern Compiler und 
Lint. Ich kann mich mit einem Kollegen sprachlich darüber austauschen 
("adcValueList war nicht upgedated"). Und nein, in den allermeisten 
Fällen existiert dazu nicht noch ein adcValueList in anderer 
Schreibweise. Und auch kein canInit oder CAN_INIT im Beispiel oben.

Der Mensch ist wirklich gut darin, Sprache zu erfassen. Genauso wie 
Beugungen oder Anhängsel die gesprochene Sprache vereinfachen (kürzer, 
effektiver machen), können Modul-Kürzel, eindeutige Begriffe und 
Token-Bildungsregeln den Quelltext vereinfachen (lesbarer machen). Mit 
g_apu16 und ähnlichen "künstlichen" konstrukten wird es sehr schwer.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dazu kommt noch, dass man heutzutage nicht mehr auf 80x25-Terminals 
entwickeln muss. Eine 50-zeilige Funktion passt einfach auf den 
Bildschirm, und für längere Funktionen hab ich auf Arbeit einen davon 
hochkant gedreht.

Autor: Dieter F. (jim_quakenbush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vincent H. schrieb:
> auto tupiccptupdarri3_test {std::make_tuple(
>       42, "hello_world", std::make_tuple(42.42), std::array{1, 2, 3})};
>
> Keine Ahnung was ihr alle habts...
> hungarian notation macht meine Programme alle viel leserlicher!

Glück gehabt - bin kein Kollege von Dir :-)
Du übrigens auch - ich würde mich dafür einsetzen, dass Dir neue und 
spannende Aufgaben angeboten werden :-)

: Bearbeitet durch User
Autor: Dieter F. (jim_quakenbush)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wobei ich ehrlich gestehen muss, dass mir die ungarische Notation bis 
heute nicht bekannt war/ist. Ich kenne die "umgekehrte polnische 
Notation" aber keine "ungarische Notation". Eine Bildungslücke - 
offensichtlich - aber wenn ich Deine Schreibweise so sehe ist das nicht 
von Belang :-) Die Bildungslücke kann ich verschmerzen ...

: Bearbeitet durch User
Autor: Achim S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieter F. schrieb:
> Eine Bildungslücke - offensichtlic

So wichtig wie Schellackplatten und Spieler mit 78 Umdrehungen!!

Autor: Dieter F. (jim_quakenbush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> So wichtig wie Schellackplatten und Spieler mit 78 Umdrehungen!!

Da ich beides nicht habe - vermutlich (weil ich von Dir einiges gelesen 
habe ...)

: Bearbeitet durch User
Autor: Rolf M. (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dieter F. schrieb:
> Wobei ich ehrlich gestehen muss, dass mir die ungarische Notation bis
> heute nicht bekannt war/ist. Ich kenne die "umgekehrte polnische
> Notation" aber keine "ungarische Notation".

Die polnische Notation gibt's natürlich auch in nicht umgekehrt.
Ich frag mich ja immer, was die Ungarn und die Polen denn gemacht haben, 
dass ihnen die Ehre zuteil wird, dass Notationen nach ihnen benannt 
wurden.
Ich nehme von den Ungarn doch lieber das Gulasch als die Notation. ;-)

Autor: Michael R. (fisa)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Dieter F. schrieb:
> Die Bildungslücke kann ich verschmerzen

Nicht ganz. So ganz sinnlos ist die nicht. ABER: richtig anwenden, also 
nicht so wie von MS (überhaupt ist man ganz gut bedient, sich Konzepte 
von MS zu Gemüte zu führen, und das dann NICHT zu machen ;-)

Den Einwand "IDE macht eh alles" lasse ich nicht ganz gelten: ich lege 
Wert darauf, Code auch ohne IDE lesen zu können("literarisches 
Programmieren")

Autor: Achim S. (achs)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Michael R. schrieb:
> ich lege
> Wert darauf, Code auch ohne IDE lesen zu können("literarisches
> Programmieren")

und genau dieses "literarische" steht diametral zu "kryptisch".

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.