Forum: PC-Programmierung C-Programmierung - Vergleich


von Bonapart (Gast)


Lesenswert?

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

: Verschoben durch Moderator
von Michael B. (laberkopp)


Lesenswert?

if (Temp1 < lastTemp1)
{
  Temp2++;
}
else if (Temp1 > lastTemp1)
{
  Temp2++;
}
lastTemp1=Temp1;

von Bonapart (Gast)


Lesenswert?

Ja so wird gehen, aber das LastTemp1 habe ich nicht

von Günther (Gast)


Lesenswert?

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.

von Anders Wortig (Gast)


Lesenswert?

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"...

von Sebastian S. (amateur)


Lesenswert?

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.

: Bearbeitet durch User
von Bonapart (Gast)


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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.

von Erwin D. (Gast)


Lesenswert?

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!

von Bonapart (Gast)


Lesenswert?

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.

von Günther (Gast)


Lesenswert?

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 :-)

von Cyblord -. (cyblord)


Lesenswert?

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?

von eProfi (Gast)


Lesenswert?

Vor lauter Wald übersehen wir die Bäume:
Es ist wenig sinnvoll, in beiden Fällen Temp2++ zu schreiben.

von Anders Wortig (Gast)


Lesenswert?

>
> 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

von Anders Wortig (Gast)


Lesenswert?

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 ;-)

von Günther (Gast)


Lesenswert?

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.

