Name für variable

[Schraubel (Gast)]

Hi Forum,
ich suche einen bezeichnenden Namen für
eine BitVariable die folgenes tut:
Alter Status (t-1) eines Eingangs merken zur Flankenerkennung.

[MaWin (Gast)]

laststate ?

[Automatisierer (Gast)]

Auf SPSen nennt sich das Flankenmerker.

[Nase (Gast)]

state und state0?

[Automatisierer (Gast)]

Nase schrieb:
> state und state0?

Oder HansDietrich?

[Schraubel (Gast)]

Automatisierer schrieb:
> Oder HansDietrich?

Früher nannte ich meine Variablen tatsächlich "flupp" oder "zisch".

[Mark B. (markbrandis)]

Schraubel schrieb:
> Hi Forum,
> ich suche einen bezeichnenden Namen für
> eine BitVariable die folgenes tut:
> Alter Status (t-1) eines Eingangs merken zur Flankenerkennung.

Also ein Vergangenheitswert. Im Englischen "past value".

Sinnvollerweise sollte in der Variablen ausgedrückt sein, wozu die Info 
gut ist die in ihr gespeichert wird. (z.B. Zugehörigkeit zu einer 
physikalischen Größe, oder einem Maschinenteil, ...)

Beispiele im Fall eines Schalters:

light_switch_past_value
proximitySwitch_pastValue
ToggleSwitchPastValue
PushButtonSwitch_PastValue

Natürlich dürfen die Variablennamen auch in deutscher Sprache verfast 
sein, wenn es im Rest des Codes ebenfalls so ist. Aber bitte nicht 
deutsch und englisch wild durcheinander mischen. Das ist krank ;-)

[Nichtimmerzustimmer (Gast)]

Hmm ... "past" hört sich in diesem Zusammenhang irgendwie komisch an. 
previousIrgendwas bzw. prevIrgendwas und, falls nötig (*), 
currentIrgendwas bzw. curIrgendwas (oder entsprechend mit Unterstrichen) 
findet man häufig, das ist doch praktisch so eine Art "Namens-Idiom". 
Drückt meiner Meinung hier auch besser aus, was gemeint ist.
Dass 'last' irreführend sein kann, habe ich selbst schon ab und zu 
bemerkt (ist es jetzt der aktuelle Status oder der davor?).

(*) Ich würde aber eher darauf verzichten, wenn es geht. Also nur den 
einfachen Variablennamen für den aktuellen Wert benutzen und bei der 
Variable, die den alten Wert enthält, etwas davor oder dahinter setzen.

[Dussel (Gast)]

Wert_alt, Status_alt, Zustand_alt oder auch Alter_Wert, AlterWert oder 
in welcher Kombination es einem auch immer passt.

[Thomas R. (dt_roll)]

Eine gute idee ist auch die Variablen in Dialekt zu benennen, Das 
erschwert ein Auslagern irgendwohin ab 50km Distanz. Wobei das erst im 
Nachhinein auffaellt.

[sepp (Gast)]

Thomas R. schrieb:
> Eine gute idee ist auch die Variablen in Dialekt zu benennen, Das
> erschwert ein Auslagern irgendwohin ab 50km Distanz. Wobei das erst im
> Nachhinein auffaellt.

oida_status

[Georg (Gast)]

Schraubel schrieb:
> ich suche einen bezeichnenden Namen für
> eine BitVariable

Wenn du bei jeder Variablen eine Volksbefragung startest, wirst du auch 
für das allerkleinste Projekt Jahre brauchen. Anders formuliert: krasses 
Beispiel von Unselbstständigkeit.

Georg

[Markus V. (valvestino)]

Georg schrieb:
> Wenn du bei jeder Variablen eine Volksbefragung startest, wirst du auch
> für das allerkleinste Projekt Jahre brauchen. Anders formuliert: krasses
> Beispiel von Unselbstständigkeit.

Mir sind Kollegen, die sich ernsthaft Gedanken machen über vernünftige 
Bezeichner und bei einer kleinen Blockade damit auch mal jemanden 
anderes fragen (Tellerrand!), 1000mal lieber als die, die irgend einen 
Sch*** hinschreiben.

Grüße
Markus

