Variablen eindeutig benennen damit der Typ eindeutig ist

Der Typ ist eindeutig, egal, wie die Variable heißt.

Manche Leute benutzen eine Konvention, daß sie im Variablennamen den Typ 
codieren, am verbreitetsten ist die "ungarische" Notation mit 
vorangestellten Kürzeln wie z.B. einem kleinen "p" zur Kennzeichnung 
eines Pointers, ein "i" für Kennzeichnung eines Ints etc.

"Ungarisch" heißt diese Konvention, weil sie von Charles Simonyi 
entwickelt wurde (der aus Ungarn kommt und eine Zeitlang bei Microsoft 
gearbeitet hat).

https://en.wikipedia.org/wiki/Charles_Simonyi
https://en.wikipedia.org/wiki/Hungarian_notation

Eine weitere Konvention aus ähnlichem Dunstkreis ist "CamelCase", bei 
dem Variablennamen, die aus mehreren Wörtern zusammengesetzt werden, mit 
Großbuchstaben im Wort geschrieben werden - der Gegenentwurf ist die 
Verwendung von Unterstrichen:

MeineVariableIstSchoen
meine_variable_ist_schoen

Ersteres mit der ungarischen Konvention gepaart kann dann so aussehen:

1

pstrMeineVariableIstSchoen = "Bla";

2

dwMeineVariableIstSchoen = 0xFFEEDDCC;

3

iMeineVariableIstSchoen = 6;

4

dblMeineVariableIstSchoen = 12.34E4;

Wie gesagt, das liegt im Auge des Betrachters.


Wirklich wichtig ist es aber, die einmal gefundene Konvention 
konsequent beizubehalten oder wieder abzuschaffen, aber niemals 
mehrere Konventionen, gar konträre, miteinander zu mischen.

Ja, da halte ich doch gleich mal dagegen, daß ich es sehr praktisch 
finde, wenn ich mich um solchen Mist nur da kümmern muß wo ich es auch 
wirklich brauche.

$x=1234;
$x="Ach nee besser doch nicht.";
$x=(int)$x; wenns denn sein muß.

Ich bin mal einem von Betriebspraktikanten in jahrelanger Arbeit 
"gepflegtem" Projekt begegnet, in dem es allen Ernstes die folgenden 
Variablennamen gab:

a
aa
aaa
aaaa
aaaaa

In Projekten an denen ich arbeite ist die einzig übliche Notation 
typischerweise das m_-Präfix vor Membervariablen, um die Namenskollision 
mit einem Getter zu vermeiden. Andere Präfixe werden nicht benutzt, und 
ich halte sie auch nicht für hilfreich.

Moin,


Hier gibts neben guten Tipps zu Variablennamen noch mehr:

https://github.com/Droogans/unmaintainable-code

Gruss
WK

> wurde er zum ex-Kollegen
LOL! Das war dann wohl stepX().

El Helicoide schrieb:
> c-hater schrieb:
>> Nur Anfänger kommen überhaupt auf die Idee, sich um solchen völlig
>> unwichtigen Scheiss irgendwelche Gedanken zu machen. Damit du es
>> begreifst: es spielt absolut kein Rolle, welchen Namen ein Symbol
>> trägt.
>
> Es spielt also "absolut kein Rolle", welchen Namen ein Symbol trägt.

Tja. Ich hätte nie gedacht, daß ich das mal sage, aber wo er Recht hat, 
hat er Recht.

Namen von Symbolen sollten vor allem aussagekräftig für den Menschen 
sein, der den Code lesen und pflegen muß. Der Typ ist dafür in 99.9% der 
Fälle  aber vollkommen irrelevant bzw. wenn erforderlich, von der IDE 
mit nur einem Tastendruck abrufbar ("zeige die Definition des Symbols 
unter der Maus").

Darüber hinaus halte ich es für höchst problematisch, wenn es 
Variablen mit gleichem "Grundnamen", aber verschiedenem Typ gibt. Also 
bspw.

1

pstrMeineVariableIstSchoen = "Bla";

2

dwMeineVariableIstSchoen = 0xFFEEDDCC;

3

iMeineVariableIstSchoen = 6;

4

...

wie weiter oben im Thread gesehen. Es gibt also genau gar keinen 
Grund, den Typ irgendwie in den Variablennamen aufzunehmen. Deswegen 
habe ich mich ungarischer Notation und ähnlichem Unsinn auch immer 
strikt verweigert. Probleme hatte ich damit übrigens noch nie, denn ich 
habe auch noch keinen ernstzunehmenden Programmierer getroffen, der auf 
ungarischer Notation bestanden hätte.

> Bisher war ich der Meinung, dass nur Pfuscher
> eine solche Meinung haben können.

Mit derartigen Ausfälligkeiten diskreditierst du dich nur selber.

Das Thema wurde hier im Forum schon sehr oft diskutiert. Hier sind zwei
Beispiele für recht lange Threads mit entsprechend vielen verschiedenen
Meinungen:

  Beitrag "Notation (Ungarische Notation)"
  Beitrag "Typpräfixe im Programmcode"

Meine Meinung: Die Kodierung des Typs in Variablennamen

- ist unnötig (beim Durchlesen von Programmcode interessiert der
  Variablentyp nur selten und wenn doch, ist er schnell anderweitig
  auffindbar),

- bringt einige Nachteile mit sich (flüssiges Lesen wird erschwert, nach
  einer Änderung des Typs müssen alle Vorkommen der Variable geändert
  werden) und

- eine konsequente Umsetzung ist ohnehin nicht praktikabel (bei
  selbstdefinierten Typen reicht ein Präfix aus 1 oder 2 Zeichen zur
  Typidentifikation nicht aus, und bei Funktionsnamen, wo zum Gesamttyp
  sowohl der Rückgabetyp als auch die Typen sämtlicher Argumente
  gehören, hört der Spaß endgültig auf).

Ganz abgesehen davon entspricht die Microsoftsche Ungarische Notation
nicht den ursprünglichen Ideen ihres Erfinders Simonyi. Zudem hat auch
Microsoft längst den Unsinn darin erkannt und verbietet mittlerweile (in
.NET-Bibliotheken) sogar ihre Nutzung.

Rufus Τ. F. schrieb:
> Ich bin mal einem von Betriebspraktikanten in jahrelanger Arbeit
> "gepflegtem" Projekt begegnet, in dem es allen Ernstes die folgenden
> Variablennamen gab:
>
> a
> aa
> aaa
> aaaa
> aaaaa

Vieleicht war das ein skalierbares Programm zum Batterie testen ;-)

Stefanus F. schrieb:
> Ein Kollege nannte seine Funktionen gerne step1(), step2(), step3() und
> so weiter. Als er dann mal eine Funktion einfügen sollte, nannte er sie
> step2b(). Er war davon überzeugt, dass das viel besser sei, als normale
> sprechende Namen, weil man so ihre Aufruf-Reihenfolge ablesen kann.

Ich finde diese Idee in manchen Kontexten (z.B. Handler in State 
Machines) gar nicht sooo verkehrt - aber unter der Voraussetzung dass 
der Indizierungspräfix den Kontext identifiziert und dass die einzelnen 
Steps auch noch einen semantischen Namensteil haben. Fiktives Beispiel

1

xfer00_Init

2

xfer01_SendRequest

3

xfer03_OnResponse

Ohne die Indizierung der Funktionen wäre sonst aus dem Code nur schwer 
ersichtlich in welcher Reihenfolge sie geplant waren.

Ansonsten halte ich nur in Ausnahmefällen es für sinnvoll übers Knie 
gebrochen den Typen in den Variablennamen hinen zu kodieren. Jede 
moderne IDE zeigt den einem genau so gut per Tooltip o.ä. an. Ungarische 
Notation bringt keinen Nutzwert, erwschwert nur das Lesen. Ausnahme 
wären wenn beispielsweise bei Konvertierungen inhaltlich gleiche Daten 
in unterschiedlichen Formaten vorliegen:

1

char *strAmount;

2

int iAmount;

3

float fAmount;

Moin,

Wie waers denn mit: Programmiersprache wechseln?
Es gibt Programmiersprachen, wo man sich ueber Variablennamen keine 
Gedanken machen muss - da heissen die einfach: r0..r31 oder a,x,y oder 
a,f,b,c,d,e,h,l... ;-D

Gruss
WK

Bei C-Programmen ist das eigentlich eine unsinnige Sache (wird ja auch 
im entsprechenden Wikipedia-Artikel zur Ungarischen Notation mit einigen 
Zitaten ziemlich zerrissen).

Ich programmiere jedoch viel in Assembler für MSP430 und da hilft mir 
folgende Konvention für Präfixe:

          signed  uns.  Bedeutung
------------------------------------------------------
 8 bit     b       c    "Byte" bzw. "Character"
16 bit     s       w    "Short" bzw. "Word"
32 bit     i       q    "Integer" bzw. "Quad Byte"
64 bit     l       o    "Long long" bzw. "Octo Byte"


"q" für "Quad Word" statt "dw", damit ich das Präfix auf 1 Zeichen 
limitieren kann, dasselbe bei 64 bit. Ist es ein Array, dann wird "a" 
davorgesetzt, bei Zeigern "p"; ergibt dann z.B. "ac" für einen String 
oder "pas" als Zeiger auf ein Array von signed 16-bit-Werten.