von PittyJ (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

> 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.

von Michael B. (laberkopp)


Lesenswert?

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;

von Anders Wortig (Gast)


Lesenswert?

> @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.

von Thomas E. (picalic)


Lesenswert?

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.

von J. F. (Firma: Père Lachaise) (rect)


Lesenswert?

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.

von Thomas E. (picalic)


Lesenswert?

J. F. schrieb:
> Das "Framework" liefert dir dann einen Callback
> den du verwenden kannst.

Meinst Du, der TO kann mit diesen Begriffen etwas anfangen?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
static int last_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.

von J. F. (Firma: Père Lachaise) (rect)


Lesenswert?

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.

von Ingo L. (corrtexx)


Lesenswert?

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:
1
 if ( Temp1 != last_Temp1 && Temp2 < TEMP_MAX ){
2
     Temp2++;
3
 }

: Bearbeitet durch User
von André R. (andr_r619)


Lesenswert?

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
int temp1, temp2;
2
3
void set_temp1(int newValue) { //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
void set_temp1(int newValue) { //Settermethode
2
  if(newValue > temp1) //Wenn die neue Temperatur größer ist
3
    temp2++; //Temp 2 automatisch mit erhöhen
4
  else if(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!
7
8
  //Und erst ganz am Schluss!:
9
  temp1 = newValue; //Temp 1 den neuen Wert zuweisen
10
}

von Ingo L. (corrtexx)


Lesenswert?

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?

von uint32_t clean_code; (Gast)


Lesenswert?

Ingo L. schrieb:
> if ( Temp1 != last_Temp1 && Temp < TEMP_MAX )
>  {
>      Temp2++;
>  }

Man sollte die Verundung doch sauberer schreiben:
1
if ( (Temp1 != last_Temp1) &&
2
     (Temp2 < TEMP_MAX) )
3
{
4
   Temp2++;
5
}

Ggfs. kann man noch TEMP_MAX und last_Temp1 ausrichten.

von Cyblord -. (cyblord)


Lesenswert?

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.

: Bearbeitet durch User
von Ingo L. (corrtexx)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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?

von uint32_t clean_code; (Gast)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von André R. (andr_r619)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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.

von Eric B. (beric)


Lesenswert?

Und jetzt mal ohne lastTemp  :-P
1
int temp1, temp2;
2
3
void update_temp1(int newvalue)
4
{
5
  if (temp1 != newvalue)
6
  {
7
    temp1 = newvalue;
8
    if (temp2 < MAXINT)
9
    {
10
      temp2++;
11
    }
12
  }
13
}

von André R. (andr_r619)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von X4U (Gast)


Lesenswert?

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
int iIstTemperatur, iSollTemperatur
zu schreiben?

von Peter II (Gast)


Lesenswert?

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.

von Dussel (Gast)


Lesenswert?

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.

von Jobst Q. (joquis)


Lesenswert?

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
> int iIstTemperatur, 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.

von S. R. (svenska)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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,
1
int a; //IST Temperatur
2
int b; //SOLL Temperatur.

SO schreibt man gut lesbare Programme.... nicht

: Bearbeitet durch User
von nicht"Gast" (Gast)


Lesenswert?

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.

von S. R. (svenska)


Lesenswert?

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.

von Jobst Q. (joquis)


Lesenswert?

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.

von eProfi (Gast)


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

Cyblord -. schrieb:
> SO schreibt man gut lesbare Programme.... nicht

ich habe solche kurzen Namen nicht verwendet.

von Grauhariger Programmierer (Gast)


Lesenswert?

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.

von André R. (andr_r619)


Lesenswert?

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
int tempMin = 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:
1
/// <summary>  
2
///  This class performs an important function.  
3
/// </summary>  
4
public class MyClass{}

von Jobst Q. (joquis)


Lesenswert?

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.

von Joachim B. (jar)


Lesenswert?

Michael B. schrieb:
> if (Temp1 < lastTemp1)
> {
>   Temp2++;
> }
> else if (Temp1 > lastTemp1)
> {
>   Temp2++;
> }
> lastTemp1=Temp1;

warum dieses denn?

Bedingung ist doch
1
if( (Temp1 < lastTemp1) || (Temp1 > lastTemp1) )
2
{  Temp2++;
3
   lastTemp1=Temp1;
4
}

es geht auch
1
if( Temp1 != lastTemp1 )
2
{  Temp2++;
3
   lastTemp1=Temp1;
4
}

von André R. (andr_r619)


Lesenswert?

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.

von Patrick J. (ho-bit-hun-ter)


Lesenswert?

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

: Bearbeitet durch User
von Jobst Q. (joquis)


Lesenswert?

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.

: Bearbeitet durch User
von X4U (Gast)


Lesenswert?

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)

von Oberlajtnant (Gast)


Lesenswert?

X4U schrieb:
> iDuDooferInteger

Endlich mal jemand mit Sinn für schöne Variablennamen!

von uint32_t clean_code; (Gast)


Lesenswert?

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.

von Bitwurschtler (Gast)


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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?

von Cyblord -. (cyblord)


Lesenswert?

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.

von uint32_t clean_code; (Gast)


Lesenswert?

Bitwurschtler schrieb:
> Mumpitz, selbsterklärende identiefiers sind essentiell für lesbaren
> Code

Fast richtig. Selbsterklaerende Funktions- und Variablennamen sind 
essentiell fuer lesbaren Code.

von S. R. (svenska)


Lesenswert?

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.

von X4U (Gast)


Lesenswert?

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.

von X4U (Gast)


Lesenswert?

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.

von uint32_t clean_code = 0; (Gast)


Lesenswert?

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.

von Vlad T. (vlad_tepesch)


Lesenswert?

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.

von F. F. (foldi)


Lesenswert?

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)

von Jobst Q. (joquis)


Lesenswert?

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.

von X4U (Gast)


Lesenswert?

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?

von S. R. (svenska)


Lesenswert?

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
static volatile uint8_t uart_txbuf[TXBUF_SIZE];
2
static volatile uint8_t uart_tx_rp = 0, uart_tx_wp = 0;
3
static volatile uint8_t uart_rxbuf[RXBUF_SIZE];
4
static volatile uint8_t uart_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.

von X4U (Gast)


Lesenswert?

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.

von S. R. (svenska)


Lesenswert?

Ja, trotzdem nimmt man Kindern möglichst früh die Stützräder weg, denn 
sonst fährt der Sohnemann auch noch mit 15 kein zweirädriges Fahrrad. 
;-)

von Oliver S. (oliverso)


Lesenswert?

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

von X4U (Gast)


Lesenswert?

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 
;-).

von F. F. (foldi)


Lesenswert?

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).

von Jobst Q. (joquis)


Lesenswert?

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.

von S. R. (svenska)


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.