Ein solches Gesetz gibt es nicht.
Allerdings gibt's typischerweise in Datenblättern irgendwo eine
Registerübersicht, und die sollte irgendwie noch auf ein Blatt
passen. Daher wird man eher keinen Roman dort als Name haben wollen.
Torsten Robitzki schrieb:> Oder wie kann man sich Namen wie: NCR, NSR, NIPR, NPCR, NBTR etc.> erklären?
Schreibfaulheit. Reicht doch, und wer mit Registern arbeitet, muss eh'
verstehen, was er macht. Sind ja keine Zufallskombinationen, sondern
TLAs bzw. FLAs von beschreibenden Namen. C steht für Control, S steht
für Status, R für Register. Also sind die ersten beiden schonmal ein
N<irgendwas> Control- und Status-Register.
Torsten Robitzki schrieb:> Es gibt ein ungeschriebenes Gesetzt, nach dem dürfen Registernamen> maximal 8 Zeichen lang sein.
Ha! MeinMSP430 hat mehrere Register mit 9 Zeichen langen Namen!
(Allerdings habe ich nur eines mit 10 Zeichen gefunden: USBPLLDIVB.)
Das liegt wahrscheinlich daran, dass ältere Assembler und Compiler
längere Namen nicht unterstützt haben. Selbst C89 sagt noch (Abschnitt
3.1.2):
> The implementation may ... restrict the significance of an external name> (an identifier that has external linkage) to six characters and may ignore> distinctions of alphabetical case for such names.
(C99 hat das dann auf 31 Zeichen erhöht.)
ich würde das auch auf die Übersicht schieben.
Wenn ich eine ganze Batterie von Registern habe, bin ich doch schneller
wenn ich nur 3 Zeichen lesen bzw. suchen muss anstelle dass jedes
Register mit der vollen funktion benamt ist.
Hallo,
der Hinweis, mit den Symbollängen leuchtet mir ein. Ich kann mich noch
an Grafik-APIs aus dem Studium erinnern, die Funktionsnamen mit maximal
6 Zeichen hatten.
Ich habe hier gerade einen XMC4200, dessen Reference manual hat 2165
Seiten. Selbst wenn die Register 40 Zeichen lang wären, könnte ich mir
nicht vorstellen, dass das manual deutlich länger wird. Ich könnte mir
aber vorstellen, dass es deutlich lesbarer wird.
Bei dem Ding passt die Beschreibung eines einzigen Registers schon
häufig nicht mehr auf eine Din A4 Seite ;-)
Wahrscheinlich ist der Grund für die kurzen Registernamen, dass es mal
einen Grund gab und nun hat sich jeder dran gewöhnt und keiner
hinterfragt es.
mfg Torsten
Torsten Robitzki schrieb:> Wahrscheinlich ist der Grund für die kurzen Registernamen, dass es mal> einen Grund gab und nun hat sich jeder dran gewöhnt und keiner> hinterfragt es.
Programmiert wird ja nicht erst seit vorgestern, sondern schon zu Zeiten
als Bildschirme noch eine deutlich geringere Auflösung hatten. Jeder
Programmierer hätte sich bedankt, wenn eine einzelne ASM-Anweisung nicht
in eine Zeile gepasst hätte, nur weil den Entwicklern dieses Controllers
bei der Registerbenennung die Phantasie durchgegangen ist.
mfg.
Thomas Eckmann schrieb:> Jeder> Programmierer hätte sich bedankt, wenn eine einzelne ASM-Anweisung nicht> in eine Zeile gepasst hätte, nur weil den Entwicklern dieses Controllers> bei der Registerbenennung die Phantasie durchgegangen ist.
Ich würde mich auch heute noch bedanken wenn ich statt
TIMSK |= (1<<TOIE0);
das hier:
TIMER_COUNTER_INTERRUPT_MASK_REGISTER |=
(1<<TIMER_COUNTER_0_OVERFLOW_INTERRUPT_ENABLE);
schreiben dürfte
Torben H. schrieb:> Ich würde mich auch heute noch bedanken wenn ich statt> TIMSK |= (1<<TOIE0);> das hier:> TIMER_COUNTER_INTERRUPT_MASK_REGISTER |=> (1<<TIMER_COUNTER_0_OVERFLOW_INTERRUPT_ENABLE);> schreiben dürfte
Kannst Du das nicht per Definition zuweisen?
Ja, da würde ich mich dem Dank wirklich anschließen ;-) Das kann man
dann sofort verstehen, auch wenn man mal ein Jahr nichts mit dem
entsprechendem Controller gemacht hat. Wir arbeiten ja auch nicht mehr
mit 14" Monitoren.
Die Software ist ja nur ein Aspekt. Der andere Aspekt ist die
Dokumentation.
Wenn ich den Code nach einem Jahr wieder in die Hand nehme, dann muss
ich das Datenblatt sowieso noch mal (zumindest in Teilen) lesen. Und
dann weiß ich auch ganz schnell wieder, was TIMSK ist. Und mit einem
passenden PDF-Editor kannst du auch mit suchen und ersetzen durch das
Datenblatt gehen... Ich bin jedenfalls froh das Code und Datenblatt
nicht mit solchen Spaghettibezeichnern gefüllt sind.
Torsten Robitzki schrieb:> Wir arbeiten ja auch nicht mehr> mit 14" Monitoren.
Ja, heute haben wir 10" draufgelegt.
Stell dir vor, hinter den Anweisungen stehen noch Kommentare. Wenn du
dir das Programm dann durchliest bewegst du deinen Kopf hin und her wie
die Zuschauer eines Tennisspiels. Und wenn du das jeden Tag machst,
gehst du irgendwann auch abends so nach Hause.
mfg.
Torsten Robitzki schrieb:> Hat hier jemand soweit Einblick in die inneren Kreise von> Hardware-Entwicklungsabteilungen, dass er meine Vermutung bestätigen> kann?:>>
Torsten Robitzki schrieb:> Ja, da würde ich mich dem Dank wirklich anschließen ;-) Das kann man> dann sofort verstehen, auch wenn man mal ein Jahr nichts mit dem> entsprechendem Controller gemacht hat. Wir arbeiten ja auch nicht mehr> mit 14" Monitoren.
Ich habe sehr oft auf dem Laptop 2 Editorfenster nebeneinander geöffnet,
dann ist man froh, wenn die Zeilen nicht zu lang sind. Einen so
überbordenden Namen wie TIMER_COUNTER_0_OVERFLOW_INTERRUPT_ENABLE muss
man zudem richtiggehend lesen, während man es bei kürzeren Namen direkt
sieht. Des weiteren muss man sich beim tippen merken, wo die Underlines
sind und welche Wörter allenfalls doch noch abgekürzt werden, es könnte
z.B. ja auch TIMERCOUNTER0_OVERFLOW_INT_ENA heissen.
Ich bin letztlich auch eher ein Verfechter selbsterklärender
Variablenamen, allerdings immer mit dem Ziel, diese nicht unnötig lange
zu machen.
P. M. schrieb:> Ich bin letztlich auch eher ein Verfechter selbsterklärender> Variablenamen, allerdings immer mit dem Ziel, diese nicht unnötig lange> zu machen.
Erinnert mich an einer meiner Professoren aus dem ersten Semester Uni.
Da gab es die "Dateiverarbeitungsvariable1" und die
Dateiverarbeitungsvariable2"
Im Ernst. Bei diesen Kürzeln gibt es praktisch immer so etwas wie eine
Nomenklatur. Hat man die erst mal intus, dass ist das alles kein
wirkliches Problem mehr.
Karl Heinz schrieb:> Erinnert mich an einer meiner Professoren aus dem ersten Semester Uni.> Da gab es die "Dateiverarbeitungsvariable1" und die> Dateiverarbeitungsvariable2"
Dümmer gehts fast nicht ;-) Da nimmt er also einen endlos langen Namen,
aber das eigentlich interessante - was die Variable macht - versteckt
sich hinter einer Zahl. Das würde doch eher z.B. heissen "quelldatei"
und "zieldatei" oder was auch immer sich hinter 1 und 2 versteckt.
Nein, eigentlich nicht wirklich. Ersten wäre es recht viel Arbeit,
zweitens wäre mein Code dann für die Kollegen, die diese
Registerabkürzungen auswendig kennen unnötig unlesbar.
Wie wäre es mit:
P. M. schrieb:> Karl Heinz schrieb:>> Erinnert mich an einer meiner Professoren aus dem ersten Semester Uni.>> Da gab es die "Dateiverarbeitungsvariable1" und die>> Dateiverarbeitungsvariable2">> Dümmer gehts fast nicht ;-)
Der Prof war ein älterer Herr, der seine Berufslaufbahn dem Vernehmen
nach bei ... wie hiess noch mal die Bank mit angeschlossener
Elektroabteilung ... ach ja ... Siemens absolviert hat.
Das erklärt ja dann wohl alles.
Torsten Robitzki schrieb:> Wie wäre es mit:> TIMER_COUNTER.INTERRUPT_MASK.OVERFLOW = ENABLED;
Ich wäre eher ein Fan von solcherlei (hypothetisches device, nur
beispielhaft):
Vernünftiger als superlange Registernamen ist es wohl, sich Wrapper für
Registerzugriffe zu basteln. Im Anwendungscode steht dann nirgendwo
PORTA |= (1 << LED1), sondern bloss led_on(LED1).
P. M. schrieb:> Vernünftiger als superlange Registernamen ist es wohl, sich Wrapper für> Registerzugriffe zu basteln. Im Anwendungscode steht dann nirgendwo> PORTA |= (1 << LED1), sondern bloss led_on(LED1).
Bei mir wird dann eher set_pin(LED1) oder SET_PIN(LED1) stehen,
denn wenn ich schon eine Funktion, welche normalerweise nur einen Pin
auf high setzt, schreibe, sie aber led_on nenne, kann man gleich soweit
gehen, das man eine Funktion led1_on() schreibt ;)
Michael M. schrieb:> Bei mir wird dann eher set_pin(LED1) oder SET_PIN(LED1) stehen,> denn wenn ich schon eine Funktion, welche normalerweise nur einen Pin> auf high setzt, schreibe, sie aber led_on nenne, kann man gleich soweit> gehen, das man eine Funktion led1_on() schreibt ;)
Das Problem bei set_pin(LED1) ist dann aber wiederum, dass je nach
externer Beschaltung die LED an oder aus geht. Habe ich
Pin->LED->R->GND, dann geht die LED beim setzen des Pins aus, habe ich
VCC->LED->R->PIN, dann geht sie beim setzen an. Also muss ich den
Anwendungscode ändern, wenn sich die Hardware ändert.
Thomas Eckmann schrieb:> Torsten Robitzki schrieb:>> Wir arbeiten ja auch nicht mehr>> mit 14" Monitoren.>> Ja, heute haben wir 10" draufgelegt.>> Stell dir vor, hinter den Anweisungen stehen noch Kommentare. Wenn du> dir das Programm dann durchliest bewegst du deinen Kopf hin und her wie> die Zuschauer eines Tennisspiels. Und wenn du das jeden Tag machst,> gehst du irgendwann auch abends so nach Hause.>> mfg.
Bei verständlichen Code brauchts wenig Kommentare. Ich bin froh, wenn
ich solche langen Bezeichnungen finde, die selbsterklärend sind. Ich
beschäftige mich ständig mit anderen Prozessorfamilien (x86,PPC,Ti32Bit
DSPs,8-Bit Atmels/Freescale)und Programmiersprachen ( c++, Csharp,
phyton, matlab...) Da hab ich nicht jedes mal den Nerf Datenblätter
herraus zu kramen. Wenn ich jedes mal beim per Du mit den Registernamen,
Speicheradressen und HW-Befehlen ankommen müsste ,käme ich zu nichts..
Bernd K. schrieb:> Torsten Robitzki schrieb:>> Wie wäre es mit:>> TIMER_COUNTER.INTERRUPT_MASK.OVERFLOW = ENABLED;>> Ich wäre eher ein Fan von solcherlei (hypothetisches device, nur> beispielhaft):>
1
> TIM0->INTMSK = TIM_INTMSK_OVERFLOW
2
> | TIM_INTMSK_CHANNEL_A
3
> | TIM_INTMSK_CHANNEL_B;
4
>
5
> TIM0->CONFIG = TIM_CONFIG_FOO
6
> | TIM_CONFIG_BAR
7
> | TIM_CONFIG_CLKSRC_BUSCLK
8
> | TIM_CONFIG_PRESCALE_DIV8;
9
>
10
>
Sowas geht, ich habe hier mal diesen Weg experimentell beschritten:
Beitrag "AVR-Register als Bitfields"
Mir fehlt leider nur die Zeit, das komplett durchzuziehen - für alle
8-Bit-AVRs.
Ich hasse Unterstriche. Da muss ich jedes Mal am Wortende nachsehen, ob
das Wort nicht doch noch weitergeht...
Oder wem (ausser dem Compiler) fällt der Unterschied hier sofort auf:
A. K. schrieb:> Mir wär MixedCase auch lieber.
Ich nutze gerne beides. Mixed case für Members, Underlines für andere
Variablen oder Spezialfälle, beispielsweise wenn man eine ganze Liste
ähnlicher Variablen hat, z.B. idx_bottom_left, idx_bottom_right, ...
Lothar Miller schrieb:> Oder wem (ausser dem Compiler) fällt der Unterschied hier sofort auf:> TIM_CONFIG CLKSRC_BUSCLK
Naja, dieser Einwand ist eher etwas konstruiert, praxisfern. Sowas
streicht ne durchschnittliche C/C++ IDE normalerweise schon beim
Schreiben mit deutlichen Markierungen an, da hätt ich keine Probleme den
Fehler binnen Sekunden zu bemerken.
Ich halte mich selber eigentlich meist genau an die Registernamen des uC
User Manuals. Wenn man sich daran hält gibt es keine Mißverständnisse
und kann sich immer auf die richtigen Stellen im Manual beziehen. Man
braucht für ein Projekt meist sowieso nur eine bestimmte Anzahl dieser
Register und ich merke mir die mit der Zeit.
Mfg,
Gerhard
P. M. schrieb:> Michael M. schrieb:>> Bei mir wird dann eher set_pin(LED1) oder SET_PIN(LED1) stehen,>> denn wenn ich schon eine Funktion, welche normalerweise nur einen Pin>> auf high setzt, schreibe, sie aber led_on nenne, kann man gleich soweit>> gehen, das man eine Funktion led1_on() schreibt ;)>> Das Problem bei set_pin(LED1) ist dann aber wiederum, dass je nach> externer Beschaltung die LED an oder aus geht. Habe ich> Pin->LED->R->GND, dann geht die LED beim setzen des Pins aus, habe ich> VCC->LED->R->PIN, dann geht sie beim setzen an. Also muss ich den> Anwendungscode ändern, wenn sich die Hardware ändert.
Grundsätzlich hast du recht, aber wenn du die Hardware so abänderst, wie
du es gesagt hast, dann musst du auch irgendwo den Code ändern, bei dir
dann z.B. in der Funktion. Die Frage ist dann halt, was schöner ist.
Wahrscheinlich ist eine Kombination das beste, also eine boardabhängige
Schicht, welche solche Funktionen wie info_led_on() beinhaltet, und in
diesen wird dann auf die wiederverwendbare Schicht wie set_pin(LED1)
zugegriffen.
Gibt es eigentlich irgendwo Texte/Infomaterial über dieses Thema?
Bis jetzt hab ich mir nur immer fremden Code angesehen, und überlegt,
warum es vielleicht so oder so gelöst wurde.
Michael M. schrieb:> Grundsätzlich hast du recht, aber wenn du die Hardware so abänderst, wie> du es gesagt hast, dann musst du auch irgendwo den Code ändern, bei dir> dann z.B. in der Funktion. Die Frage ist dann halt, was schöner ist.> Wahrscheinlich ist eine Kombination das beste, also eine boardabhängige> Schicht, welche solche Funktionen wie info_led_on() beinhaltet, und in> diesen wird dann auf die wiederverwendbare Schicht wie set_pin(LED1)> zugegriffen.
Kann man so machen, ja. Wichtig ist halt, dass der eigentliche
Anwendungscode und der hardwareabhängige Code ganz klar getrennt sind.
P. M. schrieb:> Michael M. schrieb:>> Grundsätzlich hast du recht, aber wenn du die Hardware so abänderst, wie>> du es gesagt hast, dann musst du auch irgendwo den Code ändern, bei dir>> dann z.B. in der Funktion. Die Frage ist dann halt, was schöner ist.>> Wahrscheinlich ist eine Kombination das beste, also eine boardabhängige>> Schicht, welche solche Funktionen wie info_led_on() beinhaltet, und in>> diesen wird dann auf die wiederverwendbare Schicht wie set_pin(LED1)>> zugegriffen.>> Kann man so machen, ja. Wichtig ist halt, dass der eigentliche> Anwendungscode und der hardwareabhängige Code ganz klar getrennt sind.
Ich finde Wartbarkeit, also eine klare Struktur im Code und Doku (mache
ich leider oft selbst nicht ;) sind am wichtigsten. Und
Wiederverwertbarkeit ist auch ganz schön, so spart man sich Arbeit ;)
Und hardwareunabhängiger Code ist bei kleinen 8 bis 16
Bit-Mikrocontrollern immer so eine Sache, da finde ich eine klare
Struktur im Aufbau des Projektes, welche man schnell versteht wichtiger.
Und dann kann man schauen, welche Dinge man Hardware unabhängig machen
kann, und in eine Bibliothek oder ähnliches Packt.
Ist eigentlich so was wie red_led_on() Hardwareunabhängig ;) ?
Ich war beim Schreiben von Programmen an der Arbeit immer ein Freund
vernünftiger Programmnamen:
LIEBE->Lagerung In Einem Betriebsteil Extern
KAUZ->Kaufteile Zusammenfassung
BUMMI->Baugruppen Und Maschinenteile Mit Interner Fertigung
Das wußten meine Kollegen auch zu würdigen und haben mir dabei
zugearbeitet.
;-)
(Das waren noch vernünftige, gute Leute...)
mfG Paul
Frank M. schrieb:> Stimmt, musste auch erst 3mal drüberschauen.
Gute Quote: einen Fehler gefunden und nur einen übersehen... ;-)
Bernd K. schrieb:> Naja, dieser Einwand ist eher etwas konstruiert, praxisfern. Sowas> streicht ne durchschnittliche C/C++ IDE normalerweise schon beim> Schreiben mit deutlichen Markierungen an
Aber wenn du einen Quelltext einfach nur liest, dann siehst du das
nicht, sondern du musst jedem einzelnen Unterstrich hinterherhecheln.
Und sobald der Quelltest aus diesem a_u_s_s_c_h_w_e_i_f_e_n_d_e_n Grund
lang und holprig wird und nicht mehr ohne Kopfverrenkung lesbar ist,
dann hilft auch das Gemecker des Editors nichts.
Aber lassen wird das, Thema waren ja nicht die unsäglichen Unterstriche
(an die man übrigens auf einer amerikanischen Tastatur mit nur einem
Tastendruck rankommt), sondern die Kürze von Mnemonics und Registern...
Ich verwende auch gerne TLA oder FLABs (wie jede Berufsgruppe, wo man
schnell mal reagieren muss, nur Patentanwälte schreiben "Zentrale
Prozessoreinheit" statt "CPU"). Und zudem muss man sich ja vom Laien
abgrenzen können... ;-)
Lothar Miller schrieb:> Gute Quote: einen Fehler gefunden und nur einen übersehen... ;-)
Dafür hätte ich 6mal drübersehen müssen ;-)
> Aber lassen wird das, Thema waren ja nicht die unsäglichen Unterstriche> (an die man übrigens auf einer amerikanischen Tastatur mit nur einem> Tastendruck rankommt), [...]
Nö. Der Unterstrich liegt auf der amerikanischen Tastatur rechts neben
der 0 und ist nur zusammen mit der Shift-Taste erreichbar. Dort ist das
Minus. Shift + Minus = Unterstrich.
Ich verwende als C-Programmierer viel lieber eine amerikanische
Tastatur, nämlich wegen ' ; / \ [ ], welche alle über einen Tastendruck
erreichbar sind. Aber auch { } usw. bediene ich lieber über Shift als
über die zusätzliche Taste ALT, welche man hier gar nicht braucht.
Michael M. schrieb:> Und ich finde den Unterstrich leichter Lesbarer als CamelCase.
Geht mir genauso.
ReadTheFuckingValueIfLightGoesOff() finde ich nicht besonders gut
lesbar. Die Unterstriche haben da eine ähnliche Wirkung wie Leerzeichen:
Sie trennen Wörter. Damit ist der Lesefluß und das Verständnis zwischen
den Ohren, was das denn nun zu bedeuten hat, einfacher und fixer.
Lothar Miller schrieb:> Aber wenn du einen Quelltext einfach nur liest, dann siehst du das> nicht, sondern du musst jedem einzelnen Unterstrich hinterherhecheln.
Ich sehe aber immer noch nicht wie der Unterstrich überhaupt
versehentlich verloren gehen kann. Wenn er mal da war und der Code schon
mal kompiliert hat dann bleibt er da bis ans Ende der Zeit, es sei denn
es sind zeichenfressende Heinzelmännchen heimlich nachts zugange.
Und beim Schreiben von neuem Code hat man ja sowieso seinen Editor der
permanent Syntax und Grammatik checkt, und beim Studieren von fremdem
Code an/mit dem man zu arbeiten gedenkt meistens auch.
Ich finde jedenfalls Unterstriche keineswegs schlechter oder besser als
CamelCase, es ist nur so daß es (in C) breiter Konsens ist Makro-Namen
in all-upper mit Unterstrichen zu schreiben und daran (und auch andere
Konventionen) versuche ich mich so gut es geht zu halten (je nach
verwendeter Sprache die einschlägigen Style-Guides).
Das deutliche Großschreiben von Makros im Gegensatz zu allem anderen
dient übrigens auch der Lesbarkeit, gerade in C mit seinem Preprozessor
und der daraus resultierenden irrsinnig kontextbehafteten Grammatik
eines Quelltextes ist es schon hilfreich auf den ersten Blick zu sehen
was was ist ohne vor dem Lesen erst mal alle benötigten Header ins
Gehirn geladen zu haben.
Das ist übrigens der große Vorteil von Pascal gegenüber C, da kann man
völlig kontextfrei irgendwo mittendrin anfangen zu lesen und alles
ergibt sofort einen Sinn.