Weiters sind die Funktionen in entsprechenden Modulen untergebracht, die 
typischerweise mit 3 bis max. 5 Zeichen abgekürzt werden, gefolgt von 
einem Unterstrich und dem eigentlichen Variablennamen, also z.B.
"wPwr_BatVlt" oder "wPwr_UsbVlt" (unsigned 16 bit-Wert im Power-Modul, 
enthält Batterie/USB-Spannungswert) oder "sPwr_SysTmp" (signed 16 bit 
Systemtemperatur).

Dr. Sommer schrieb:
> C++ hat /keine/
> Structs, nur Klassen. Das Schlüsselwort "struct" definiert eine
> Klasse, in der per default alles "public" ist.

Genau das ist der Unterschied zwischen struct und class: die 
Sichtbarkeit der Member, wenn sie nicht explizit angegeben wird. Und 
weil es einen Unterschied gibt, gibt es eben sehr wohl beides in C++. 
struct und class sind nicht eben nicht ganz synonym.

Thomas M. schrieb:
> Dr. Sommer schrieb:
>> C++ hat /keine/
>> Structs, nur Klassen. Das Schlüsselwort "struct" definiert eine
>> Klasse, in der per default alles "public" ist.
>
> Genau das ist der Unterschied zwischen struct und class: die
> Sichtbarkeit der Member, wenn sie nicht explizit angegeben wird.
> Und weil es einen Unterschied gibt, gibt es eben sehr wohl beides in C++.

Es gibt beide Schlüsselwörter, aber das dahinterstehende Konstrukt ist 
das selbe. Ich kann von einer Klasse ableiten, ihr Memberfunktionen 
(auch virtuelle) geben, Elemente private machen u.s.w., und das ist 
völlig unabhängig davon, ob ich es mit dem Schlüsselwort "class" oder 
dem Schlüsselwort "struct" definiert habe. Mit "struct" definiert man in 
C++ also nicht das, was in C eine struct wäre, sondern eine Klasse, mit 
allen Features, die es für Klassen in C++ gibt.

Rolf M. schrieb:
> Es gibt beide Schlüsselwörter, aber das dahinterstehende Konstrukt ist
> das selbe.

Ja, das geht sogar soweit:

1

struct my_struct {

2

  int dummy;

3

}

4

5

void foo(){

6

  struct my_struct thing1;

7

  class my_struct *thing2;

8

9

  thing2 = &thing1; // Compiler meckert nicht

10

}

1

void foo(){

2

  struct my_struct thing1;

3

  class my_struct *thing2;

4

5

  thing2 = &thing1; // Compiler meckert nicht

6

}

Die Schlüsselworte "struct" und "class" sind hier überflüssig, der Typ 
heißt einfach nur "my_struct".

Direkt austauschbar sind struct und class nicht; der Unterschied ist die 
standardmäßige Zuordnung zu public bzw. private.

Rufus Τ. F. schrieb:
> Direkt austauschbar sind struct und class nicht; der Unterschied ist die
> standardmäßige Zuordnung zu public bzw. private.

Und dass man "class" bei Templates für Typ-Parameter verwenden kann, 
struct nicht.

a_zip schrieb:
> Trotz rudimentärer Kenntnisse in C, denn in Py definierst du eine
> Variable und der wird ein "passender" Typ zugeordnet.

In Python definiert man Variablen nicht. Man weist einfach was zu, und 
wenn sie noch nicht existiert, wird sie dann erzeugt. Und sie bekommt 
dann einfach den Typ, den die rechte Seite der Zuweisung hatte. Und bei 
der nächsten Zuweisung wieder. Nachteil ist, dass die Variable munter 
ihren Typ wechseln kann, ohne dass das an der Stelle auffält. Ein Fehler 
bei falschem Typ kommt dann erst später irgendwo tief in einem 
Funktionsaufruf. Und bei einem Tippfehler beim Variablennamen hat man 
schnell mal stillschweigend eine neue Variable angelegt, statt die schon 
existierende zu überschreiben. Das kann einen bei der Fehlersuche auch 
in den Wahnsinn treiben.

Präfixe für Typen finde ich meist überflüssig. Wichtig ist mir 
allerdings, schon im Namen zwischen lokalen und globalen Variablen zu 
unterscheiden.

Lokale Variablen fangen bei mir mit Kleinbuchstaben an, globale mit 
Großbuchstaben. Dasselbe bei Funktionsnamen. Funktionen, die nur mit 
lokalen Variablen arbeiten, fangen klein an. Funktionen, die auf globale 
Variablen zugreifen, bekommen einen Namen, der mit Großbuchstaben 
anfängt. Ausnahme ist nur 'main', da er von außen vorgegeben ist.

Die Länge der Variablen hängt davon ab, wie speziell die Aufgabe der 
Variablen ist, globale Variablen sind da naturgemäß länger.

Ich benutze auch einfache Buchstaben als lokale Variablen, die aber 
immer dieselben Aufgaben und denselben Typ haben, egal in welcher 
Funktion. Meist sind es diejenigen, die Kernighan&Ritchie schon in ihren 
Beispielfunktionen verwendet haben.

So ist 'i' immer die Indexvariable für einfache for-Schleifen und int. 
Stringanalyse wird mit 's' gemacht, ein Lesezeiger (const char *). 
Brauche ich mehrere Variablen dieser Art, fangen sie ebenfalls mit 's' 
an, also s1,s2 ... oder zB sr für Reststring. Das Schreiben von Strings 
geschieht entsprechend mit 't' (für target) als Schreibzeiger (char *).

Rolf M. schrieb:
> In Python definiert man Variablen nicht. Man weist einfach was zu, und
> wenn sie noch nicht existiert, wird sie dann erzeugt

Ja, sorry, habe ich auch so gemeint...Katzenklappe = 3...
Gruß Rainer

Rolf M. schrieb:
> In Python definiert man Variablen nicht. Man weist einfach was zu, und
> wenn sie noch nicht existiert, wird sie dann erzeugt. Und sie bekommt
> dann einfach den Typ, den die rechte Seite der Zuweisung hatte. Und bei
> der nächsten Zuweisung wieder. Nachteil ist, dass die Variable munter
> ihren Typ wechseln kann, ohne dass das an der Stelle auffält. Ein Fehler
> bei falschem Typ kommt dann erst später irgendwo tief in einem
> Funktionsaufruf. Und bei einem Tippfehler beim Variablennamen hat man
> schnell mal stillschweigend eine neue Variable angelegt, statt die schon
> existierende zu überschreiben. Das kann einen bei der Fehlersuche auch
> in den Wahnsinn treiben.

Ach naja, so einen Fehler kann man sich in C++ mit dem Shadowing auch 
leicht bauen ...

Sven B. schrieb:
> Rolf M. schrieb:
...

Ja, aber...und wenn es hier vielleicht nicht hingehört...du arbeitest 
fast immer mit Klassen, deren Methoden und Funktionen im Modul definiert 
sind. Damit ist schon eine große Eindeutigkeit gegeben. Weiß nicht, ob 
das in C genau so ist, aber in einer OO-orientierten Sprache sollte das 
relativ eindeutig u n d lesbar sein oder?
Gruß Rainer

Sven B. schrieb:
> Ach naja, so einen Fehler kann man sich in C++ mit dem Shadowing auch
> leicht bauen ...

Man muß aber die dann folgende Compiler-Warnung nicht ignorieren.

Dr. Sommer schrieb:
> Und indem man globale Variablen ganz vermeidet spart man sich auch diese
> Komplexität.

Und schafft sich durch die Vermeidung neue Komplexitäten. Mir sind 
globale Variablen lieber als lange Parameterlisten, in denen dann oft 
immer wieder dasselbe steht. Da finde ich globale, also 
funktionsübergreifende Variablen für das, was man immer wieder braucht, 
deutlich praktischer. Je kürzer die Parameterlisten, um so weniger muss 
man auf die Reihenfolge achten.

Manche Daten braucht man dauerhaft. Da finde ich es weder sinnvoll, die 
alle in main als lokale Variablen zu deklarieren, noch sie mit static 
auf die Funktionen zu verteilen.

Dr. Sommer schrieb:
> Daher kapselt man zusammen gehörende Daten in Klassen.

Aber innerhalb einer Klasse sind die meisten Variablen eben nicht lokal. 
Bei einer Quelldatei pro Klasse sind die Membervariablen im gesamten 
Quelltext verfügbar und damit global.

Dr. Sommer schrieb:
> Jobst Q. schrieb:
>> Bei einer Quelldatei pro Klasse sind die Membervariablen im gesamten
>> Quelltext verfügbar und damit global.
>
> Nur in den Funktionen eben dieser Klasse. Sie sind eben nicht global.
> Dass Member-Funktionen einer Klasse auf die Member-Variablen zugreifen
> ist klar - sonst wären es keine Member-Funktionen - womit sich die
> Konvention mit der Großschreibung dann erledigt.

Es geht mir um die wesentliche Unterscheidung zwischen lokalen und 
nicht-lokalen Variablen. Die nicht-lokalen Variablen fangen bei mir mit 
Großbuchstaben an. Wenn dich daran die Bezeichnung global stört, ersetz 
es einfach durch nicht-lokal.