[Mark B. (markbrandis)]

Markus V. schrieb:
> Mir sind Kollegen, die sich ernsthaft Gedanken machen über vernünftige
> Bezeichner und bei einer kleinen Blockade damit auch mal jemanden
> anderes fragen (Tellerrand!), 1000mal lieber als die, die irgend einen
> Sch*** hinschreiben.

So isses.

[Der Andere (Gast)]

vorherig = previous

also z.B. "PrevState"

[Random .. (thorstendb)]

Ich benenne die meisst mit dem prefix "Prev" oder "Old":
xPrev, yOld

[Markus V. (valvestino)]

Random .. schrieb:
> Ich benenne die meisst mit dem prefix "Prev" oder "Old":
> xPrev, yOld

Wohl eher Suffix... ;-)

[Random .. (thorstendb)]

Markus V. schrieb:
> Random .. schrieb:
>> Ich benenne die meisst mit dem prefix "Prev" oder "Old":
>> xPrev, yOld
>
> Wohl eher Suffix... ;-)
genau :-)

[S.Siebenhaar (Gast)]

Über das "richtige" Benennen von Variablen, Konstanten, Funktionen und 
ähnlichem sind schon dutzende Doktorarbeiten geschrieben worden.
Ich fand das Ergebnis immer sch**.

Entweder (früher) knabberte man am Längenlimit für Bezeichner herum 
(heute glühen wohl eher die Fingerkuppen, oder das Resultat war schlicht 
und einfach unlesbar.
...aber bis zur zehnten Nachkommastelle nachvollziehbar.

[tictactoe (Gast)]

Mark B. schrieb:
> Aber bitte nicht
> deutsch und englisch wild durcheinander mischen.

Weil's so schön Spaß macht, hier noch mein Lieblingsfunktionsname:

GetNextesZeichen()

[Carl D. (jcw2)]

Ich hatte mal vor Jahrzehnten einen Kollegen, der sollte mir 
Programmieren beibringen (da tat ich das schon ca. 10 Jahre) und hat 
allen ernstes vorgeschlagen lokale Variablen Inn, mit nn=00..99, zu 
benennen, weil's viel übersichtlicher ist.
Dank Code-Auto-Completion wird man heute eher die Doku in den 
Variablenname verpacken.

[Vincent H. (vinci)]

static unsigned long int state[2] = {};

// blabla

state[1] = state[0];

[Markus V. (valvestino)]

Vincent H. schrieb:
> state[1] = state[0];

Das ist so ziemlich die schlechteste Lösung: Kein Mensch weiß, welche 
Semantik sich hinter 0 und 1 verbirgt.

[Frank M. (ukw) (Moderator)]

Markus V. schrieb:
> Vincent H. schrieb:
>> state[1] = state[0];
>
> Das ist so ziemlich die schlechteste Lösung: Kein Mensch weiß, welche
> Semantik sich hinter 0 und 1 verbirgt.

Um diesen Ansatz zu retten:

#define CURRENT_STATE  0
#define PREVIOUS_STATE 1

state[PREVIOUS_STATE] = state[CURRENT_STATE];

Ist auf jeden Fall skalierbar, z.B. mit:

#define NEXT_STATE     2

;-)

[Markus V. (valvestino)]

Frank M. schrieb:
> Um diesen Ansatz zu retten:#define CURRENT_STATE  0
> #define PREVIOUS_STATE 1
>
> state[PREVIOUS_STATE] = state[CURRENT_STATE];
>
> Ist auf jeden Fall skalierbar, z.B. mit:#define NEXT_STATE     2

Und was ist daran besser als currentState und previousState? Außer daß 
es mehr Code ist, der schwerer verständlich ist! ;-)

Grüße
Markus

[Dussel (Gast)]

Markus V. schrieb:
> Das ist so ziemlich die schlechteste Lösung: Kein Mensch weiß, welche
> Semantik sich hinter 0 und 1 verbirgt.
Das mache ich in VHDL zur Flankenerkennung immer so und hier sehe ich 
keinen Grund, warum das nicht gehen sollte. Man muss halt durch den 
Namen kennzeichnen, dass das eine Aufnahme der letzten n Zustände ist.

[Markus V. (valvestino)]

