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
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
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
Ich neige sogar dazu zu sagen: Die Benutzung von Notationen unterscheitet den Profi vom Hobbyprogrammierer... ;-) MfG Andreas Jäger
Die ,,ungarische'' (eigentlich ja Microsoftsche) Notation ist unter C-Programmierern außerhalb der Microsoft-Schmiede größtenteils verrufen. Argumentationen dafür findest Du sicher genügend im Internet. Eigentlich hast Du das beste Gegenbeispiel ja schon selbst gegeben: uint8_t guiCounter; ...wäre für mich beim ersten Lesen ein Zähler, der irgendwas in einem GUI zählen soll. Die recht weit verbreitete Auffassung dagegen ist, daß es keinen Sinn hat. Wenn ein Programmierer sowas braucht, weil er sonst keinen Überblick mehr über seinen Code besitzt, dann hat er beim Design was vermasselt. Kurze, beschreibende Namen sind allemal praktischer. Aber bei MS's aufgeblasenen und oft völlig überladenen APIs ist das kein Wunder, daß sie sowas zum Hausstandard erhoben haben. ;-)
@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
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.
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
@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
Hallo Im Prinzip stimme ich dazu, aber man ist nicht immer in der glücklichen Lage neuen Code zu entwickeln, sonder meistens muß man bestehende Software umbauen, oder weiter entwickeln, und da hat man es mit Code anderer Leute zu tun, und der eine mag lieber Vanille, und der andere lieber Himbeer :-) Notationen sind da manchmal schon recht hilfreich...
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.
Was hat das miteinander zu tun? Nö, ich stimme dem einfach grundsätzlich nicht zu, daß eine solche ,,Notation'' dem Verständnis in irgendeiner Form zuträglich wäre. Entweder ist der Code ordentlich geschrieben, dann braucht's den Zirkus nicht, oder es ist schreckliches Kauderwelsch, dann hilft auch das "lp" oder "gui" oder sowas vor den Bezeichnern nicht. Ich habe schon gruseligsten ,,ungarischen'' Code gesehen, bei dem ich am Ende aus lauter Freundlichkeit dem, der es mir gegeben hat, den Code debuggen durfte (der andere hatte ihn aber nicht selbst geschrieben, zu seiner Ehrenrettung -- aber ich hätte diesen Code nichtmal benutzt). Da half der ganze MS-Stil, Verzeihung ungarische Notation, auch überhaupt nicht, daß Zeug war einfach nur grauenvolles Chaos. Zum anderen kannste mir glauben, daß ich bereits sehr viel C-Code verschiedenster anderer Autoren in der Mache hatte, den man auch ohne all sowas gut verstehen konnte, weil er sauber strukturiert war, mehr oder weniger ordentlich kommentiert, davon zeugend, daß der Autor auch sein Handwerkszeug verstanden hat. Klar, eine komplexe Aufgabe wie das Reinstricken der COFF-Debug-Erzeugung in die GNU Binutils hat mich auch erstmal einiges an Recherche gekostet um herauszufinden, welche Resourcen mir allesamt innerhalb der Binutils zur Verfügung stehen, und danach zu planen, wie ich das Problem denn angehen müßte. Aber das ist bei einer komplexen Aufgabe normal. Eine völlig andere Sache ist natürlich, daß ein Programm auch einen einheitlichen Stil verfolgen sollte. Es gibt nicht den richtigen davon, aber solange sie in sich konsistent sind, kann man damit leben. Wenn man für ein bestimmtes Projekt dann Ergänzungen verfaßt, hält man sich einfach mal an den Stil, in dem das schon verfaßt ist. Ich habe viel mit FreeBSD zu tun, da gibt's ein allgemeines Agreement, der in einer manual page namens style(9) zusammengefaßt ist. Nicht alles finde ich darin sinnvoll (bspw. werden dort die Ausdrücke nach einem »return« geklammert, also »return (0);« statt »return 0;«, hat historische Gründe), aber man kann damit leben. GNU sieht ein bißchen anders aus, kann man auch damit leben.
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.
Ohne ungarische Notation geht die Welt unter. Das muss mal ganz klar gesagt werden.
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.
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...
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.
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ß
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.
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.
Ist ja dann doch beruhigend, daß sich in den 15 Jahren seit Eröffnung dieses Threads was weiterentwickelt hat. Oliver
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
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.
Nix gegen den Unterstrich, da steh ich drauf :) Leichter schreibbar als m_ und unauffälliger als m :P
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.
> 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.
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_.
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.
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.
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!
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 ... ;-)
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..
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>
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".
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:
1 | Suffix Beispiel Datentyp |
2 | ——————————————————————————————————————————— |
3 | ohne BREITE 40-Bit-Floating-Point |
4 | % ANZAHL% 16-Bit-Integer |
5 | $ TEXT$ Textstring |
6 | ——————————————————————————————————————————— |
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:
1 | struct ResultType (*iA3_PF10ResultTypePKcE_tab[3])(const char *) = { |
2 | iF10ResultTypePKcE_foo, |
3 | iF10ResultTypePKcE_bar, |
4 | iF10ResultTypePKcE_baz
|
5 | };
|
Ein Aufruf einer Funktion aus der Tabelle könnte so aussehen:
1 | struct ResultType i10ResultType_qux; |
2 | int ii_index = 2; |
3 | 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 ;-)
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
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.
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
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.
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.
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...
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.
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.
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;
1 | auto tupiccptupdarri3_test {std::make_tuple( |
2 | 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!
Junge schrieb: > struct{ > } s_Auto; > > s_Auto oAuto1, oAuto2, oAuto3; Hat keinen Vorteil gegenüber struct Auto { }; struct Auto auto1, auto2, auto3;
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:
1 | uint16 v0 = adcValueList[0]; |
vs.
1 | 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.
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.
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 :-)
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 ...
Dieter F. schrieb: > Eine Bildungslücke - offensichtlic So wichtig wie Schellackplatten und Spieler mit 78 Umdrehungen!!
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 ...)
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. ;-)
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")
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".
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.