Jobst Q. schrieb:
> Es geht mir um die wesentliche Unterscheidung zwischen lokalen und
> nicht-lokalen Variablen.

Diese Unterscheidung macht doch nur Sinn in einer Nicht-OO-Umgebung! 
Wenn du z.B. die Parameter eines Fensters in eine Klassendefinition 
packst, dann kannst du überall mit Class.Param drauf zugreifen und in 
der Klasse hast du möglicherweise den Typ expliziert definiert...das ist 
aber alles andere, als in einem "normalen" Progrämmchen Variablen als 
global zu definieren!
Gruß Rainer

Joern DK7JB .. schrieb:
> Wie benennt ihr eure Variablen eindeutig in der Programmiersprache C
> damit eindeutig ist welcher Typ verwendet worden ist? Gibt es da eine
> bewährte Methode oder erfindet da jeder Programmierer das Rad neu?

Benutzt Ihr keine IDE? Meine Bezeichner sind unterschiedlich bunt, und 
wenn ich darüber "hover", bekomme ich den Typ auch angezeigt ...

Leute, diese ganze Diskussion stammt doch aus einer Zeit, als man noch 
mit Zeileneditoren wie ed arbeitete.

Stefanus F. schrieb:
> Wilhelm M. schrieb:
>> Leute, diese ganze Diskussion stammt doch aus einer Zeit, als man
>> noch mit Zeileneditoren wie ed arbeitete.
>
> Oder Arduino IDE. Die war damals um 2020 noch sehr aktuell und weit
> verbreitet.

Was war nochmal Arduino?

Stefanus F. schrieb:
>>>> Leute, diese ganze Diskussion stammt doch aus einer Zeit, als man
>>>> noch mit Zeileneditoren wie ed arbeitete.
>
>>> Oder Arduino IDE. Die war damals um 2020 noch sehr aktuell und weit
>>> verbreitet.
>
> Wilhelm M. schrieb:
>> Was war nochmal Arduino?
>
> Diese komische altmodische Entwicklungsumgebung ohne Debugger.
> Give me Five!

Ich bin enttäuscht: wir beweisen doch die Korrektheit ;-)

Der Typ ist nur selten für das Verständnis wichtig. Ich hab schon genug 
damit zu tun, kurze und die Funktion beschreibende Namen auszudenken, da 
muß ich nicht noch die Lesbarkeit durch unnütze Präfixe und Suffixe 
erschweren.

Profi schrieb:
> Eine der erfolgreichsten Software Firmen ist Microsoft. Eine der
> Ursachen ist, sie beginnen jede Variable mit einem Typvorsatz und die
> Teile der Namen beginnen mit einem Großbuchstaben. Es gibt Profis und
> Stümper. Man sollte von den Profis lernen.

Wie schon in diesem Thread erwähnt wurde, hat selbst Microsoft 
eingesehen, dass das Unsinn war.

Yalu X. schrieb:
> Ganz abgesehen davon entspricht die Microsoftsche Ungarische Notation
> nicht den ursprünglichen Ideen ihres Erfinders Simonyi. Zudem hat auch
> Microsoft längst den Unsinn darin erkannt und verbietet mittlerweile (in
> .NET-Bibliotheken) sogar ihre Nutzung.

A. S. schrieb:

> Typo-Konventionen (z.B. CamelCase oder _)

Ich wusste gar nicht, dass es für Schreibfehler (typo) Konventionen gibt 
;-)

Egon D. schrieb:
> Alles, was nicht auf Deinen Garten beschränkt ist, ist
> global?
>
> Ich würde eher verschiedene Grade von Lokalität unterscheiden
> (blocklokal, funktionslokal, modullokal,...).

Dann sagt lokal garnichts mehr aus. Blocklokal ist zwar möglich, aber 
nicht sinnvoll. Modullokal ist eben nicht mehr lokal, man könnte 
modulregional sagen, wenn man das Wort global nicht mag.

Solange ein Programm nur aus einem Modul bzw einem Quelltext besteht, 
ist global und modulregional identisch. Erweitert man nun das Programm 
um ein Modul, sind alle bisher globalen Variablen nicht mehr global im 
Sinne von programmweit gültig, obwohl sich nichts an ihnen geändert hat. 
Global wären dann nur noch Variablen, die als extern deklariert sind.

Der Unterschied zwischen modulweit und programmweit ist also eher 
theoretischer Natur. Dagegen ist der Unterschied zu (funktions-)lokalen 
Variablen drastisch und von großer praktischer Bedeutung.

Lokale Variablen sind im allgemeinen auch temporär, also zeitlich nur 
gültig solange sie abgearbeitet wird. Es gibt zwar auch die Möglichkeit 
statische Variablen in einer Funktion zu deklarieren, das schafft aber 
meist mehr Probleme als sie löst.

Jobst Q. schrieb:
>> Ich würde eher verschiedene Grade von Lokalität unterscheiden
>> (blocklokal, funktionslokal, modullokal,...).
>
> Dann sagt lokal garnichts mehr aus. Blocklokal ist zwar möglich, aber
> nicht sinnvoll. Modullokal ist eben nicht mehr lokal, man könnte
> modulregional sagen, wenn man das Wort global nicht mag.

Deine Definition von "lokal" beschränkt sich auf eine Weltsicht von "es 
gibt Funktionen und die haben ein drinnen (lokal) und ein draußen 
(global)". Das ist manchmal sinnvoll und manchmal nicht. Vor allem 
schränkt es dich in deiner Denkweise stark ein.

Wenn ich ein Buch verleihe, dann mache ich es jemandem zugänglich, der 
außerhalb meines Scopes liegt (ergo: nicht lokal). Aber deswegen mache 
ich es noch lange nicht jedem Menschen auf dieser Welt zugänglich (ergo: 
nicht global).

Im Übrigen nutze ich blocklokale Variablen sehr gerne (z.B. in 
Schleifen).

Jobst Q. schrieb:

> Solange ein Programm nur aus einem Modul bzw einem Quelltext besteht,
> ist global und modulregional identisch. Erweitert man nun das Programm
> um ein Modul, sind alle bisher globalen Variablen nicht mehr global im
> Sinne von programmweit gültig, obwohl sich nichts an ihnen geändert hat.
> Global wären dann nur noch Variablen, die als extern deklariert sind.

Eine etwas merkwürdige Logik. Wenn man ihr weiter folgt, wären alle 
lokalen Variablen auch global, solange man nur eine Funktion (also 
main()) hat, da man sie ja dann auch vom ganzen Programm aus sieht und 
sie auch über die gesamte Programmlaufzeit existieren.

A. S. schrieb:
> Und die wiederum hat viele Blöcke, von denen aus
> gesehen es lokale (nur innerhalb dieses Blocks)
> und globale (oberhalb dieses Blocks) Variablen gibt.

Membervariablen sind aus mehreren Blöcken (nämlich den Methoden) 
erreichbar, gleichzeitig aber nur von dort.

Wie würdest du sie einordnen? Lokal, global oder doch keins davon?

Rolf M. schrieb:
> Jobst Q. schrieb:
>
>> Solange ein Programm nur aus einem Modul bzw einem Quelltext besteht,
>> ist global und modulregional identisch. Erweitert man nun das Programm
>> um ein Modul, sind alle bisher globalen Variablen nicht mehr global im
>> Sinne von programmweit gültig, obwohl sich nichts an ihnen geändert hat.
>> Global wären dann nur noch Variablen, die als extern deklariert sind.
>
> Eine etwas merkwürdige Logik. Wenn man ihr weiter folgt, wären alle
> lokalen Variablen auch global, solange man nur eine Funktion (also
> main()) hat, da man sie ja dann auch vom ganzen Programm aus sieht und
> sie auch über die gesamte Programmlaufzeit existieren.

Das ist nicht meine Logik, deshalb "im Sinne von programmweit gültig". 
Von manchen wird global so verstanden, ich habe es eher als nicht-lokal 
verstanden und so ist auch die Unterscheidung in meiner 
Benennungskonvention: Nur lokale (temporäre) Variablen beginnen mit 
Kleinbuchstaben.

S. R. schrieb:
> Membervariablen sind aus mehreren Blöcken (nämlich den Methoden)
> erreichbar, gleichzeitig aber nur von dort.
>
> Wie würdest du sie einordnen? Lokal, global oder doch keins davon?

Könnte man regional nennen.

c-hater schrieb:
> unsäglichen C-Only-Wichsern

Sagt der unsägliche c-hater.

Dr. Sommer schrieb:
> c-hater schrieb:
>> C-only-Wichser
>
> Ja, gute Programmierer können auch noch mehr Sprachen wie Python, Scala,
> Scheme, Mathematica, SQL, Haskell, Erlang, JavaScript, Java, ... und
> können von dort Paradigmen übernehmen.

Und gute Programmieren können vor allem auch Assembler, oft von all 
den Sache, mit denen sie im Läufe der Jahrzehnte Kontakt hatten. z80, 
8048, 8051, x86, AVR, ARM jeweils privat, oder eben /370 beruflich, wenn 
auch schon 2 Jahrzehnte nicht mehr.
Einfach nur die Mainstreamsprache zu hassen ist keine Leistung. Selbst 
wenn man bei C die Freiheit hat sich Probleme einzufangen, Assembler ist 
C darin haushoch überlegen.