Dussel schrieb:
> Das mache ich in VHDL zur Flankenerkennung immer so und hier sehe ich
> keinen Grund, warum das nicht gehen sollte...

Niemand behauptet, dass das nicht geht. Und trotzdem ist es für Leser 
des Sourcecodes sehr schwer nachvollziehbar, was das passieren soll. 
Weshalb es per se schlecht ist.

Grüße
Markus

[Dussel (Gast)]

Markus V. schrieb:
> Und trotzdem ist es für Leser
> des Sourcecodes sehr schwer nachvollziehbar, was das passieren soll.
Das ist es eben nicht. Was willst du denn machen, wenn du mehrere alte 
Werte speichern willst? Variablen aktuell, alt, älter, noch_älter, 
noch_davor…
Wie berechnest du einen gleitenden Mittelwert über zig oder hunderte 
Werte, wenn ein Array als 'Schieberegister' so schwer verständlich ist?
Das Problem ist in allen Fällen das Gleiche: Man möchte vergangene Werte 
betrachten. Ob das jetzt 1024 oder 2 sind, ist für die Fragestellung 
kein Unterschied.

Lothar Miller macht es zum Beispiel auch so 
http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung

[Daniel A. (daniel-a)]

Dussel schrieb:
> Wie berechnest du einen gleitenden Mittelwert über zig oder hunderte
> Werte, wenn ein Array als 'Schieberegister' so schwer verständlich ist?

Man nimmt 1-(i+1)/n vom momentanen wert und adiert (i+1)/n vom neuen 
dazu. Das ist dein neuer Momentane wert.

[Markus V. (valvestino)]

Dussel schrieb:
> Das ist es eben nicht. Was willst du denn machen, wenn du mehrere alte
> Werte speichern willst? Variablen aktuell, alt, älter, noch_älter,
> noch_davor…
> Wie berechnest du einen gleitenden Mittelwert über zig oder hunderte
> Werte, wenn ein Array als 'Schieberegister' so schwer verständlich ist?
> Das Problem ist in allen Fällen das Gleiche: Man möchte vergangene Werte
> betrachten. Ob das jetzt 1024 oder 2 sind, ist für die Fragestellung
> kein Unterschied.

Das ist aber ein total anderer Usecase. Bei der ursprünglichen 
Fragestellung ging es (nur) um "current" und "previous". Wenn Du die 
Historie tatsächlich benötigst, ist ein Array / eine Liste natürlich 
richtig.

Grüße
Markus

[Mark B. (markbrandis)]

Dussel schrieb:
> Wie berechnest du einen gleitenden Mittelwert über zig oder hunderte
> Werte

Das ist etwas völlig anderes als eine Flanke zu erkennen.

[Vincent H. (vinci)]

Markus V. schrieb:
> Vincent H. schrieb:
>> state[1] = state[0];
>
> Das ist so ziemlich die schlechteste Lösung: Kein Mensch weiß, welche
> Semantik sich hinter 0 und 1 verbirgt.


Du hast wohl nicht viel mit Signalverarbeitung oder Regelungstechnik zu 
tun?
n(0), n(-1), n(-2)

Das sind ganz klassische Bezeichnungen für diskrete Zeiten.

C unterstützt halt leider keine negativen Indizes.

[Daniel A. (daniel-a)]

Vincent H. schrieb:
> C unterstützt halt leider keine negativen Indizes.

Und diese Info hast du von wo?

#include <stdio.h>

static int tmp_n[3] = {1,2,3};
int *n = tmp_n + sizeof(tmp_n)/sizeof(*tmp_n) - 1;

int main(){
  printf("%d %d %d\n",n[0],n[-1],n[-2]);
  return 0;
}

daniel@Daniels-Surface-Pro-3:~$ gcc -std=c99 -Wall -Werror -pedantic main.c -o main
daniel@Daniels-Surface-Pro-3:~$ ./main 
3 2 1

[Vincent H. (vinci)]

Ich meinte damit natürlich direkte Indizes, die 1:1 am Array wirken, 
keine Pointer-Arithmetik.

/edit

printf("%d", tmp_n[-1]); // quasi

[Markus V. (valvestino)]

