Hallo Leute,
ich hoffe ihr könnt mir helfen und bedanke mich schon im Voraus.
meine Problem ist:
Ich habe eine Variable Temp1 sie verändert sich mit der Zeit entweder
vorwärts oder rückwärts. Durch diese Variable will eine andere
(Temp2)steueren.
Wie kann ich abfragen ob die erste Variable kleiner oder größe wird ??
(in C)
mein Ansatz sieht so aus :
if (Temp1 kleiner wird)
{
Temp2++;
}
else if (Temp1 größer wird)
{
Temp2++;
}
wie kann ich das machen mit kleiner oder größer wird.
vielen Dank
genauso (mit der kleinen Einschränkung dass man lastTemp1=Temp1; am
Anfang des Programms durchführen sollte).
Aber mal ehrlich: auf so etwas bist du nicht selber gekommen? Vielleicht
solltest Du das mit dem Programmieren-lernen nochmal überdenken - ich
glaube das ist nichts für dich.
dein Codegerüst (genauso wie das laberkoppsche) muss wiederholt mehrmals
durchschritten werden, Idealerweise in gleichmässigen Zeitabständen.
(-->Schlaufen, Interrupts, Timer, ...)
Nur so kann mittels der Hilfsvariable lastTemp1 ein älterer Wert
gespeichert werden, um im späteren Durchlauf zwecks Vergleich herhalten.
Der allererste Durchlauf wird entsprechend noch kein korrektes
Vergleichsergebnis liefern: dagegen sind "harmlose" Vorkehrungen zu
treffen... (--> Initialisierung)
Nein: eine "automatische Variablenwertbeobachtung" gibt es in C nicht,
dazu ist diese Sprache zu wenig "hochsprachig"...
Ich glaube nicht, dass das Programmieren die richtige Beschäftigung für
Dich ist;-)
Du hast irgendwo die Frage gestellt: Wo speichere ich den Vergleichswert
Temp1 und folglich eine Variable mit Namen Tem1 angelegt.
Anschließend hat sich die spannende Frage: Wo speichere ich den
Vergleichswert Temp2 ab, aufgetan. Worauf Du die Variable Temp2 angelegt
hast.
Jetzt benötigst Du eine weitere Variable, für den "vorherigen" Wert und
weist nicht wie das gehen soll?
Gratulation. Mir scheint das ist ein typischer Fall von Copy & Past, auf
der Wissensbasis: Keine Ahnung.
Danke für die Leute, die mir Tipps gegeben haben.
UND an den anderen, die nur Scheiße Schreiben, sag ich einfach mal: Kein
Mensch auf dieser Erde ist als Super Programmierer geboren.
Ich würde gerne wissen wie es bei euch war am Anfang???
Mansche Leute sind wirklich bedaurlich.
Bonapart schrieb:> Ich würde gerne wissen wie es bei euch war am Anfang???
wir hatten kein Internet und habe einfach dinge selber versucht. Damit
gab es auch viele Fehler aber selbst das hat zum wissen beigetragen.
Durch zu schnelles Fragen/googlen verlernt man doch das eigene
experimentieren.
Bonapart schrieb:> UND an den anderen, die nur Scheiße Schreiben...Bonapart schrieb:> Mansche Leute sind wirklich bedaurlich.
Sag mal, wenn du schon zwei Variablen (Temp1, Temp2) verwendest, sind
die doch auch nicht vom Himmel gefallen. Wenn dir jetzt gesagt wird, daß
du noch eine weitere Variable brauchst (lastTemp1), kannst du die doch
genauso anlegen wie die anderen beiden.
Da muß man doch nicht andere dermaßen unflätig beschimpfen!
Erwin D. schrieb:> Bonapart schrieb:>> UND an den anderen, die nur Scheiße Schreiben...>> Bonapart schrieb:>> Mansche Leute sind wirklich bedaurlich.>> Sag mal, wenn du schon zwei Variablen (Temp1, Temp2) verwendest, sind> die doch auch nicht vom Himmel gefallen. Wenn dir jetzt gesagt wird, daß> du noch eine weitere Variable brauchst (lastTemp1), kannst du die doch> genauso anlegen wie die anderen beiden.> Da muß man doch nicht andere dermaßen unflätig beschimpfen!
Ich beschimpfe nur die, das verdient haben. Bei den anderen habe ich
mich bedankt.
Bonapart schrieb:> Ich würde gerne wissen wie es bei euch war am Anfang???
Wir haben nachgedacht. Damals gab es nämlich kein Internet - da musste
man den eigenen Kopf benutzen statt das Denken auf andere Köpfe zu
verlagern.
Hättest du eine fertige Lösung mit der Hilfsvariable lastTemp1
hingeschrieben und dann gefragt, ob es in C nicht eine Möglichkeit gibt,
eine Veränderung ohne Zwischenspeicherung zu erkennen, dann wäre das
kein Problem gewesen.
So muss man aber wirklich davon ausgehen, dass du fürs programmieren
nicht die richtige Verschaltung im Kopf hast.... denn das ich eine
Variable für die Zwischenspeicherung anlegen muss, wäre/ist mir schon
nach meinen ersten Zeilen à la
10 Print "Hello world"
20 Goto 10
von alleine eingefallen :-)
Bonapart schrieb:> Ja so wird gehen, aber das LastTemp1 habe ich nicht
Bub, wenn du wissen willst ob sich etwas über die Zeit verändert hat
("Temp1 kleiner wird"), dann musst du mindestens 2 zeitlich
unterschiedliche Zustände kennen und diese vergleichen. Das sollte doch
klar sein.
Also merk dir den vorherigen Zustand und fertig. Was soll das Gejammer?
>> Ich beschimpfe nur die, das verdient haben.
Das ist jedoch sowohl unnötig wie unanständig!
> Bei den anderen habe ich> mich bedankt.
Da bleibt noch die Frage offen, wie denn mit solchen umzugehen ist, die
sich beim rumfragen so anstellen wie Du?
(der Eröffnungspost geht gerade noch so, dein Beitrag von 11:20 ist aber
ein Affront )
Mein Anfang, als Teenie damals in den 80ern? Mehr lesen vor dem
Probieren und noch mehr Probieren... (war kaum Jemand -kompetentes- da
zum fragen...)
Und arg schwitzen beim Nachdenken! X-D
eProfi schrieb:> Vor lauter Wald übersehen wir die Bäume:> Es ist wenig sinnvoll, in beiden Fällen Temp2++ zu schreiben.
Ganz gut!
Netiquette einhalten ist wieder mal wichtiger als Inhalt ;-)
eProfi schrieb:> or lauter Wald übersehen wir die Bäume:> Es ist wenig sinnvoll, in beiden Fällen Temp2++ zu schreiben.
Doch hatte ich direkt gesehen, aber ich ging da noch von einem
Beispielcodestück (à la 'lorem ipsum') aus und dass dann dort eigentlich
ersetzt werden würde. Mittlerweile bin ich mir da aber nach
'aber das LastTemp1 habe ich nicht
bin ich mir da nicht mehr so sicher....
@Bonapart: Wie gesagt, lass das besser mit dem Programmieren. Es ist
jetzt schon zu erkennen, dass du daran keine Freude haben wirst. Mal
lieber ein Bild, lerne Sprachen oder schnitze eine Blockflöte oder mach
was auch immer dir mehr liegt.
Es gibt hunderte von Büchern die sich mit der Einführung in das
Programmieren beschäftigen. Amazon bietet 558 davon an.
Warum liest heute keiner mehr ein Buch? Setzt sich in sein stilles
Kämmerlein und versucht ein paar Dinge?
Und wem Amazon zu teuer ist, kann immer noch die Stadtbücherei
versuchen.
> Warum liest heute keiner mehr ein Buch?
Heute suchen die Leute nur noch bei Youtube und Facebook. Manche leute
glauben wohl auch ganz feste daran, daß alles "ganz einfach" ist und man
sich die großartigen Sachen nicht mehr mühsam eventuell gar in mehreren
Jahren aneignen muss.
Mir tun die Musiker Leid, die kaum noch wissen, wovon sie leben sollen.
Aber die werden ja laut Heise auch bald durch Computer ersetzt. Dann
hören wir uns nur noch computergenerierte Aufzugmusik an. Schöne neue
Welt.
Ich bin schon wieder abgedriftet, sorry.
An Bonapart: Lass Dich nicht unterkriegen. Der Tonfall in diesem Forum
ist oft sehr grob. Wer geduldig ist, kann hier trotzdem eine Menge über
Elektronik und über Menschen lernen.
eProfi schrieb:> Vor lauter Wald übersehen wir die Bäume:> Es ist wenig sinnvoll, in beiden Fällen Temp2++ zu schreiben.
Dachte ich mir auch erst, aber wenn man nur die Anzahl der Änderungen
zählen will (die Summe der Änderungen steht hinterher ja in Temp1), wäre
es ok. Es weiss natürlich niemand, was Bonapart wirklich will.
Bonapart schrieb:> Ja so wird gehen, aber das LastTemp1 habe ich nicht
Tja, dann deklariere es halt: int lastTemp1=Temp1;
> @Bonapart: Wie gesagt, lass das besser mit dem Programmieren. Es ist> jetzt schon zu erkennen, dass du daran keine Freude haben wirst. Mal> lieber ein Bild, lerne Sprachen oder schnitze eine Blockflöte oder mach> was auch immer dir mehr liegt.
Nein, doch bitte nicht so drastisch.
Dranbleiben, mehr probieren, "besser" fragen, Hilfestellungen
beherzigen.
Das bedeutet nicht, dass bei Jedem der das Programmieren versucht, das
Programmieren auch gelingt. Bei einigen dauert es halt etwas länger...
Aber auch wenn der Dreh zum Programmieren nicht gefunden wird: das
erhöht den Respekt vor denen die es zustande bringen.
eProfi schrieb:> Vor lauter Wald übersehen wir die Bäume:> Es ist wenig sinnvoll, in beiden Fällen Temp2++ zu schreiben.
Würde ich nicht unbedingt so sehen - aus dem Eingangspost geht nicht
hervor, daß die Änderung von temp2 abhängig vom Vorzeichen der Änderung
von temp1 sein soll. Möglicherweise will der TO in temp2 ja nur die
absolute Anzahl der Änderungen von Temp1 zählen.
Ja nach verwendeter Hardware könnte man die Überprüfung auch mit
Boardmitteln machen, wobei du den eigentlich Code natürlich weiter in C
programmieren kannst. Das "Framework" liefert dir dann einen Callback
den du verwenden kannst.
Bonapart schrieb:> if (Temp1 kleiner wird)> {> Temp2++;> }>> else if (Temp1 größer wird)> {> Temp2++;> }
Tipp: Da in beiden Fallunterscheidungen jeweils dasselbe gemacht wird,
also wenn Temp1 kleiner als auch größer wird, kann man diese
Unterscheidung auf ein if-Statement reduzieren:
1
if (Temp1 sich verändert)
2
{
3
Temp2++;
4
}
Nichtsdestotrotz braucht man eine Hilfsvariable, welche sich den letzten
Zustand merkt:
1
staticintlast_Temp1;
2
3
if(Temp1!=last_Temp1)
4
{
5
Temp2++;
6
}
7
last_Temp1=Temp1;
Fertig. @TO: Das kannst Du so abtippen, sollte funktionieren - ohne
jetzt über das Verstehen dieses Codes diskutieren zu wollen.
Thomas E. schrieb:> Meinst Du, der TO kann mit diesen Begriffen etwas anfangen?
Das weiß ich nicht, aber wieso sollte ich ihm diese Information trotzdem
vorenthalten? Wenn er sich dafür interessiert und tiefer in die Materie
einsteigt, kann ihm diese Info nutzen. Wenn nicht kostet Sie ihn nur 10
Sekunden seines Lebens. Verschmerzbar.
Frank M. schrieb:> if (Temp1 != last_Temp1)> {> Temp2++;> }> last_Temp1 = Temp1;
Man sollte trotzdem noch die Fälle "Überlauf" und "Unterlauf" (wird wohl
nicht gebraucht!?) abfangen:
Mein Gott, was herrscht denn hier für ein Menschenbild vor? Ich kann
alles und alles andere sind Idioten? Leute, reißt euch mal zusammen! Ich
habe auch solch blöde Fragen gestellt, als ich vor 15 Jahren mit dem
Programmieren angefangen habe. Heute verdiene ich damit mein Geld …
Zu Deiner Frage: Üblicherweise löst man so etwas mit einem so genannten
Setter: Statt direkt temp1 zu inkrementieren (temp1++), bastelt man sich
eine Funktion, die einerseits temp1 beeinflusst, andererseits aber auch
temp2 entsprechend anpasst. Ein Beispiel:
1
inttemp1,temp2;
2
3
voidset_temp1(intnewValue){//Settermethode
4
temp1=newValue;//Temp 1 den neuen Wert zuweisen
5
temp2++;//Temp 2 automatisch mit erhöhen
6
}
7
8
//Um die Temperatur dann zu setzen bisher:
9
temp1=IRGEND_EIN_NEUER_WERT;
10
11
//Zukünftig dann:
12
set_temp1(IRGEND_EIN_NEUER_WERT);
Du kannst Du Setter-Methode auch dahingehend erweiter, dass etwas
unterschiedliches passiert, wenn der Wert Temp 1 kleiner oder größer
wird:
1
voidset_temp1(intnewValue){//Settermethode
2
if(newValue>temp1)//Wenn die neue Temperatur größer ist
3
temp2++;//Temp 2 automatisch mit erhöhen
4
elseif(newValue<temp1)//Ansonsten wenn die neue Temperatur geringer ist
5
temp2--;//Temp 2 automatisch mit verringern
6
//Sind alter und neuer Wert gleich, dann passiert nichts!
André R. schrieb:> Üblicherweise löst man so etwas mit einem so genannten> Setter:
Setzt ein "Setter" wie der Name schon vermuten lässt nicht nur
irgendwelche Variablen per Funktion auf einen definierten Wert? Was du
meinst ist ein Modifier oder?
André R. schrieb:> Mein Gott, was herrscht denn hier für ein Menschenbild vor? Ich kann> alles und alles andere sind Idioten? Leute, reißt euch mal zusammen! Ich> habe auch solch blöde Fragen gestellt, als ich vor 15 Jahren mit dem> Programmieren angefangen habe. Heute verdiene ich damit mein Geld …
Quereinsteiger? Merkt man leider!
> Statt direkt temp1 zu inkrementieren (temp1++), bastelt man sich> eine Funktion, die einerseits temp1 beeinflusst, andererseits aber auch> temp2 entsprechend anpasst.
Eine solche Funktion kann man zwar machen, sie aber als "setter" zu
bezeichnen ist unschön.
1.) Ein Setter soll EINE Variable setzen und dabei bestimmte Invarianten
aufrechterhalten. Die Bezeichnung "set_temp1" suggeriert dass hier NUR
temp1 verändert wird. Dann aber hat sie auf einmal Seiteneffekte auf
temp2. Unschön und fehlerträchtig.
2.) Setter sollte man allgemein vermeiden, da sie doch wieder recht
direkt die internen Datenstrukturen offenlegen. Das sollte man ohne Not
nicht machen.
Darüber hinaus interpretierst du denke ich die Aufgabenstellung falsch.
Er will im Prinzip einen Thermostat haben. Und da reicht in der Tat die
Eingabe einer SOLL-Temperatur welche dann in einer Regelschleife mit der
IST Temperatur abgeglichen wird. Da braucht es keine Funktionen welche
temp1 und temp2 beim Aufruf setzen.
uint32_t clean_code; schrieb:> Ggfs. kann man noch TEMP_MAX und last_Temp1 ausrichten.
Deine Schreibweise macht den Code nur unnötig lang. Ich arbeite erst mit
Zeilenumbrüchen bei 3 Bedingung die zu prüfen sind.
Ingo L. schrieb:> Ich arbeite erst mit Zeilenumbrüchen bei 3 Bedingung die zu prüfen> sind.
Und wenn man einen größeren Monitor hat, dann erst ab 4 Bedingungen?
Ingo L. schrieb:> Deine Schreibweise macht den Code nur unnötig lang. Ich arbeite erst mit> Zeilenumbrüchen bei 3 Bedingung die zu prüfen sind.
Der Code wird dadurch vertikal in die Laenge gezogen. Unnoetig ist das
jedoch nicht, sondern sauber. Genauso kann man die Klammern weglassen,
sie machen den Code jedoch auch sauber.
Ingo L. schrieb:> Ich arbeite erst mit Zeilenumbrüchen bei 3 Bedingung die zu prüfen sind.
Ich arbeite mit Zeilenumbrüchen, wenn zuviele Bedingungen in einer Zeile
unlesbar werden. Das ist unabhängig von der Monitorgröße (also der Größe
des Editor-Fensters) und somit portabel.
Cyblord -. schrieb:> Quereinsteiger? Merkt man leider!
Überhaupt nicht. Schon als junger Bub dem Onkel fasziniert zugesehen,
dann diverse Bücher, anschließend technisches Gymnasium mit Fachrichtung
Informatik, Berufsausbildung als Anwendungsentwickler und seither viele
Jahre Praxis.
Falls sich der Quereinsteiger auf die Sprache C bezieht, dann allerdings
ja. Beruflich hauptsächlich .NET und Websprachen.
> Eine solche Funktion kann man zwar machen, sie aber als "setter" zu> bezeichnen ist unschön.
Ok, darauf lasse ich mich ein. Hauptberuflich würde ich das mithilfe
eines Propertys umsetzen. Aber über Nomenklatur lässt sich viel
streiten.
> 1.) Ein Setter soll EINE Variable setzen und dabei bestimmte Invarianten> aufrechterhalten. Die Bezeichnung "set_temp1" suggeriert dass hier NUR> temp1 verändert wird. Dann aber hat sie auf einmal Seiteneffekte auf> temp2. Unschön und fehlerträchtig.
Für mich hat sich das durchaus auch so gelesen, als solle Temp2 hier nur
als "Seiteneffekt" verändert werden.
> 2.) Setter sollte man allgemein vermeiden, da sie doch wieder recht> direkt die internen Datenstrukturen offenlegen. Das sollte man ohne Not> nicht machen.
Geschmackssache. Da sagt jede Guideline etwas anderes.
> Darüber hinaus interpretierst du denke ich die Aufgabenstellung falsch.
Ich habe überhaupt nicht interpretiert. Oben steht doch ganz genau
beschrieben, was er haben möchte:
> Ich habe eine Variable Temp1 sie verändert sich mit der Zeit entweder vorwärts
oder rückwärts. Durch diese Variable will eine andere (Temp2)steueren.
>> Wie kann ich abfragen ob die erste Variable kleiner oder größe wird ?? (in C)
Ob da dann am Ende ein Thermostat daraus werden soll, oder was auch
immer, sei erst einmal dahin gestellt.
André R. schrieb:> Ok, darauf lasse ich mich ein. Hauptberuflich würde ich das mithilfe> eines Propertys umsetzen.
In C?
> Aber über Nomenklatur lässt sich viel> streiten.
Naja aber über eine korrekte Benamung von Funktionen nicht. Funktionen
sollen klar benannt sein und eine klare Aufgabe haben. Der Name ist
irreführend so.
> Für mich hat sich das durchaus auch so gelesen, als solle Temp2 hier nur> als "Seiteneffekt" verändert werden.
Unerwartete Seiteneffekte sollte man immer vermeiden, das hat nichts mit
der Aufgabe zu tun.
> Geschmackssache. Da sagt jede Guideline etwas anderes.
Welche Guidelines? Und dann gleich jede? Au weia.
Es geht hier um Abstraktion. Wenn man alle Variablen als getter/setter
rausführt hat man nichts gewonnen und nur ein Prinzip ohne Sinn und
Verstand verwendet.
Interne Daten verstecken und sinnvolle Interface definieren. Das wirst
du sicher auch in deinen "Guidelines" nachlesen können.
Cyblord -. schrieb:> André R. schrieb:>> Ok, darauf lasse ich mich ein. Hauptberuflich würde ich das mithilfe>> eines Propertys umsetzen.> In C?
C# oder VB.NET. Darfst Dir eines aussuchen. Wie gesagt, in C bin ich
Quereinsteiger; daher kann ich mich auch nur auf die Sprachen berufen,
die ich tatsächlich gelernt habe und versuchen, die dortigen
Sprachkonzepte zu adaptieren.
>> Aber über Nomenklatur lässt sich viel>> streiten.>> Naja aber über eine korrekte Benamung von Funktionen nicht. Funktionen> sollen klar benannt sein und eine klare Aufgabe haben. Der Name ist> irreführend so.
D'accord.
> Interne Daten verstecken und sinnvolle Interface definieren.
Das ist grundsätzlich auch immer sinnvoll! Ob das jetzt bei einem
100-Zeilen-Projekt für einen µC wirklich die hohe Schule ist, sei aber
mal dahin gestellt.
> Das wirst du sicher auch in deinen "Guidelines" nachlesen können.
Du scheinst ja schon ne Weile im Geschäft zu sein. „gewachsene
Strukturen“ kennst Du dann sicher. Dass man damit ein „jeder macht, was
er will“ zu vertuschen versucht, lernt man irgendwann später.
André R. schrieb:> Das ist grundsätzlich auch immer sinnvoll! Ob das jetzt bei einem> 100-Zeilen-Projekt für einen µC wirklich die hohe Schule ist, sei aber> mal dahin gestellt.
Da wir nur einen Codefetzen haben lässt sich zum konkreten "Projekt"
sowieso nichts sagen.
Aber genau das sage ich ja: Nur weil man bestimmte Konzepte kennt und
oft einsetzt, müssen die nicht immer sinnvoll sein.
Gute Interfaces braucht man aber auf Mikrocontrollern genauso wie
überall.
Bonapart schrieb:> Danke für die Leute, die mir Tipps gegeben haben.> UND an den anderen, die nur Scheiße Schreiben, sag ich einfach mal: Kein> Mensch auf dieser Erde ist als Super Programmierer geboren.> Ich würde gerne wissen wie es bei euch war am Anfang???>> Mansche Leute sind wirklich bedaurlich.
Ähemm...
Also, niemand wird als Programmierer geboren. Aber am Anfang von ALLEM
steht das Erlernen des logischen Denkens - und das fehlt bei dir noch.
Genau DAS ist das Bedauerliche - vorerst.
mein Rat:
Bevor du auch nur die allererste Zeile in irgend einer
Programmiersprache irgendwo hineintippst, solltest du dir das nötige
Rüstzeug erlernen. Und das ist in diesem Fall erstmal das gründliche
Überdenken dessen, was du eigentlich zu erreichen gedenkst. Versuche,
dein Problem zu analysieren und dann gedanklich eine Lösung dafür zu
konstruieren. Das betrifft hier eben auch, den Zeit- und
Amplitudenrahmen zu bedenken, also ob man mit einer Hysterese arbeiten
muß und in welchen Abständen oder zu welchen Gelegenheiten dein
vergleich stattfinden soll.
Wenn dir bereits so etwas ein Problem macht:
Bonapart schrieb:> aber das LastTemp1 habe ich nicht
dann hast du noch derart VIEL vor dem allerersten Programmierversuch
zu lernen, daß deine Bemerkung "anderen, die nur Scheiße Schreiben" sehr
deplaziert ist.
W.S.
André R. schrieb:> int temp1, temp2;
Mal ne Frage an die Profis (und etwas offtopic).
temp1 und temp2 würde ich als temporäre Variablen sehen
Ist es nicht sinnvoller
X4U schrieb:> Ist es nicht sinnvollerint iIstTemperatur, iSollTemperatur> zu schreiben?
ich finde es schlechter lesbar. Bei mir kommt jede Variabel auf eine
extra Zeile. Da kann man bei Bedarf noch einen passenden Kommentar
dahinter schreiben.
X4U schrieb:> André R. schrieb:>> int temp1, temp2;>> Mal ne Frage an die Profis (und etwas offtopic).>> temp1 und temp2 würde ich als temporäre Variablen sehen>> Ist es nicht sinnvollerint iIstTemperatur, iSollTemperatur> zu schreiben?
Das kommt immer drauf an. Bei Variablen, die oft benutzt werden, stimmt
das schon. Variablen, die man nur in wenigen hintereinanderliegenden
Zeilen braucht, habe ich auch schon temp genannt.
Damit ist klar, dass das keine Variable ist, die irgendwoanders
irgendwas macht, sondern eben nur an dieser Stelle.
Du weißt ja nicht, was mit den Temperaturwerten noch gemacht werden
soll.
X4U schrieb:> André R. schrieb:>> int temp1, temp2;>> Mal ne Frage an die Profis (und etwas offtopic).>> temp1 und temp2 würde ich als temporäre Variablen sehen>> Ist es nicht sinnvoller>
1
>intiIstTemperatur,iSollTemperatur
2
>
> zu schreiben?
Ist umständlicher beim Schreiben und beim Lesen. Temporär sind fast alle
Variablen in einer Funktion. Zur Unterscheidung von temporären (lokalen)
und globalen Variablen schreib ich die lokalen mit kleinen
Anfangsbuchstaben und die globalen mit großen.
X4U schrieb:> Ist es nicht sinnvoller> int iIstTemperatur, iSollTemperatur> zu schreiben?
Man kann die Variablen auch "intIstDieGeradeAktuelleTemperatur" und
"intIstMeineGewuenschteZielTemperatur" nennen, oder man kürzt einfach
auf "ist" und "soll" ab. Die Datentypen im Namen zu codieren finde ich
doof.
S. R. schrieb:> X4U schrieb:>> Ist es nicht sinnvoller>> int iIstTemperatur, iSollTemperatur>> zu schreiben?>> Man kann die Variablen auch "intIstDieGeradeAktuelleTemperatur" und> "intIstMeineGewuenschteZielTemperatur" nennen, oder man kürzt einfach> auf "ist" und "soll" ab. Die Datentypen im Namen zu codieren finde ich> doof.
Korrekt!
Die Datentypen sieht man sofort in jeder modernen IDE wenn man kurz über
die Variable fährt. Das reicht. Gut lesbare Variablennamen die SINNVOLL
sind
verwenden. Dann brauchts auch keine Kommentare hinter jeder Variablen.
> ich finde es schlechter lesbar. Bei mir kommt jede Variabel auf eine> extra Zeile. Da kann man bei Bedarf noch einen passenden Kommentar> dahinter schreiben.
Ja Peter super,
S. R. schrieb:> oder man kürzt einfach auf "ist" und "soll" ab.
Das ist dann ein wenig zu kurz. Was soll denn ist und soll bedeuten? Da
fehlt der Zusammenhang.
Ich wäre eher für currentTemperature und setTemperature
S. R. schrieb:> Die Datentypen im Namen zu codieren finde ich doof.
Jupp, macht man nicht mehr. Find ich auch doof.
nicht"Gast" schrieb:>> oder man kürzt einfach auf "ist" und "soll" ab.> Das ist dann ein wenig zu kurz. Was soll denn ist und soll bedeuten? Da> fehlt der Zusammenhang.
In einer Funktion "temp_regler" ist der Zusammenhang da.
Selbst in einer Funktion "regler" in der Datei "temp.c" ist der
Zusammenhang da.
Hängt natürlich vom Rest des Programms ab. Eine gute Strukturierung
setze ich einfach mal voraus.
nicht"Gast" schrieb:>> oder man kürzt einfach auf "ist" und "soll" ab.>> Das ist dann ein wenig zu kurz. Was soll denn ist und soll bedeuten? Da> fehlt der Zusammenhang.
In einer Funktion Regler ist es sogar sinnvoller als 'istTemperatur' und
'sollTemperatur'. Schließlich soll sie wiederverwendbar sein und es gibt
noch andere Dinge zu regeln außer Temperatur.
Häää? Kann es sein, dass hier mit temp1 und temp2 gar keine
Temperaturen, sondern temporäre Variablen gemeint sind?
Das Wort Temperatur hat zuerst
Autor: André R. (andr_r619) Datum: 17.08.2017 13:17
im 27. Beitrag (!) ins Spiel gebracht.
Die Abkürzung "temp" ist (zu) zweideutig. Sie kann einerseits
"Temperatur" bedeuten, andererseits "temporär".
Das Hirn des Lesers muss bei "temp" daher zu viel Kontext verarbeiten.
Das ist schlecht.
Jobst Q. schrieb:> Ist umständlicher beim Schreiben und beim Lesen. Temporär sind fast alle> Variablen in einer Funktion.
Das stimmt. Variablen, die in einer Funktion definiert werden, sind auch
nur innerhalb der Funktion gültig. Bei größeren Funktionen kann es sogar
ratsam sein, mehrere Scopes zu verwenden. Man kann nämlich einfach
innerhalb einer Funktion einen Bereich in geschweifte Klammern
einschließen und darin deklarierte Variablen sind dann nur innerhalb
dieses Bereichs gültig.
> Zur Unterscheidung von temporären (lokalen)> und globalen Variablen schreib ich die lokalen mit kleinen> Anfangsbuchstaben und die globalen mit großen.
Kann man so machen. Da ich aus der objektorientierten Welt kommt, ist
mir die Großschreibung aber eher für Klassennamen geläufig. Ich halte
das meistens so, dass ich vor den Namen lokaler Variablen einen _ setze
und Konstanten in Majuskeln schreibe.
_privateVariable
KONSTANTE
normaleVariable
Dabei unterscheide ich aber nicht, ob global oder lokal.
X4U schrieb:
> Die Datentypen im Namen zu codieren finde ich doof.
Das hat man früher tatsächlich so gemacht und auch empfohlen. In Zeiten
der modernen IDEs mit IntelliSense und Co. bläht das allerdings nur den
Text auf, verringert die Lesbarkeit und verwirrt unter Umständen sogar.
Ich verwende solche Präfixe eigentlich nur bei komplexen Typen, wie
beispielsweise Steuerelementen in GUIs. Textboxen nenne ich also
meistens txtMeinEingabefeld, Buttons btnMachWas usw.
S. R. schrieb:
>> ich finde es schlechter lesbar. Bei mir kommt jede Variabel auf eine>> extra Zeile. Da kann man bei Bedarf noch einen passenden Kommentar>> dahinter schreiben.>>Ja Peter super,>int a; //IST Temperatur>int b; //SOLL Temperatur.>>SO schreibt man gut lesbare Programme.... nicht
Das stimmt allerdings. Ich bin durchaus auch der Meinung, dass man
thematisch zusammenhängende Variablen gerne auch in eine Zeile schreiben
kann und ggf. auch soll. Beispiel:
1
inttempMin=3,tempMax=30;
Manche compiler erlauben heutzutage auch Inline-Dokumentationen. Damit
kann man die Variablen dann näher beschrieben und die IDE zeigt die
Texte dann auch an entsprechende Stelle an. In C# geht das
beispielsweise mit drei Schrägstrichen:
eProfi schrieb:> Häää? Kann es sein, dass hier mit temp1 und temp2 gar keine> Temperaturen, sondern temporäre Variablen gemeint sind?
Und die globalen Variablen dann glob1, glob2,...
Das wäre mit die dümmste Möglichkeit, wie man Variablen benennen kann.
Sogar a,b,c,d ... wäre da sinnvoller.
Michael B. schrieb:> if (Temp1 < lastTemp1)> {> Temp2++;> }> else if (Temp1 > lastTemp1)> {> Temp2++;> }> lastTemp1=Temp1;
warum dieses denn?
Bedingung ist doch
Jobst Q. schrieb:> Das wäre mit die dümmste Möglichkeit, wie man Variablen benennen kann.> Sogar a,b,c,d ... wäre da sinnvoller.
Geht noch viel bescheuerter! Ich habe mal einen Vorschlag gelesen, der
Programme wirksam vor Disassemblierung schützen solle. Da wurde allen
Ernstes vorgeschlagen, man solle für die Variablennamen eine
willkürliche Reihung an Sonderzeichen, griechischen, kyrillischen,
chinesischen und japanischen Schriftzeichen verwenden. Dadurch wäre die
Entschlüsselung des Programms nahezu unmöglich.
Hi
André R. schrieb:> Dadurch wäre die> Entschlüsselung des Programms nahezu unmöglich.
Hmm, musst halt nur dem Dis-Assembler sagen, daß Er die Variablen
nicht, wie üblich, nur durchzählt sofern dort überhaupt was Anderes
außer Register zusammen kommt.
... wäre mir neu, daß ein egal wie gearteter Variablen-Name auch nur
ansatzweise im µC landet ... außer vll. als Display-Text :)
Und gerade dort will man ja verstanden werden - wieder Nix mit den
ganzen schönen Zeichen, Die Keiner auf der Tastatur zusammen bekommt :)
MfG
PS: Erinnert etwas an 'Brainfuck'
https://de.wikipedia.org/wiki/Brainfuck
André R. schrieb:> Ich habe mal einen Vorschlag gelesen, der> Programme wirksam vor Disassemblierung schützen solle. Da wurde allen> Ernstes vorgeschlagen, man solle für die Variablennamen eine> willkürliche Reihung an Sonderzeichen, griechischen, kyrillischen,> chinesischen und japanischen Schriftzeichen verwenden. Dadurch wäre die> Entschlüsselung des Programms nahezu unmöglich.
Wie soll das vor Disassemblierung schützen? Diese betrifft die
ausführbare Binärdatei, nicht den Quelltext.
Außerdem sind Variablennamen in fast jeder Sprache auf Buchstaben,das
Sonderzeichen _ und Ziffern beschränkt,wobei das erste Zeichen keine
Ziffer sein darf. Nur Forth ist da etwas freizügiger.
Erstmal vielen Dank für die vielen Antworten, bin kein C Profi und daher
schreibe ich alles aus. Taste mich aber zur Zeit auch an Styleguides ran
und lerne dazu.
André R. schrieb:> In Zeiten> der modernen IDEs mit IntelliSense und Co. bläht das allerdings nur den> Text auf, verringert die Lesbarkeit und verwirrt unter Umständen sogar.
Bei mir als Gelegenheitsprogger hat es aber schon viel gebracht
Wenn ich z.B.
gucSerialBuffer = iDuDooferInteger;
schreibe sehe ich sofort was falsch läuft.
Für mich ist das auch super lesbar. Aber wahrscheinlich weil ich noch
sehr lange brauche um ein paar Zeilen Code zu bauen. FreeRTOS macht das
aber ähnlich und das wirkt auf mich sehr professionell.
(guc = global unsigned char)
X4U schrieb:> gucSerialBuffer = iDuDooferInteger;>> schreibe sehe ich sofort was falsch läuft.
Die Praefixe tragen redunante Informationen, die irrelevant sind. Falls
gucSerialBuffer ein Pointer ist (waere da nicht gpucSerialBuffer
besser?), gibt der Compiler eine Warnung a la assignment makes pointer
from integer without a cast. Falls gucSerialBuffer ein Array ist (waere
da nicht gaucSerialBuffer besser?), gibt der Comiler ein Error a la
assignment to expression with array type.
D.h. der Compiler weisst auf solche Fehler hin und demjenigen, der den
Code verstehen muss, wird das Lesen durch die redunaten Praefixe
erschwert, sie werden zu 99.9% ignoriert, gefiltert, sind unnoetig,
sogar kontraproduktiv.
uint32_t clean_code; schrieb:> Code verstehen muss, wird das Lesen durch die redunaten Praefixe> erschwert, sie werden zu 99.9% ignoriert, gefiltert, sind unnoetig,> sogar kontraproduktiv.
Mumpitz, selbsterklärende identiefiers sind essentiell für lesbaren
Code, vermeidbare Redundanzen sind da nebensächlich und zwangsläufig
wenn mit Kopien von Pointern arbeiten muss.
Bitwurschtler schrieb:> Mumpitz, selbsterklärende identiefiers sind essentiell für lesbaren> Code
nein, spätestens bei C++ macht es überhaupt kein sinn mehr den type im
namen zu codieren.
Und wenn man aus einen int ein Long macht fängt man an alle Variablen
umzubenennen?
Peter II schrieb:> Bitwurschtler schrieb:>> Mumpitz, selbsterklärende identiefiers sind essentiell für lesbaren>> Code>> nein, spätestens bei C++ macht es überhaupt kein sinn mehr den type im> namen zu codieren.>> Und wenn man aus einen int ein Long macht fängt man an alle Variablen> umzubenennen?
Völlig korrekt. Am Ende passen dann Name und Typ bei min. 50% aller
Variablen nicht mehr zusammen. Das Problem haben eben alle redundanten
Informationen und darum sind diese grundsätzlich zu vermeiden.
Bitwurschtler schrieb:> Mumpitz, selbsterklärende identiefiers sind essentiell für lesbaren> Code
Fast richtig. Selbsterklaerende Funktions- und Variablennamen sind
essentiell fuer lesbaren Code.
X4U schrieb:> Wenn ich z.B.>> gucSerialBuffer = iDuDooferInteger;>> schreibe sehe ich sofort was falsch läuft.
Das solltest du auch sehen, wenn du "SerialBuffer = DuInteger"
schreibst, ist einfach eine Übungssache. Präfixe scheitern bei
komplexeren Datentypen (structs), und sie versagen komplett, wenn sich
die Typen ändern (siehe WinAPI). Sie sind halt überholt.
Normalerweise willst du deine Funktionen kurz halten (unter einer
Bildschirmseite, also maximal etwa 50 Zeilen). Dann hast du auch genug
Überblick, um die verwendeten Variablen und deren Typen im Kopf zu
behalten.
Globale Variablen sollte man ohnehin vermeiden, und dann hat man es auch
nur mit wenigen datei-lokalen Variablen zu tun.
S. R. schrieb:> Das solltest du auch sehen, wenn du "SerialBuffer = DuInteger"> schreibst,
Fällt mir noch schwer, vor allem wenn das noch ein paar Monaten wieder
anfasse.
> ist einfach eine Übungssache.
Na hoffentlich.
> Präfixe scheitern bei> komplexeren Datentypen (structs),
Das verstehe ich jetzt nicht. Zur Zeit mach ich da z.B. ein
stStructname.cMember
draus . Wenn darauf dann ein pointer zeigt nennt der sich halt
pstStructname.cMember.
Das finde ich übersichtlich und klar. Tippen muss man das ja nur einmal
Die "autocompletion" der IDE zeigt mir dann auch alle structs an wenn
ich nur st tippe.
> und sie versagen komplett, wenn sich> die Typen ändern (siehe WinAPI). Sie sind halt überholt.
Ok soweit bin ich aber noch nicht..
> Globale Variablen sollte man ohnehin vermeiden, und dann hat man es auch> nur mit wenigen datei-lokalen Variablen zu tun.
Das war jetzt ein Praxisbeispiel wo es ohne nicht funzt. Dieser
gcSerialBuffer wird von einem Interrupt gefüttert und ohne global hängt
sich das ganze auf.
uint32_t clean_code; schrieb:> Die Praefixe tragen redundante Informationen, die irrelevant sind.
Schon klar, der Typ ist ja inhärent. Mir fällt es aber (noch) leichter
dass zu lesen. Manchmal druck ich auch Teile aus und da ist es dann die
einzge Möglichkeit den Typ zu erkennen.
> Falls> gucSerialBuffer ein Pointer ist (waere da nicht gpucSerialBuffer> besser?),
War jetzt kein pointer, den würde ich dann pgucSerialBuffer nennen da er
ja auf gucSerialBuffer zeigt.
SerialBuffer heißt der übrigens weil der Datenstrom von Serial -> Buffer
geht (andersherum würde ich ihn BufferSerial nennen). Zum Thema deutlich
machen das ein Teil aus Hardware besteht ist mir aber noch nicht
eingefallen.
Das mag aus der Sicht eines Profis jetzt völlig übertrieben sein, aber
ich lerne ja noch und halt am besten wenn ich mit dem Thema herumspiele.
> gibt der Compiler eine Warnung a la assignment makes pointer> from integer without a cast.
Auch klar, nur sehe ich das dann halt schneller
> Falls gucSerialBuffer ein Array ist (waere> da nicht gaucSerialBuffer besser?),
Zur Zeit bin ich der Meinung das die Struktur nicht im Namen auftauchen
sollte (ausser bei struct). Das macht das ganze sonst zu unleserlich (im
Bezug zu C lernen für Dummies was ja das Ggeenteil von "how to write a
marslander with a single line of code" ist ;-) ).
> gibt der Comiler ein Error a la> assignment to expression with array type.
Auch klar s.o.
>> D.h. der Compiler weisst auf solche Fehler hin und demjenigen, der den> Code verstehen muss, wird das Lesen durch die redunaten Praefixe> erschwert, sie werden zu 99.9% ignoriert, gefiltert, sind unnoetig,> sogar kontraproduktiv.
Das verstehe ich jetzt nicht. Also ich bin nicht in der Lage die Typen
von all den Variablen im Kopf zu behalten. Mit den Typangaben wird doch
aus der Fehlermeldung klar um was es geht. Sonst müsste ich erst einmal
in der Zeile nachlesen und "mouseovern" was da los ist.
X4U schrieb:> Manchmal druck ich auch Teile aus und da ist es dann die> einzge Möglichkeit den Typ zu erkennen.
Bei ausgedrucktem Code kann man die bereits von Andre erwaehnten
Vorzuege einer modernen IDE nicht nutzen. Da hilft solch eine Notation
natuerlich. Aber Sonderfaelle sollten nicht den Coding Style
beeinflussen.
X4U schrieb:> SerialBuffer heißt der übrigens weil der Datenstrom von Serial -> Buffer> geht (andersherum würde ich ihn BufferSerial nennen).
Das ist eine missverstaendliche Nomenklatur. Die Verwendung von
gaengigen Worten wie Output und Input ist da deutlich aussagekraeftiger.
X4U schrieb:> Zur Zeit bin ich der Meinung das die Struktur nicht im Namen auftauchen> sollte (ausser bei struct). Das macht das ganze sonst zu unleserlich
Entlarvt! Ein a macht das ganze unleserlich, st und pguc gehen aber
noch?
X4U schrieb:> Sonst müsste ich erst einmal> in der Zeile nachlesen und "mouseovern" was da los ist.
Richtig. Du verzichtest auf diese unnoetige ungarische Notation. Wenn du
dann einen Fehler machst, guckst du was los ist und korrigierst ihn. Im
Mittel sparst du auch noch Zeit, weil du keine seltsamen Praefixe
schreiben und lesen musst.
uint32_t clean_code; schrieb:> Man sollte die Verundung doch sauberer schreiben:> if ( (Temp1 != last_Temp1) &&> (Temp2 < TEMP_MAX) )> {> Temp2++;> }>> Ggfs. kann man noch TEMP_MAX und last_Temp1 ausrichten.
dann aber bitte den operator an den Anfang der Zeile, damit man nicht
erst nach dem Modus der Verknüpfung suchen muss.
1
if((Temp1!=last_Temp1)
2
&&(Temp2<TEMP_MAX))
3
{
4
Temp2++;
5
}
hat sich in der Mathematik schließlich auch bewährt. Da würde auch
keiner auf die Idee kommen, die Operatoren ans Zeilenende zu schreiben.
Bonapart schrieb:> Danke für die Leute, die mir Tipps gegeben haben.> UND an den anderen, die nur Scheiße Schreiben, sag ich einfach mal: Kein> Mensch auf dieser Erde ist als Super Programmierer geboren.> Ich würde gerne wissen wie es bei euch war am Anfang???>> Mansche Leute sind wirklich bedaurlich.
Na ja, das Forum ist rau, aber so wirst du sicher wenig Hilfe bekommen.
Ganz ehrlich, ich habe im Anfang das auch nicht so richtig verstanden
gehabt, bis mir das (wodurch weiß ich nicht mehr) verdeutlicht wurde,
dass bei jedem Durchlauf eben diese einzelnen Schritte abgearbeitet
werden und wenn du dann deine Variable nicht zwischenspeicherst, ist die
halt weg und dein aktueller Wert steht dann dafür.
Aber darüber hinaus, ich finde es auch nicht schön, wenn neue Leute
gleich so einen Wind bekommen und man sie so lächerlich da stehen lässt.
Oft sind sie vielleicht sehr jung oder aber haben in anderen Bereichen
ein Wissen, was das eines manchen Programmierers hier, bei weitem
übertreffen kann.
Immer schön nett zueinander sein.
... und denkt dran, ich bin bewaffnet. ;-) (nur Spaß, für die, die das
so nicht kapieren)
S. R. schrieb:> Globale Variablen sollte man ohnehin vermeiden, und dann hat man es auch> nur mit wenigen datei-lokalen Variablen zu tun.
Bei Eigenschaften, die das ganze Programm betreffen, ist es unsinnig,
sie nicht global zu deklarieren. Und sie womöglich noch mit ellenlangen
Parameterlisten von einer Funktion zur nächsten schaufeln.
Wo beides möglich ist, sind Lösungen mit globalen Variablen oft besser,
wenn damit auf Parameterübergaben verzichtet werden kann. Besonders bei
zeitkritischen Funktionen ist das von Bedeutung.
uint32_t clean_code = 0; schrieb:> Das ist eine missverstaendliche Nomenklatur. Die Verwendung von> gaengigen Worten wie Output und Input ist da deutlich aussagekraeftiger.
Woher soll ich dann wissen woher der Input kam?
Da wäre der Gerätename UART1_Buffer klarer? Ist sowas üblich?
X4U schrieb:>> ist einfach eine Übungssache.> Na hoffentlich.
Dazu gehört aber auch, es zu üben. Wer ständig mit Navi fährt, übt den
Skill "Ortskenntnis" auch durch viel Fahren nicht.
>> Präfixe scheitern bei komplexeren Datentypen (structs),>> Das verstehe ich jetzt nicht. Zur Zeit mach ich da z.B. ein>> stStructname.cMember>> draus .
Das heißt, in deiner Notation sind alle Strukturen gleich. Damit ist
deine Notation sinnlos, denn du unterscheidest keine relevanten Typen
mehr.
Die Datentypen heißen "int", "unsigned char", "struct pid_regler",
"struct wetter" und so weiter.
Mit steigendem Abstraktionsgrad arbeitest du fast ausschließlich mit
structs (oder, wenn objektorientiert, mit Klassen), und die bildest du
nichtmal ab. Primitive Datentypen werden zunehmend weniger wichtig.
>> und sie versagen komplett, wenn sich>> die Typen ändern (siehe WinAPI). Sie sind halt überholt.>> Ok soweit bin ich aber noch nicht..
Du weißt aber schon jetzt, dass dir dein Konzept irgendwann mal tierisch
auf die Füße fallen wird. Wenn ein Brückenbauer so rangeht, wird er mal
kräftig Schadenersatz leisten müssen...
>> Globale Variablen sollte man ohnehin vermeiden, und dann hat man es auch>> nur mit wenigen datei-lokalen Variablen zu tun.>> Das war jetzt ein Praxisbeispiel wo es ohne nicht funzt.
Trotzdem muss die Variable nicht applikations-global sein. Datei-lokal
(außerhalb einer Funktion static deklarieren) reicht völlig aus, und
viele solche Variablen wirst du nicht brauchen.
uint32_t clean_code = 0; schrieb:> X4U schrieb:>> SerialBuffer heißt der übrigens weil der Datenstrom von Serial -> Buffer>> geht (andersherum würde ich ihn BufferSerial nennen).>> Das ist eine missverstaendliche Nomenklatur. Die Verwendung von> gaengigen Worten wie Output und Input ist da deutlich aussagekraeftiger.
Ich nutze für sowas "rx" oder "tx" im Namen. Dann ist klar, ob es um den
Sende- oder Empfangspuffer geht.
1
staticvolatileuint8_tuart_txbuf[TXBUF_SIZE];
2
staticvolatileuint8_tuart_tx_rp=0,uart_tx_wp=0;
3
staticvolatileuint8_tuart_rxbuf[RXBUF_SIZE];
4
staticvolatileuint8_tuart_rx_rp=0,uart_rx_wp=0;
Und wenn meine Puffer mal größer als 128 Bytes werden dürfen (oder ich
nicht auf einem AVR bin), dann ändere ich einfach den Datentypen und
muss nichts umbenennen.
Jobst Q. schrieb:>> Globale Variablen sollte man ohnehin vermeiden, und dann hat man es auch>> nur mit wenigen datei-lokalen Variablen zu tun.>> Bei Eigenschaften, die das ganze Programm betreffen, ist es unsinnig,> sie nicht global zu deklarieren. Und sie womöglich noch mit ellenlangen> Parameterlisten von einer Funktion zur nächsten schaufeln.
Es gibt meist nur extrem wenige Eigenschaften, die das gesamte Programm
betreffen. Und statt hunderte globaler Variablen zu benutzen, sammelt
man soetwas dann lieber in einer einzigen globalen Struktur und übergibt
einen Pointer auf diese (oder auf einen Teil davon).
In der Regel ist das, was du beschreibst, aber ein Designfehler: Du
brichst mit der Modularisierung. Eine Funktion sollte genau das wissen,
was sie für ihre Arbeit braucht, und möglichst nicht mehr.
> Wo beides möglich ist, sind Lösungen mit globalen Variablen oft besser,> wenn damit auf Parameterübergaben verzichtet werden kann. Besonders bei> zeitkritischen Funktionen ist das von Bedeutung.
(Programm-)Globale Variablen sind immer möglich, und sie sind *fast
immer* ein Fehler. Es mag Ausnahmen geben, aber die sind selten und
sollten sehr gut begründet werden können.
Performanter Code ist im Allgemeinen weniger wichtig als lesbarer Code.
Ausnahmen bestätigen die Regel.
S. R. schrieb:> Dazu gehört aber auch, es zu üben.
mach ich, versprochen ;-).
Danke für die vielen Tipps, wenn ich das alles kapiert und routine habe
werde ich bestimmt vieles weglassen und auf bewährte Verfahren
zurückgreifen. Die sind aber am Anfang schwer zu durchdringen. Was für
jemanden dem das "in Fleisch und Blut" übergegangen vielleicht etwas
blöde aussieht sind für mich gute Hilfen.
uint32_t clean_code = 0; schrieb:> Bei ausgedrucktem Code kann man die bereits von Andre erwaehnten> Vorzuege einer modernen IDE nicht nutzen.
Äh, ja.
Bei Progrämmchen, die sich ncoh sinnvoll ausdrucken lassen, braucht man
das aber eh nicht.
Oliver
S. R. schrieb:> a, trotzdem nimmt man Kindern möglichst früh die Stützräder weg,
Nach meiner persönlichen Erfahrung baut das Kind Sie sofort ab wenn das
Radfahren sitzt da die dann Anfangen zu nerven. Ist aber schon etwas her
;-).
Damals hatte man auf einem alten Damenrad, mit Heuwagenbremse, stehend
angefangen, weil nur der Kopf so eben über den Sattel ragte.
Gefühlte 100000 Mal auf die Fresse geflogen und dann gab es ein Rad, das
man so eben fahren konnte (also schon mal zwei Nummer, aus heutiger
Sicht, zu hoch).
S. R. schrieb:
Jobst Q. schrieb:
>> Bei Eigenschaften, die das ganze Programm betreffen, ist es unsinnig,>> sie nicht global zu deklarieren. Und sie womöglich noch mit ellenlangen>> Parameterlisten von einer Funktion zur nächsten schaufeln.>> Es gibt meist nur extrem wenige Eigenschaften, die das gesamte Programm> betreffen. Und statt hunderte globaler Variablen zu benutzen, sammelt> man soetwas dann lieber in einer einzigen globalen Struktur und übergibt> einen Pointer auf diese (oder auf einen Teil davon).
Meine Programme haben auch keine hunderte globale Variablen, aber in
einen struct gehören nur Variablen, die zusammengehören, als Sammlung
beliebiger sind sie unsinnig.
>> In der Regel ist das, was du beschreibst, aber ein Designfehler: Du> brichst mit der Modularisierung. Eine Funktion sollte genau das wissen,> was sie für ihre Arbeit braucht, und möglichst nicht mehr.
Mehr bekommt sie auch nicht. Dass jede Funktion theoretisch auf jede
globale Variable zugreifen könnte, schadet ja nichts, solange sie es
nicht tut.
Nach meiner Erfahrung ist die praktische Designregel der Sparsamkeit bei
den Parametern viel wichtiger, als die ideologische Vermeidung von
globalen Variablen.
>>> Wo beides möglich ist, sind Lösungen mit globalen Variablen oft besser,>> wenn damit auf Parameterübergaben verzichtet werden kann. Besonders bei>> zeitkritischen Funktionen ist das von Bedeutung.>> (Programm-)Globale Variablen sind immer möglich, und sie sind *fast> immer* ein Fehler. Es mag Ausnahmen geben, aber die sind selten und> sollten sehr gut begründet werden können.>> Performanter Code ist im Allgemeinen weniger wichtig als lesbarer Code.> Ausnahmen bestätigen die Regel.
Solche (all)gemeinen Programme kenn ich auch, die trotz schneller
Prozessoren und SSD für bestimmte Aufgaben noch mehrere Minuten
brauchen.
Globale bzw statische Variablen sind kaum schlechter lesbar als lokale.
Lange Parameterlisten beeinträchtigen die Lesbarkeit viel mehr.
Neben der Geschwindigkeit ist auch die geringere Stackbelastung bei
globalen Variablen ein Vorteil bei rekursiven Funktionen wie zB
Quicksort.
Daten, die während des ganzen Sortiervorgangs gleichbleiben, wie der
Zeiger auf die Vergleichsfunktion, brauchen nicht als Parameter
übergeben werden, wenn sie global/statisch deklariert werden.
Jobst Q. schrieb:> Globale bzw statische Variablen sind kaum schlechter lesbar als lokale.> Lange Parameterlisten beeinträchtigen die Lesbarkeit viel mehr.
Statische Variablen zähle ich nicht als global, weil ich mich auf die
Sichtbarkeit beziehe, nicht auf die Lebensdauer. Wenn du sowas meinst,
stimme ich dir zu.
Ansonsten sind globale Variablen ein Maintenance-Problem und man muss
abwägen, ob man bereit ist, die Kosten zu zahlen.
Jobst Q. schrieb:> Solche (all)gemeinen Programme kenn ich auch, die trotz schneller> Prozessoren und SSD für bestimmte Aufgaben noch mehrere Minuten> brauchen.
Die passen aber so ganz schlecht in den typischen Mikrocontroller... und
ich bin mir dann auch noch sicher, dass "globalen Variablen vermeiden"
nicht für die mangelhafte Geschwindigkeit verantwortlich ist.