Rufus Τ. F. schrieb:
> Eine weitere Konvention aus ähnlichem Dunstkreis ist "CamelCase", bei
> dem Variablennamen, die aus mehreren Wörtern zusammengesetzt werden, mit
> Großbuchstaben im Wort geschrieben werden

 Am übersichtlichsten.
 Den Typ da noch reinzuquetschen ist vollkommen überflüssig.

Axel S. schrieb:
> sein, der den Code lesen und pflegen muß. Der Typ ist dafür in 99.9% der
> Fälle  aber vollkommen irrelevant bzw. wenn erforderlich, von der IDE
> mit nur einem Tastendruck abrufbar ("zeige die Definition des Symbols
> unter der Maus").

 Genau.
 Und "Konstanten.hh" und "Variablen.hh" mit Blöcken für verschiedene
 Routinen, wo Variablen und Konstanten zusammengelegt werden, machen
 das Ganze übersichtlich genug.

Rufus Τ. F. schrieb:
> Ich bin mal einem von Betriebspraktikanten in jahrelanger Arbeit
> "gepflegtem" Projekt begegnet, in dem es allen Ernstes die folgenden
> Variablennamen gab:
>
> a
...
> aaaaa

 In kurzen Routinen mache ich mir nicht die Mühe, Variablen,
 insbesondere die Loop- und Umrechnungsvariablen, anders als x,y,z,
 zu benennen.

Blechbieger schrieb:
> Also zumindest bei geschachtelten Schleifen und mehrdimensionalen Arrays
> verwende ich sprechende Laufvariablen da man selber oder der nächste sie
> zu leicht verwechselt.

'laufvariable' ist vielleicht geschwätziger, sagt aber auch nicht mehr 
als 'i'. Und wenn es um verschachtelte Schleifen geht, sagt 'i1' 'i2' 
usw auch ohne Buchstabenballast etwas über die Tiefe der Verschachtelung 
aus.

Carl D. schrieb:
> Selbst wenn man bei C die Freiheit hat sich Probleme einzufangen,
> Assembler ist C darin haushoch überlegen.

Das ist signaturverdächtig. :-)

Blechbieger schrieb:
> Also zumindest bei geschachtelten Schleifen und mehrdimensionalen Arrays
> verwende ich sprechende Laufvariablen da man selber oder der nächste sie
> zu leicht verwechselt.

 Kommt darauf an.
 x,y,z können nur Loop- oder Umrechnungsechnungsvariablen sein.
 Wenn man sich angewöhnt hat, die Variablen auch in dieser Reihenfolge
 zu verwenden, gibt es keine Probleme, da immer Array[x][y][z].
 Dabei ist für mich x immer die Breite, y die Höhe und z die Tiefe.
 Das hat auch noch den Vorteil, dass man nicht raten muss, ob diese
 Variablen noch für irgendetwas anderes benutzt werden.
 Natürlich benutze ich auch sinnvolle Namen - da wo es nötig ist.

 Ausführliche Kommentare (auch schon bei der Deklaration der
 Variablen/Konstanten) finde ich jedoch viel nützlicher.
 Man lernt so etwas spätestens dann zu schätzen, wenn nach ein paar
 Monaten etwas im Programm geändert werden muss.

Rufus Τ. F. schrieb:
> Ich bin mal einem von Betriebspraktikanten in jahrelanger Arbeit
> "gepflegtem" Projekt begegnet, in dem es allen Ernstes die folgenden
> Variablennamen gab:
>
> a

 Wenn wir schon von Kollegen reden - schreibfaule Typen, die Zeilen
 sparen wollen sind (für mich) viel schlimmer.
 Wir hatten mal einen, der fast immer Dutzend oder mehr Variablen, die
 zwar alle vom selben Typ waren, aber quer durch Programm in
 verschiedenen Routinen benutzt wurden, in einer Zeile deklariert hat,
 um Deklarationen so kurz wie möglich zu halten - prost mahlzeit.

C und C++ sind nicht stark typisiert, sodass die Verwendung von einer 
Notation durchaus
nützlich sein kann. Vergleiche beispielsweise implizite casts unsigned 
and signed
Typen unterschiedlicher Bitbreite in C und Go.

Am besten eine funktionale Sprache ohne Variablen verwenden ... F# oder 
Haskell ;)

Carl D. schrieb:
> Und gute Programmieren können vor allem auch Assembler, oft von all
> den Sache, mit denen sie im Läufe der Jahrzehnte Kontakt hatten.

Nicht jeder gute Programmierer hat vor mehreren Jahrzehnten angefangen, 
die damaligen Systeme (mangels Alternativen) in Assembler zu 
programmieren. Manche sind auch schlicht nicht alt genug.

Anfänger schrieb:
> Wenn C++ keine structs hätte, gäbe es in C++ das Schlüsselwort "struct"
> nicht bzw. müsste bei Verwendung zu einer Fehlermeldung führen.

Das ist doch nur eine Definitionsfrage.

C++ hat keine „reinen“ structs, das Schlüsselwort "struct" ist dort nur 
ein alternatives Schlüsselwort für Klassen.

Aber das wurde nun schon zur Genüge hier durchgekaut.

Anfänger schrieb:
> Ob cplusplus.com nun EINE Referenz für C++ ist oder eben DEINE Referenz
> für C++ gerade nicht ist, spielt keine Rolle. Tatsache ist, es gibt das
> Schlüsselwort struct in C++, nur dessen Bedeutung ist halt anders als in
> C, siehe
>
> https://de.cppreference.com/w/cpp/keyword
> https://namespace-cpp.de/std/doku.php/kennen/keywords

Nunja, die einzige wirkliche Referenz für C++ ist die ISO-Spezifikation. 
Dort heißt es in Kapitel 9 "Classes":

A structure is a class defined with the class-key struct; its members 
and base classes (clause 10) are public by default

Rolf M. schrieb:
>
> A structure is a class defined with the class-key struct; its members
> and base classes (clause 10) are public by default

was den Vorteil hat, kompatibel zu bestehendem C-Code zu sein.
Das, die Kompatibilität zur Vorgängern/Vorversionen ist der Grund für 
jede C++ "Sprachungereimtheit". Das ist aber auch der Grund dafür, daß 
sich C++ mit so vielen "besseren" Sprachen vergleichen lassen muß. Es 
hat sie schlicht alle überlebt.

Carl D. schrieb:
> Rolf M. schrieb:
>>
>> A structure is a class defined with the class-key struct; its members
>> and base classes (clause 10) are public by default
>
> was den Vorteil hat, kompatibel zu bestehendem C-Code zu sein.

Ja, das Schlüsselwort struct existiert hauptsächlich aus Gründen der
Abwärtskompatibilität zu C und nicht etwa, um dem faulen Programmierer
das Tippen des Wörtchens "public" zu ersparen. Es wäre ja sonst ziemlich
unsinnig, für die beiden Dinge (class und struct), die sich lediglich in
der defaultmäßigen Sichtbarkeit ihrer Elemente unterscheiden, so völlig
unterschiedliche Bezeichnungen zu wählen.

Deswegen benutze ich struct ausschließlich C-like, d.h. für reine
Datenstrukturen ohne Elementfunktionen, und class ausschließlich für
echte Klassen, d.h. solche, die nicht nur Datenelemente, sondern auch
Elementfunktionen enthalten. Auch eine (selten vorkommende) echte
Klasse, in der sämtliche Elemente public sind, ist bei mir eine class,
auch wenn ich mit struct etwas weniger zu tippen hätte.

Das ganze ist natürlich eine eher philosophische bzw. linguistische
Frage, aber wenn man schon die freie Wahl hat, dürfen auch mal die
Geisteswissenschaften zu Wort kommen ;-)

Yalu X. schrieb:
> Deswegen benutze ich struct ausschließlich C-like, d.h. für reine
> Datenstrukturen ohne Elementfunktionen, und class ausschließlich für
> echte Klassen, d.h. solche, die nicht nur Datenelemente, sondern auch
> Elementfunktionen enthalten. Auch eine (selten vorkommende) echte
> Klasse, in der sämtliche Elemente public sind, ist bei mir eine class,
> auch wenn ich mit struct etwas weniger zu tippen hätte.

Den besten Vorschlag den ich zu dieser Unterscheidung gehört habe, war 
"class" für Dinge zu verwenden, die eine Invariante haben. Wenn jeder 
beliebige Wert für jedes der Member ok ist, ist "struct" meist sinnvoll. 
Das passt auch ziemlich gut zu dem, was man so intuitiv tun würde. Es 
passt auch gut zu dem "alles ist public"-Konzept.

W.S. schrieb:
> nein, man muß auch alle gängigen Typen umbenennen und alle Zahlen außer
> 0 und 1 aus einem anständigen Programm entfernen und durch Bezeichner
> ersetzen, die dann in 37 verschiedenen Fremd-Dateien verschiedener
> Hersteller in die betreffende Zahl umgesetzt werden - und

Es ist bestens bekannt, daß Du Fan von "magic numbers" im Quelltext 
bist, denn die lassen sich ja viel einfacher im Datenblatt finden.

W.S. schrieb:
> Das zuständige Hardware-Register, wo die Zahl reinkommt, findet man im
> RefManual ganz leicht.