Vincent H. schrieb:
> Du hast wohl nicht viel mit Signalverarbeitung oder Regelungstechnik zu
> tun?

Mit Signalverarbeitung oder Regelungstechnik nicht, dafür aber sehr viel 
mit Code Quality / Clean Code Development.

Vincent H. schrieb:
> n(0), n(-1), n(-2)
>
> Das sind ganz klassische Bezeichnungen für diskrete Zeiten.

Es ist aber nach wie vor ein anderer Use Case, wie der des TOs. Also 
vergleiche bitte nicht Äpfel mit Birnen. ;-)

Grüße
Markus

[Dussel (Gast)]

Markus V. schrieb:
> Es ist aber nach wie vor ein anderer Use Case, wie der des TOs.
Das ist es halt nicht. In den genannten Fällen braucht man Werte von 
mehreren Zeitpunkten, um daraus etwas abzuleiten. Ob man eine 
Flankenerkennung oder ein Ausgangssignal daraus ableitet, ist für die 
Speicherung der Werte egal. Auch egal ist prinzipiell erstmal, ob es 2 
oder 1000 Werte sind.

Mir geht es auch nicht um eine Diskussion, wie man es jetzt bei der 
Flankenerkennung machen sollte. Ich würde das Array nehmen, jemand 
anderes halt zwei einzelne Variablen. Oben wurde aber von Markus 
geschrieben, dass der Ansatz mit dem Array totaler Quatsch sei. Das ist 
eben nicht so, sondern gängige Praxis für solche Probleme.

[Markus V. (valvestino)]

Wenn ich nochmals in Erinnerung rufen dürfte: :-)
Markus V. schrieb:
> Vincent H. schrieb:
>> state[1] = state[0];
>
> Das ist so ziemlich die schlechteste Lösung: Kein Mensch weiß, welche
> Semantik sich hinter 0 und 1 verbirgt.

Bei der Frage des TOs ging es um genau ZWEI Zustände: Den aktuellen und 
den vorhergehenden. Dies mit einem Array zu implementieren, mit nichts 
sagenden Konstanten 0 und 1 zu implementieren ist die schlechteste 
Lösung. Dabei bleibe ich.

Wenn man für das Erkennen von irgendwelchen Zuständen mehr als zwei 
Werte benötigt, macht ein Array ja Sinn. Das streite ich doch garnicht 
ab.

Aber beim Use Case des TOs sind es halt nur zwei Zustände. Und deshalb 
gleich eine abstrakte Lösung mit n historischen Zuständen zu 
fabrizieren, die man wahrscheinlich niemals benötigt, ist Overkill. Man 
sollte immer folgendes, wichtiges Prinzip in der Softwareentwicklung 
beachten: So konkret wie möglich und so abstrakt wie nötig.

Grüße
Markus

[Mark B. (markbrandis)]

Dussel schrieb:
> dass der Ansatz mit dem Array totaler Quatsch sei. Das ist
> eben nicht so, sondern gängige Praxis für solche Probleme.

Arrays mit einer Größe von exakt zwei halte ich nicht für typisch und 
gängig. Aber ich kann mich natürlich auch irren. Wir können ja mal eine 
Code-Suchmaschine anwerfen und schauen, wie oft dieser Fall real 
vorkommt? :-)

[Eric B. (beric)]

Mark B. schrieb:
> Arrays mit einer Größe von exakt zwei halte ich nicht für typisch und
> gängig.

Sehr gängig für double buffering...

ImageStruct buffer[2];
int work = 0, display = 1;

void flip()
{
  work = display;
  display = 1 - display;
}

void renderLoop()
{
  while(1)
  {
    showImage(&buffer[display]);
    renderNewImage(&buffer[work]);
    flip();
  }
}

[Mark B. (markbrandis)]

Eric B. schrieb:
> Mark B. schrieb:
>> Arrays mit einer Größe von exakt zwei halte ich nicht für typisch und
>> gängig.
>
> Sehr gängig für double buffering...

Okay, dann genauer eingeschränkt:

Arrays mit einer Größe von exakt zwei zum Speichern von physikalischen 
Größen (z.B. Messwerte, die von einem Sensor erfasst werden) halte ich 
nicht für typisch und gängig.