Variablen sinnvoll benennen?

TP-Inc

Level-3
Beiträge
1.109
Reaktionspunkte
249
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi, ich arbeite aktuell an einem Projekt mit einem Keyence XG-X bei dem ich etliche Variablen im Controller benötige. Manche sind Parameter, manche sind Ergebnisse, Zwischenwerte, Hilfsvariablen, Variablen die nicht angefasst werden dürfen weil sie für Grundfunktion mit der SPS verwendet werden usw.
Es gibt im VisionEditor keine Möglichkeit diese Variablen zu strukturieren oder zu kommentieren. Das wird relativ schnell unübersichtlich.
Gibts eine Art Richtlinie oder Ähnliches wie man da am besten vorgeht? Im SPS-Programm gibts unser eigener Standard vor, der halt auf kommentierten Strukturen beruht.
 
Eine Möglichkeit ist hier eine Art der Namenskonventionen, also z.B. n für INTs, f für Floats, a für Array , c für Constans usw.
-> Dies ergibt natürlich dann auch Kombinationen für z.B. ein Array of REAL wäre dies af<Name>

Die dir dazu z.B. mal das von Beckhoff im Infoysy an,.. dort hat es Vorschläge für FBs, Variablen, usw.

Dabei zu empfhelen ist längere Texte mit allgemien Abkürzugnen und CamelCase zu benennen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hier mal ein Auszug von möglichen Benamungen bei meinen letzten Auftraggeber:
x = BOOL
b = BYTE
w = WORD
i = INT
u = unsigned
s = short
usi = unsigned short Int
r = REAL
s = String
c = Char
p = Pointer
pb = POINTER TO BYTE
a = ARRAY
ab = ARRAY OF BYTE
ST_ = Struktur
st = Instanz von Struktur
EN_ = ENUM
en = Instanz von ENEM
FB_ = Funkrionsbaustein
fb = Instanz von FB
I_ = Eingang
I_x = Boolescher Eingang
Q_ = Ausgang
Q_b = Byte Ausgang

Bei einem Kunden wurde die Anzahl der Bits mit angegeben
i8 = Integer mit 8 Bits (SINT)
ui16 = Unsigned Integer mit 16 Bits (UINT)
 
Hi, ich arbeite aktuell an einem Projekt mit einem Keyence XG-X bei dem ich etliche Variablen im Controller benötige. Manche sind Parameter, manche sind Ergebnisse, Zwischenwerte, Hilfsvariablen, Variablen die nicht angefasst werden dürfen weil sie für Grundfunktion mit der SPS verwendet werden usw.

Statt den Typen, wie mein Vorredner erwähnt, würde ich dann markante funktionale Abkürzungen selbst wählen.

para_ rslt_ zw_ h_ SPS_ jeweils als Vorsatz zum Bleistift.

Die Typenangaben halte ich selten für zielführend, weil es eigentlich Compilersache ist. Aber man kann die natürlich auch anhängen, wenns dem Verständnis dient.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Inzwischen hab ich die Kommentarspalte in der Keyence-Software auch gefunden. War nur ganz rechts, und man muss hinscrollen…
Hab mich trotzdem dazu entschieden die Variablen mit einer Abkürzung der Verwendung zu beginnen. SYS, PRM, ERG usw. Den Datentypen finde ich eigentlich eher uninteressant (Gibt auch nicht viele in der Umgebung)
 
Dabei zu empfhelen ist längere Texte mit allgemien Abkürzugnen und CamelCase zu benennen.
Prinzipiell immer eine gute Idee da man keine sinnlosen Leerzeichen uder Unterstriche mehr hat und damit mehr
Text fürs wesentliche was die Programme verständlicher macht.

Ich Persönlich nutze PascalCase im gegensatz zu camelCase Wobei der Einzige Unterschied der allererste
Buchstabe ist (alles andere ist gleich).
PascalCase = Allererster Buchstabe Groß sowie alle Erstbustaben eines Teilbegriffes groß alles andre klein.
camelCase = Allererster Buchstabe klein sowie alle Erstbustaben eines Teilbegriffes groß alles andre klein.

Gruß

A.
 
Die ganze abkurzerei finde ich schrecklich. Wenn du aber nur 24 Zeichen hast wie bei S7 Classic musst du.
Ja, Abkürzungen sind nicht immer schön (vielleicht sogar schrecklich). Aber ich versuche trotzdem die Variablen- und Strukturnamen kurz zu halten. Sonst kann der Code auch schnell unleserlich(er) werden.

DB.Motor.Status.Fehler // kann man lesen
Datenbaustein.Motorstruktur.Statuswort.Fehler // kann man zwar auch lesen, wenn aber logische Verknüpfungen hinzukommen, braucht man mehrere Bildschirme, um die Variablen darzustellen.
 
Zurück
Oben