Ärgerlicherweise wird das Hardwareregister dort aber mit einem Namen 
angesprochen, statt dessen viel eindeutigere und verständlichere Adresse 
zu verwenden. Denn letztlich ist doch genau das Deine

> ultimative Vorschrift zum Bilden eines qualifizierten Variablennamens.

Das hier ist doch viel verständlicher und eingängiger :

1

  *(unsigned char *) 0x1A &= ~1;

2

  *(unsigned char *) 0x1A |= 2;

als das hier:

1

  DDRA &= ~(1 << PA0);

2

  DDRA |= (1 << PA1);

oder?

W.S. schrieb:
> Reißt euch zusammen und kreiert endlich die ultimative Vorschrift zum
> Bilden eines qualifizierten Variablennamens. Die Welt wartet sehnsüchtig
> drauf!

 Niemand zwingt dich dazu, deine Variablen so zu benennen - bleib
 doch einfach bei: a, ab, abc etc. wenn dich das glücklich macht.

 Zusätzlich zu den sinnvollen Variablennamen setze ich bei Konstanten
 immer ein c_ davor, etwa so:

1

#define c_SOF    0xAA

2

#define c_EOF    0xA9

3

4

// Position in Buffer

5

#define c_RcvAdr  0x01

6

#define c_SndAdr  0x02

7

#define c_CmdTyp  0x03

8

#define c_CmdLen  0x04

9

#define c_DatBlk  0x05

10

11

#define c_DatBlkLen  0x3F  // 63 Byt max

 So weiss ich immer womit ich es zu tun habe und kann die
 Variablen ohne Probleme so deklarieren:

1

typedef struct {

2

    uint8_t   Msg_SOF;

3

    uint8_t   RcvAdr;

4

    uint8_t   SndAdr;

5

    uint8_t   CmdTyp;

6

    uint8_t   CmdLen;

7

    uint8_t   DatBlk[c_DatBlkLen];

8

} USART_RAM;

9

USART_RAM UartRam; // CRC/ChkSum und EOF werden danach gesendet

 Und wenn du es irgendwann einmal zu einem sinnvollem  Programm,
 welches länger als 5 Zeilen eigenes Code ist, schaffen solltest,
 wirst du es wahrscheinlich selber so machen.

 Natürlich, bei Copy&Paste braucht man sich keine Gedanken darüber
 zu machen - Autor hat es wahrscheinlich schon getan - also bleib
 ruhig bei kopieren.

Marc V. schrieb:
> Ausführliche Kommentare (auch schon bei der Deklaration der
>  Variablen/Konstanten) finde ich jedoch viel nützlicher.

Grundsätzlich ein falscher Ansatz, aber ... nicht immer.

Jedesmal wenn es einen juckt einen Kommentar zu formulieren sollte man 
zuvor überlegen, ob nicht der gleiche Informationsgewinn durch 
Umbenennen des Bezeichners möglich ist. Zieht man das durch, bleibt 
erstaunlich wenig übrig, das eines Kommentars bedarf und der Code wird 
viel leichter verständlich.

doof:

1

ulong i = 0; // Index für Dingse

besser:

1

ulong dingsIdx = 0;

Marc V. schrieb:
> setze ich bei Konstanten
>  immer ein c_ davor, etwa so:
> #define c_SOF 0xAA

Die allgemein übliche Konvention für Macros ist es, deren Namen in 
Versalien zu schreiben. Deine "Konstanten" sind nämlich keine, sondern 
Macros.

Wenn das eine Konstante sein soll, muss es so aussehen:

1

const uint8_t c_SOF = 0xAA;

A. S. schrieb:
> Und warum nicht direkt Strukturen verwenden?

Macht er doch, die Konstante (genauer: das #define) taucht als Anzahl in 
dem Array aus Strukturen auf, das er anlegt.

Ich bezog mich hierauf:

1

uint8_t DatBlk[c_DatBlkLen];

(nein, ein Array aus Strukturen ist das gar nicht, da hab' ich mich 
offensichtlich vertan)

Wozu die anderen "Konstanten" gut sein sollen, hatte ich mir gar nicht 
angesehen.

Ich versteh gar nicht, warum hier so viel auf C++, class und struct 
rumgekaut wird, darum ging es dem OP doch gar nicht.

"Variablen eindeutig benennen damit der Typ eindeutig ist" - eigentlich 
kann man sich die Frage selbst beantworten, indem man mal den Quellcode 
von einigen Open Source-Projekten überfliegt, die soetwas nutzen und 
sich daran orientieren: gängige Konvention ist wohl, dass dafür Präfixe 
verwendet werden, wenn auch in unterschiedlichen Ausformungen. Ich 
persönlich halte nicht viel davon. Letztlich kommt es, wie oft schon 
angesprochen, auch darauf an, was für das jeweilige Projekt 
vorgeschrieben ist. Für private Sachen kann man es dann halten, wie man 
will.

Viel schlimmer als Variablen mit Präfixen zu versehen finde ich in C 
eher die Unart von vielen Bibliotheken, für die primitiven Typen eigene 
typdefs zu definieren. Statt mit etwas Einheitlichem wie uint32_t darf 
man sich dann mit UINT, uint, UINT32, U32, u4 etc. herumschlagen. Hier 
wäre es mir echt lieber, wenn nicht jeder das Rad neu erfinden bzw. 
älterer Code in dieser Hinsicht mal gewartet werden würde.

Stefanus F. schrieb:
> Ich glaube das hat historischen Grund.

Ja, vor allem sind manche Betriebssystem-APIs auch ziemlich alt; das von 
MS verwendete Namensschema (BYTE, WORD, DWORD etc.) ist bald 30 Jahre 
alt (ich hab' zwar noch nie ein Windows 2.x-SDK gesehen, aber das werden 
sie nicht für Windows 3.0 erst so erfunden haben, und das kam im Mai '90 
raus).

c-hater schrieb:
> eigene Arbeit mit Blut, Schweiss und Tränen

Wenn Du doch nur einfach C programmieren gelernt hättest, wäre Dir viel 
davon erspart geblieben.

c-hater schrieb:
> Aber: Der Unterschied zu C ist: Hier kann man nicht nur (fast) alle
> typischen Fehler eines Assemblerprogrammierers begehen (denn die stehen
> einem fast alle durch die mögliche Maschinennähe von C genauso frei zur
> Verfügung), man kann DARÜBER HINAUS auch noch Unmassen C-Fehler begehen.

Die Wahrscheinlichkeit, dass ich einen halbwegs komplexen Ausdruck wie

1

  f = x + 2 * y * (z-1)

in Assembler falsch beschreibe, sind deutlich höher als in C.
Selbst dann noch, wenn man Überläufe usw. berücksichtigt.

Die Wahrscheinlichkeit, dass ich aus einem Array den falschen Wert lese, 
weil ich mich bei der Indexberechnung verhakle, ist in Assembler 
deutlich höher als in C.

Und ja, ich habe schon einiges mit Assembler gearbeitet (und auch 
absichtlich). Es gibt Situationen, in denen will man Assembler. Das sind 
aber äußerst wenige und selbst dort ist C-Interoperabilität hilfreich.

A. S. schrieb:
> kleinen Kontext. Der einzige gemeinsame Nenner der 6 Konstanten (warum
> auch immer die bei 1 anfangen) ist das c_.

 Weil Offset 0 immer SOF ist.
 Und wenn du den Rest nicht verstehst (bzw. keinen gemeinsamen Nenner
 siehst), brauchen wir auch nicht weiter darüber zu diskutieren.

A. S. schrieb:
> wofür c_RcvAdr, wenn es nur offsetof RcvAdr ist? In den meisten fällen
> schreibt man doch eh X.RcvAdr. Und wenn man den Index braucht ...
 Deswegen vielleicht:

1

union {

2

  USART_RAM sRam;

3

  uint8_t sbuff[5 + c_DatBlkLen + 3];

4

} Uart_un;

 ?
 Ich bin mit solcher Bezeichnungsart bisher ganz gut gefahren,
 habe auch nach mehreren Monaten keine Probleme zu verstehen, was
 es bedeuten soll.

Thomas M. schrieb:
> Jedesmal wenn es einen juckt einen Kommentar zu formulieren sollte man
> zuvor überlegen, ob nicht der gleiche Informationsgewinn durch
> Umbenennen des Bezeichners möglich ist. Zieht man das durch, bleibt
> erstaunlich wenig übrig, das eines Kommentars bedarf und der Code wird
> viel leichter verständlich.

 Also, das stimmt bestimmt nicht, zumindest nicht für einigermassen
 komplexe Programe.
 Ich wollte schon unzählige Male beim ändern bzw. erweitern eines
 Programs klüger sein als beim schreiben, ein paar Bytes/Takte einsparen
 aber das hat sich ohne entsprechende Kommentare oft genug als ein
 Schuss nach hinten erwiesen.

 Wie gesagt, das alles mag Geschmacksache sein, nicht aber in einem
 Team - da fliegt man ohne entsprechend kommentierten Code ganz
 schnell raus.
 Und bei Variablen wie a, aa, aaa... erst recht.

Dr. Sommer schrieb:
> Die Welt ist kein Wunschkonzert. Nicht jeder kann deiner kruden
> Weltsicht folgen.

Nun bin ich erst mal (wieder) überrascht, wieviele Beiträge sich zu so 
einem Blödsinn sammeln. Blödsinn, weil wenn privat, dann Jacke wie 
Hose...wenn Profi, dann gibt es eine bindende(!) Vorschrift, wie 
Programme geschrieben werden müssen!! Wenn nicht, dann reden wir von 
einer "Klitsche", die nicht besser als "privat" ist! Und hier melden 
sich offensichtlich Repräsentanten aller Kathegorien...zumindes die 
"Profis" hätte ich hier nicht erwartet :-)
Gruß Rainer

Rainer V. schrieb:
> wenn Profi, dann gibt es eine bindende(!) Vorschrift, wie
> Programme geschrieben werden müssen!! Wenn nicht, dann reden wir von
> einer "Klitsche", die nicht besser als "privat" ist!

Was mich an diesem Forum immer beeindruckt ist das Muster aus diesem 
Post: "Ich bin Profi und mache alles superprofessionell. Wenn ihr das 
weniger professionell macht, seid ihr doofe Noobs!"

Und dann muss natürlich der nächste kommen und zeigen, dass er noch 
professioneller ist als das, weil er noch irgendeine wirre Maßnahme 
ergreift, bei der alle die das nicht machen doofe Noobs sind. Bis man 
bei irgendsoeinem absurden theoretischen Professionalitätsniveau 
angelagt ist, was mit der Realität nur noch wenig und mit der 
ursprünglichen Frage und Situation garantiert überhaupt nichts mehr zu 
tun hat. Nur damit jeder mal gezeigt hat, wie professionell er ist.

Das lustige daran ist, dass diese Posts immer darauf aus sind, andere 
mit der eigenen Erfahrung zu beeindrucken. Diesen Zweck verfehlen sie 
aber zuverlässig bei allen Lesergruppen.

Die tatsächlich erfahrenen Leute haben erfahrungsgemäß eine deutlich 
entspanntere Haltung zu vielen Dingen, und haben erkannt dass es meist 
viele Wege gibt, die zu einem vernünftigen Ergebnis führen. Die genaue 
Einhaltung eines einzelnen Konzepts ist dabei meist nicht so wichtig. 
Anders gesagt: An dem herummaulen was andere tun ist leicht. Schwieriger 
ist, konstruktiv darauf aufzubauen und ausgehend von der Situation des 
anderen einen pragmatischen Verbesserungsvorschlag zu machen.

Rufus Τ. F. schrieb:
> Es ist bestens bekannt, daß Du Fan von "magic numbers" im Quelltext
> bist, denn die lassen sich ja viel einfacher im Datenblatt finden.

Es ist viel schlimmer: Diese "Magic Numbers by W.S." müssen für jeden 
ATmega/ATTiny bei einer Portierung auf einen Verwandten der AVR-Familie 
neu angepasst werden, weil die Bits öfter mal an anderen Positionen im 
Register stecken. Unnötige Arbeit, wenn man die entsprechenden 
Preprocessor-Konstanten wie z.B. COM0A0 verwendet.

Allerdings kann man da auch auf die Nase fliegen, da sie nicht immer nur 
innerhalb desselben Registers "wandern", sondern manchmal - aber 
glücklicherweise selten - auch (je nach AVR) das Register wechseln.

Deshalb hatte ich vor ein paar Jahren mal ein Projekt "Registersichere 
Anwendung von Flags" vorgeschlagen. Leider ist es aus Zeitmangel nur bei 
einem Konzept geblieben. Es wäre nämlich eine Menge Arbeit gewesen, für 
alle AVRs sämtliche Register und deren Flags bzw. Bitgruppen vollständig 
und registersicher zu beschreiben. Mit diesem Werkzeug wäre es dann aber 
vollkommen egal, in welchem Register die Bits überhaupt stecken.

Siehe auch: Beitrag "Re: AVR-Register als Bitfields"

W.S. schrieb:
> Tja, gut gemeint... Da setzen sich Leute hin, um sich sowas wie c_ für
> Konstanten per #define auszudenken (und meinen dazu "So weiss ich immer
> womit ich es zu tun habe") - oder noch anderen Schmonzes.

 Mag für dich und andere Möchtegern- und Copy&Paste Experten Schmonz 
sein,
 für mich ist es nicht.

W.S. schrieb:
> auch zuende denken. Wenn man sowas wie
>
> #define c_ottokar 4711
>
> fordert, um das Konstantenhafte zu dokumentieren, was legt man dann für
> ne echte Konstante fest? Rufus hat das ja schon thematisiert:
>
> const int c_i_echt_ottokar = 4711;
>
> So? Oder wie sonst?

 Wie du nicht weisst, wird const ins Flash geschrieben, #define aber
 ist einfach eine Anweisung für Präprozessor.
 Einen Array mit festen Werten schreibe ich als:

1

static const uint8_t c_7seg[] = {

2

...

3

}

 und kann auch daraus lesen.

 So etwas kann man aber mit const nicht machen:

1

const uint8_t c_DatBlkLen = 0x3F;  // 63 Byt max

2

uint8_t   DatBlk[c_DatBlkLen];

 mit #define dagegen geht das ohne Probleme.

 Etwas, was mit #define definiert wurde, kann mit #undef wieder
 rückgängig gemacht werden.

 Wenn du mit Copy&Paste aufhörst, wirst du das (kaum wahrscheinlich
 aber immerhin zu 0,0001% möglich) auch verstehen.

Frank M. schrieb:

> Deshalb hatte ich vor ein paar Jahren mal ein Projekt "Registersichere
> Anwendung von Flags" vorgeschlagen. Leider ist es aus Zeitmangel nur bei
> einem Konzept geblieben. Es wäre nämlich eine Menge Arbeit gewesen, für
> alle AVRs sämtliche Register und deren Flags bzw. Bitgruppen vollständig
> und registersicher zu beschreiben.

Könnte man mittlerweile per xslt aus den XML-Beschreibungen machen.

Beim ATmega128RFA1 (und seinen Nachfolgern) hatten wir sowas ins 
offizielle Headerfile in der avr-libc reingepackt, aber das hat in der 
restlichen AVR-Welt innerhalb Atmel keinen Anklang gefunden. Seit sie 
nun all ihren eigenen Device-Support nur noch über ihre "device packs" 
verteilen (und damit eigene Headerfiles ausliefern, die nicht denen des 
avr-libc-Projekts entsprechen), dürfte das gänzlich den Bach 
runtergegangen sein.

A. S. schrieb:
> Sinnvolle Namen statt Kommentare (darum ging es)

Ich wiederhole mich ungern, aber dem TO kann man nur sagen, was Profis 
machen oder HiWis! Da sich hier lustigerweise sowohl Profis, als auch 
HiWis die Klinke in die Hand geben...was soll man da sagen...ich fand 
meinen Beitrag zur Mausefalle unterhaltsamer!
Gruß Rainer

Rainer V. schrieb:
> wenn Profi, dann gibt es eine bindende(!) Vorschrift, wie
> Programme geschrieben werden müssen!! Wenn nicht, dann reden wir von
> einer "Klitsche", die nicht besser als "privat" ist!

Ach was erzählst du da für einen Unsinn...
Professionell heißt nur, dass man damit Geld verdient und sagt nichts 
über die Qualität aus. Eine wie auch immer geartete, "bindende 
Vorschrift, wie Programme geschrieben werden müssen" ist ein 
untrügliches Zeichen dafür, dass man es entweder mit inkompetenten 
Idioten oder stark regulierten Märkten zu tun hat. Bei uns gibt es 
stattdessen mehrere Code-Reviews.

Marc V. schrieb:
>  Wie du nicht weisst, wird const ins Flash geschrieben, #define aber
>  ist einfach eine Anweisung für Präprozessor.

Auch "const" wird nicht ins Flash geschrieben, wenn es nicht ins Flash 
geschrieben werden muss. Stichwort Compiler-Optimierung.

Marc V. schrieb:
> So etwas kann man aber mit const nicht machen:
> const uint8_t c_DatBlkLen = 0x3F;  // 63 Byt max
> uint8_t   DatBlk[c_DatBlkLen];
> mit #define dagegen geht das ohne Probleme.

Auch das ist seit C99 schlicht falsch. Stichwort Variable Length Array.

Ein typischer Marc.

A. S. schrieb:
> Das glaube ich Dir. Es wird nur noch einfacher, wenn Du Dir redundante
> defines sparst. Poste ein Beispiel und ich spendiere Dir eine Kiste
> Bier, wenn ich es ohne Redundanz nicht einfacher hinbekomme .

 Nein, umgekehrt.
 Ich spendiere dir eine Kiste Bier, wenn du mir die Redundanz in
 meinem Beitrag zeigst.

A. S. schrieb:
> Das sind aber 2 verschiedene Baustellen:
>
> Sinnvolle Namen statt Kommentare (darum ging es)

 Nun, so sehe ich das bestimmt nicht.
 Sinnvole Namen und Kommentare sowohl für Variablen, als auch
 innerhalb des Programms.

 Und es geht natürlich um Programme die länger als ein paar Zeilen
 sind, mehr als ein Dutzend Variablen haben und wesentlich komplizierter
 als BlinkLed Beispiel sind.
 Da sind mehrere Dutzend includes, mit mehreren Tausenden von Linien.
 Wenn man da etwas ändern muss und dazu erst die Routine xxyyzz finden
 muss, um zu sehen was diese Routine überhaupt tut, anstatt dies gleich
 aus Kommentar zu sehen oder vielleicht sogar aus dem Namen, z.B:
 PutDateTimeToI2C().
 Genauso ist es mit Variable xxyyzz.

 Das dies alles auch unter der Maus angezeigt wird, ändert nichts an
 der Sache.

S. R. schrieb:
> Auch "const" wird nicht ins Flash geschrieben, wenn es nicht ins Flash
> geschrieben werden muss. Stichwort Compiler-Optimierung.

 Für mich bedeutet const eine readonly Variable, die demzufolge irgendwo
 im Flash abgelegt werden muss.
 Mit #define wird irgendetwas definiert, ob das ein Ausdruck, String
 oder schlicht ein Wert ist, ist absolut egal.

> Marc V. schrieb:
>> So etwas kann man aber mit const nicht machen:
>> const uint8_t c_DatBlkLen = 0x3F;  // 63 Byt max
>> uint8_t   DatBlk[c_DatBlkLen];
>> mit #define dagegen geht das ohne Probleme.
>
> Auch das ist seit C99 schlicht falsch. Stichwort Variable Length Array.

 Ahem.
 Kompiliere das mal bitte, so wie es da steht.
 Soviel ich und mein Compiler es wissen, geht das nur wenn man Array
 lokal deklariert, nicht aber wenn es global deklariert wird.

> Ein typischer Marc.
 Eher ein typischer svenska.

Dr. Sommer schrieb:
> Marc V. schrieb:
>> Mit #define wird irgendetwas definiert, ob das ein Ausdruck, String oder
>>  schlicht ein Wert ist, ist absolut egal.
>
> Ja, eine dumme Textersetzung. Das ist ein sehr grobes Werkzeug, da kann
> man schnell mal daneben hauen...

 Stimmt, allerdings kann man an vielen Stellen in einem Programm ganz
 schnell daneben hauen...
 Der einzige Nachteil von #define ist meiner Meinung nach die fehlende
 Prüfung auf ev. Fehler, deswegen mag die definition von Makros
 fehlerträchtig sein, aber Deklarationen von einfachen Positionen im
 Buffer bestimmt nicht.

Marc V. schrieb:
>> Auch "const" wird nicht ins Flash geschrieben, wenn es nicht ins Flash
>> geschrieben werden muss. Stichwort Compiler-Optimierung.
>
>  Für mich bedeutet const eine readonly Variable,
>  die demzufolge irgendwo im Flash abgelegt werden muss.

Das mag für dich so sein, der Compiler sieht das anders.

>> Marc V. schrieb:
>>> So etwas kann man aber mit const nicht machen:
>>> const uint8_t c_DatBlkLen = 0x3F;  // 63 Byt max
>>> uint8_t   DatBlk[c_DatBlkLen];
>>> mit #define dagegen geht das ohne Probleme.
>>
>> Auch das ist seit C99 schlicht falsch. Stichwort Variable Length Array.
>
>  Ahem.
>  Kompiliere das mal bitte, so wie es da steht.

1

$ cat test.c 

2

int main()

3

{

4

        const char x = 0x3F;

5

        char test[x];

6

7

        return 0;

8

}

9

$ gcc test.c

10

$ ./a.out 

11

$

Geht prima, wo ist dein Problem?

>  Soviel ich und mein Compiler es wissen, geht das nur wenn man Array
>  lokal deklariert, nicht aber wenn es global deklariert wird.

Dein geposteter Code enthält kein main(), lässt sich also nicht 
kompilieren. Ich habe mir nur die Freiheit genommen, eins einzubauen. 
:-)

>> Ein typischer Marc.
>  Eher ein typischer svenska.

Mir ging es darum, dich darauf hinzuweisen, dass deine beiden Aussagen 
maximal Halbwissen sind. Das stört vor allem, weil du immer in 
Absolutismen schreibst und selbstverständlich niemals Unrecht hast.

Ein "sowas kann man nicht machen" ist falsch, wenn man es eben doch 
meistens machen kann. Und mit Aussagen wie "wie du nicht weißt, gilt X" 
blamierst du dich vor allem dann, wenn X nicht uneingeschränkt gilt.

Und genau das ist typisch.
Damit wäre ich dann wieder raus, streitet euch mal weiter. :-)

A. S. schrieb:
> A. S. schrieb:
>> wofür c_RcvAdr, wenn es nur offsetof RcvAdr ist? In den meisten fällen
>> schreibt man doch eh X.RcvAdr. Und wenn man den Index braucht ...
>> doppelt gemoppelt failed schneller.
>
> Deshalb fragte ich fairer Weise nach einem sinnvollen Beispiel.

Marc V. schrieb:
> Deswegen vielleicht:
> union {
>   USART_RAM sRam;
>   uint8_t sbuff[5 + c_DatBlkLen + 3];
> } Uart_un;
>  ?

 Falls ich:

1

 sbuff[offsetof(UartRam, CmdTyp)]

 anstatt:

1

 sbuff[c_CmdTyp]

 verwende, habe ich deutlich mehr an vielen Stellen zu schreiben.
 Deklarieren tue ich es dagegen nur einmal ;)

S. R. schrieb:
>>  Ahem.
>>  Kompiliere das mal bitte, so wie es da steht.
> $ cat test.c
> int main()
> {
>         const char x = 0x3F;
>         char test[x];
>
>         return 0;
> }
> $ gcc test.c
> $ ./a.out
> $
>
> Geht prima, wo ist dein Problem?

 Sure.
 Und so ?

1

 const char x = 0x3F;

2

 char test[x];

3

int main()

4

{

5

//        const char x = 0x3F;

6

//        char test[x];

7

8

        return 0;

9

}

S. R. schrieb:
> Mir ging es darum, dich darauf hinzuweisen, dass deine beiden Aussagen
> maximal Halbwissen sind. Das stört vor allem, weil du immer in
> Absolutismen schreibst und selbstverständlich niemals Unrecht hast.

 Tja, eigentlich geht es mir so mit dir.

Joern DK7JB .. schrieb:
> Wie benennt ihr eure Variablen eindeutig in der Programmiersprache C
> damit eindeutig ist welcher Typ verwendet worden ist? Gibt es da eine
> bewährte Methode oder erfindet da jeder Programmierer das Rad neu?

Mir ist nicht ganz klar, wie man auf die Idee kommt, dass es sinnvoll 
wäre dies zu tun. Wie andere schon gesagt haben - jeder moderne Editor 
zeigt einem den Variablentyp an, wenn man z.B. kurz mit der Maus 
drübergeht.

Was immer sinnvoll ist, sind selbstsprechende Namen für Variablen und 
Funktionen. Man liest den Namen und schon weiß man um was es geht. 
Beispiele:

Vehicle_speed
RoomTemperature
TransmitBuffer[]

display_speed()
temperature_to_Fahrenheit()
isBufferFull()

A. S. schrieb:
> Und warum nicht sRam.CmdTyp? Wie gesagt, Fetzen bringen wenig.

 Weil sbuff ein Array ist und da ist sbuff[c_CmdTyp] für mich
 irgendwie logischer.
 sRam ist eine Struktur, da passt sRam.CmdTyp schon.

> Zumal es trotzdem nicht rechtfertigt, Struktur und define parallel zu
> pflegen.

 Mag sein, aber die sind gleich untereinander deklariert, zusammen mit
 allen anderen Variablen fur RS485.
 Die Namen sind vielleicht nicht ganz passend gewählt, aber das ganze
 funktionert seit vielen Jahren so, warum jetzt ändern ?

S. R. schrieb:
> Ach was erzählst du da für einen Unsinn...
> Professionell heißt nur, dass man damit Geld verdient und sagt nichts
> über die Qualität aus. Eine wie auch immer geartete, "bindende
> Vorschrift, wie Programme geschrieben werden müssen" ist ein
> untrügliches Zeichen dafür, dass man es entweder mit inkompetenten
> Idioten oder stark regulierten Märkten zu tun hat. Bei uns gibt es
> stattdessen mehrere Code-Reviews.

Also seid ihr Klitsche nach meinem Verständniss! Und es sagt erst mal 
auch gar nichts über die (welche) Qualität aus, was wem möglicherweise 
vorgeschrieben wird. Aber wenn mehr als 2 Mann/Frau an einer Software 
basteln, dann sind nicht nur die Übergabeparameter festgeschrieben, 
sondern auch der Stil der Programmierarbeit überhaupt! Wenn ich von 
einem Fuzzi 3 Mal in der Woche Module bekomme, die Fehler erzeugen, dann 
schau ich doch mal in dessen Quellcode und wehe, der ist anders als im 
Pflichtenheft geschrieben!
Und bitte verzeih', "Code-Review" hört sich für mich an wie 
"Therapeutensitzung"
Und klar heisst professionell, dass man Geld verdient...was sonst?
Gruß Rainer

Rainer V. schrieb:
> S. R. schrieb:
> Bei uns gibt es
>> stattdessen mehrere Code-Reviews.
>
> Also seid ihr Klitsche nach meinem Verständniss! Und es sagt erst mal
> auch gar nichts über die (welche) Qualität aus, was wem möglicherweise
> vorgeschrieben wird. Aber wenn mehr als 2 Mann/Frau an einer Software
> basteln, dann sind nicht nur die Übergabeparameter festgeschrieben,
> sondern auch der Stil der Programmierarbeit überhaupt! Wenn ich von
> einem Fuzzi 3 Mal in der Woche Module bekomme, die Fehler erzeugen, dann
> schau ich doch mal in dessen Quellcode und wehe, der ist anders als im
> Pflichtenheft geschrieben!
> Und bitte verzeih', "Code-Review" hört sich für mich an wie
> "Therapeutensitzung"

Genau! Bäm! Du Noob! Ich Profi! Überhaupt sind nur Leute mit 
Pflichtenheft Profis! Und Leute mit anderen etablierten Verfahren, wie 
Reviews, sind Noobs, weil ich als Profi das nicht mache und deshalb kann 
das gar nicht professionell sein!

Mehrere verschiedene Möglichkeiten, professionell zu arbeiten, sind 
grundsätzlich nicht vorstellbar: sonst ist das Feld der Professionalität 
ja vielleicht gar nicht total geordnet, und dann kann ich gar nicht ganz 
oben in der Hackordnung stehen.

Wie gesagt, dieses Muster ist hier im Forum echt typisch und es hat noch 
nie zu einer gewinnbringenden Diskussion geführt, ever. Es nervt nur 
alle: die Beteiligten und die Leser gleichermaßen.

In der Softwareentwicklung ist das besonders krass, weil es ohne 
Übertreibung hunderte solcher Vorgaben gibt, die von weiten Kreisen als 
ein absolutes Muss gehandelt sind, anderen hingegen völlig unbekannt 
sind. Deshalb kann man sich da trefflich stundenlang anmaulen, wer der 
größere Noob ist weil er keine Versionskontrolle // keine Reviews // 
kein Pflichtenheft // keine Style Guide // keine 
Dokumentations-Guideline // kein Scrum // kein whaaatever macht. 
Projekte wie der Code für die Mondrakete beweisen aber z.B., dass man 
sehr wohl ohne Versionskontrollsystem gute Software entwickeln kann ...
Man wird hier nicht dadurch zum Profi, dass man möglichst viele Punkte 
auf der Buzzword-Liste abhakt. Weniger ist manchmal sogar mehr.

S. R. schrieb:
> Marc V. schrieb:
>>  Wie du nicht weisst, wird const ins Flash geschrieben, #define aber
>>  ist einfach eine Anweisung für Präprozessor.
>
> Auch "const" wird nicht ins Flash geschrieben, wenn es nicht ins Flash
> geschrieben werden muss. Stichwort Compiler-Optimierung.

Das geht aber nur, wenn es static ist. Sonst muss sie im Flash stehen, 
da eine andere Übersetzungeinheit sie referenzieren könnte.

> Marc V. schrieb:
>> So etwas kann man aber mit const nicht machen:
>> const uint8_t c_DatBlkLen = 0x3F;  // 63 Byt max
>> uint8_t   DatBlk[c_DatBlkLen];
>> mit #define dagegen geht das ohne Probleme.
>
> Auch das ist seit C99 schlicht falsch. Stichwort Variable Length Array.

Die gibt es aber aus offensichtlichen Gründen nur bei lokalen Variablen.

Tatsächlich gibt es in C gar keine echten Konstanten. #define ist die 
beste Annäherung daran. Deshalb wird es auch so oft dafür verwendet. Ein 
const int ist keine Konstante, sondern eine Variable, die man nicht 
ändern darf. Und ja, das macht einen Unterschied. Beispiel:

1

const int a = 0;

2

const int b = a;

Das führt in gcc zu folgendem Fehler:

1

const2.c:20:15: error: initializer element is not constant

2

 const int b = a;

3

               ^

Sven B. schrieb:
> Genau! Bäm! Du Noob! Ich Profi! Überhaupt sind nur Leute mit
> Pflichtenheft Profis!

Mann, dich in einem Vorstellungsgespräch...göttlich...
und Betriebssystem "Hello World"...
Kleiner Mann mit peinlich kleinem Hut...
Rainer

Rainer V. schrieb:
> Mann, dich in einem Vorstellungsgespräch...göttlich...

Hmm, meinst du, es wäre besser, dir in einem Vorstellungsgespräch 
gegenüber zu sitzen?

Wenn ich es mir aussuchen kann, würde ich wohl Sven jederzeit den Vorzug 
geben. Leute mit Dogma mag ich nicht (weder als Chef noch als 
Mitarbeiter).

Ich habe schon an so vielen verschiedenen Projekten mitgearbeitet, dass 
ich mir die Flexibilität leisten muss, nicht auf einen coding style 
festgefahren zu sein. Auch ohne geschriebene coding guides kann man 
konsistenten Code produzieren, wenn man nur will. („Ungarische“ Notation 
war aber, von paar Win32-Syscalls in AVRDUDE abgesehen, bislang zum 
Glück noch nicht dabei.)

Sven B. schrieb:
> Projekte wie der Code für die Mondrakete beweisen aber z.B., dass man
> sehr wohl ohne Versionskontrollsystem gute Software entwickeln kann ...
> Man wird hier nicht dadurch zum Profi, dass man möglichst viele Punkte
> auf der Buzzword-Liste abhakt. Weniger ist manchmal sogar mehr.

Na ja, heutzutage kann man tatsächlich nicht mehr professionell ohne 
Versionskontrolle entwickeln. Alleine schon wenn man gegenüber dem 
Gutachter reproduzierbar nachweisen muss, welcher SW-Stand wann wie zur 
Zulassung gebracht werden soll oder wenn man eben Änderungen 
(nach-)dokumentieren muss.

Gehört nicht ohne Grund zum "Joel Test" ;-)

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/

Rolf M. schrieb:
>> Auch "const" wird nicht ins Flash geschrieben, wenn es nicht ins Flash
>> geschrieben werden muss. Stichwort Compiler-Optimierung.
>
> Das geht aber nur, wenn es static ist. Sonst muss sie im Flash stehen,
> da eine andere Übersetzungeinheit sie referenzieren könnte.

In der Theorie ja. In der Praxis gibt es auch link-time-optimization 
(gcc: -flto). Damit funktionieren solche Optimierungen auch über die 
Grenzen von Übersetzungseinheiten hinweg.

Axel S. schrieb:
>> Das geht aber nur, wenn es static ist. Sonst muss sie im Flash stehen,
>> da eine andere Übersetzungeinheit sie referenzieren könnte.
>
> In der Theorie ja. In der Praxis gibt es auch link-time-optimization
> (gcc: -flto). Damit funktionieren solche Optimierungen auch über die
> Grenzen von Übersetzungseinheiten hinweg.

 Mit switches kann man vieles anders machen und verdrehen, fragt sich
 nur ob das auch sinnvoll ist.
 Bei einem Teamprojekt steht der switch bei einem Kollegen so, bei
 anderen wiederum anders und schon werden aus selbem Code 4 verschiedene
 Versionen kompiliert - bei einem funktioniert es, bei anderem (der
 zufälligerweise gerade seine Routine geändert hat) nicht und dann
 geht die Sucherei los...

mh schrieb:
> Ernsthaft?
 Natürlich,

> Etwas überspitzt gefragt: Redet ihr in diesem "Team" auch
> miteinander?
 Ja, wir reden miteinander.

> Es gibt Dinge die sollte man im Team festlegen.
 Und es gibt Dinge, die soll man nicht mit Gewalt und ohne Grund
 ändern, nur damit man beweist, dass irgendein Beitrag in uC.net
 nicht stimmt.
 So etwas nennt sich Korinthenkackerei und es gibt ein paar
 Leute hier, die genau das immer wieder tun, nur um zu beweisen
 wie klug und allwissend sie sind und wie unwissend die
 anderen.

 Dass das genau nichts zum Thema beiträgt und dem TO in keiner
 Weise hilft, berührt diese Experten überhaupt nicht, Hauptsache
 die anderen werden als unwissend/halbwissend dargestellt...

 P.S.
 Aussage:
 Mercedes ist ein verkehrssicheres Fahrzeug.

 Behauptung:
 Ja, aber wenn man die Reifen auf 0,5 bar aufpumpt und dann mit
 200Km/h auf der Autobahn fährt, stimmt das überhaupt nicht...

 Schlussfolgerung:
 Die obige Aussage ist falsch und derjenige der das behauptet,
 hat überhaupt keine Ahnung von Fahrzeugen und fahren.

W.S. schrieb:

>> Das ist ja wohl eine perverse (="verdrehte") Weltsicht.
>> Das, was Du als "echte Konstante" bezeichnest, ist
>> technisch eine vorbelegte Variable.
>
> Du redes Unsinn. Das Obengenannte ist eine Konstante.

Nein, ist es technisch gesehen nicht. C kennt in diesem Sinne keine 
Konstanten, es ist eine Variable, bei dem Versuche, ihren Wert zur 
Laufzeit zu ändern, vom Compiler abgewiesen werden.

C++ kennt echte Konstanten, deshalb darf man sowas dort auch zur 
Definition der Größe eines (beliebigen) Arrays benutzen, was man in C 
nicht darf:

1