- Beiträge
- 15.150
- Reaktionspunkte
- 3.631
-> Hier kostenlos registrieren
aber du kannst doch auch E0.0 eingeben - selbst wenn die Symbolik "Greifer_oben" ist ...
Software Resilienz im SPS-/Produktionsbereich
- Ersteller If-Schleife
- Erstellt am
-> Hier kostenlos registrieren
JSEngineering
Level-3
- Beiträge
- 2.260
- Reaktionspunkte
- 807
aber doch bitte ohne Punkt im Variablennamen... wegen solcher Angewohnheiten muß man bei TIA immer die nervigen "" haben... E0.0 kann man auch E0_0 schreiben, ist genauso lesbar...
- Beiträge
- 11.478
- Reaktionspunkte
- 4.014
-> Hier kostenlos registrieren
- Beiträge
- 11.478
- Reaktionspunkte
- 4.014
das wären dann eher so die ganz kleinen Sorgen, die ich so den Tag über habe
- Beiträge
- 11.478
- Reaktionspunkte
- 4.014
bringt mir aber nicht wirklich was. "Greifer_oben" steht halt rechts im Kommentar, wenn ichs wissen will...
-> Hier kostenlos registrieren
Ich hab das mal in einem Projekt gesehen (nicht von mir), da hat der Programmierer die Merker so benannt:
Wirklich kein Witz:
M5.0 -E5.0
M5.1 -E5.1
M5.2 -E5.2
M5.3 -E5.3
Im Code unterschied sich dann ein Merker und ein Eingang mit "E5.0" und E5.0.
Also ohne "".
DerTechpriester
Level-2
- Beiträge
- 687
- Reaktionspunkte
- 378
Mensch, da war ja ein Profi am Werk.
Mein schlimmstes Programm war ein Zuweisungs-Stil aber ganz ohne Variablennamen.
Das ganze Programm einer Anlage bestand aus:
Tag_1, Tag_2, Tag_3 etc.
- Beiträge
- 15.150
- Reaktionspunkte
- 3.631
vielleicht war das ja das Programm einer Zeitschaltuhr ?
Lipperlandstern
Level-3
- Beiträge
- 6.455
- Reaktionspunkte
- 1.997
-> Hier kostenlos registrieren
Ich finde das gut und arbeite nur so. Erstens bekomme ich den Eingang meist erst kurz vor der IB (wenn überhaupt) und dann kann es sein das er noch während der IB geändert wird. Unsere Elektriker sind da etwas speziellWo wir bei Werksnormen wären, wo der Kunde das komplette BMK im Variablennamen haben möchte, weil die Instandhalter ja nur so auch den Sensor/Aktor identifizieren können
. Das BMK ändert sich auf jeden Fall nicht.
DerTechpriester
Level-2
- Beiträge
- 687
- Reaktionspunkte
- 378
Bestimmt. Es zählt die Tage bis zur eigenen Verschrottung.
Also ich verwende das BMK in meinen Programmen auch. Nur als Kommentar, nicht als Variablenname. (Eigentlich ein Fehler, immerhin fängt unser BMK mit der Baugruppennummer an.Ich finde das gut und arbeite nur so. Erstens bekomme ich den Eingang meist erst kurz vor der IB (wenn überhaupt) und dann kann es sein das er noch während der IB geändert wird. Unsere Elektriker sind da etwas speziell
)
- Beiträge
- 11.478
- Reaktionspunkte
- 4.014
Warum TIA das so benennt, wird mir auch ewig ein Rätsel bleiben...
DerTechpriester
Level-2
- Beiträge
- 687
- Reaktionspunkte
- 378
-> Hier kostenlos registrieren
Weil Englisch sich besser anhört. Auf Deutsch wäre es ja: Etikett_1, Etikett_2, Etikett_3
- Beiträge
- 11.478
- Reaktionspunkte
- 4.014
Es könnte aber auch wenn man M0.0 eintippt die Variable erstmal "M0.0" nennen... oder soWeil Englisch sich besser anhört. Auf Deutsch wäre es ja: Etikett_1, Etikett_2, Etikett_3
- Beiträge
- 11.478
- Reaktionspunkte
- 4.014
Wie hat er denn den M5.0 gebildet? Könnte mir vorstellen, da mussten mal schnell nachträglich alle Eingänge verzögert werden oder sowas? Und dann einfach in der Software überall E5.0 gegen M5.0 umschreiben...
Aber wer weiss das schon. Aber irgendwie macht das auch keinen Sinn...
-> Hier kostenlos registrieren
Das weiß ich nicht mehr genau... ist schon eine Weile her...
Der M5.0 hatte schon irgendwas mit dem E5.0 zu tun, aber wie du sagst, gab trotzdem keinen Sinn.
Hab die Symbolik damals geändert...
- Beiträge
- 11.478
- Reaktionspunkte
- 4.014
Oder halt auf "Symbolik hat Vorrang" geschaltet und in der Variablentabelle den "E5.0" von E5.0 nach M5.0 umgemappt und übersetzt oder sowas... war das ne 300er oder 1500er
Aber auch egal. Hatte sicherlich nen Hintergrund.
Gerhard Bäurle
Schreibender Ingenieur
- Beiträge
- 7.142
- Reaktionspunkte
- 2.664
Das Buzzword außerhalb der Automatisierung für dieses Thema ist übrigens "Clean Code" ...
-> Hier kostenlos registrieren
Nun ja aber es gib halt auch effezienten Code die wenige verstehe... Oder nicht auf die Idee gekommen sind? Wie geht man damit um? Viel kommentieren oder als, ist doch logisch wie das funktioniert abstempeln? Gerade bei der Bitschubserei ist sie Trickkiste ja prall gefüllt.
Code:
float Q_rsqrt( float number )
{
long i;
float x2, y;
const float threehalfs = 1.5F;
x2 = number * 0.5F;
y = number;
i = * ( long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - ( i >> 1 ); // what the fuck?
y = * ( float * ) &i;
y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
// y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration,
// this can be removed
return y;
}
Mrtain
Level-3
- Beiträge
- 1.361
- Reaktionspunkte
- 822
Das Buch dazu ist übrigens echt gut ud lesenswert (also das original von Robert C Martin)
OP
If-Schleife
Level-2
- Beiträge
- 102
- Reaktionspunkte
- 16
Ich habe mal was zusammen geschrieben:
- Robuste Fehlerbehandlung:
- Implementiere effektive Fehlerbehandlung, um unerwartete Probleme abzufangen und angemessen zu reagieren.
- Protokolliere Fehlermeldungen für spätere Diagnose und Behebung.
- Klare Struktur und Lesbarkeit:
- Verwende aussagekräftige Bezeichner für Variablen, Funktionen und Klassen.
- Halte den Code gut strukturiert und formatiert, um die Lesbarkeit zu erleichtern.
- Kommentiere komplexen Code, um anderen Entwicklern das Verständnis zu erleichtern.
- Vermeidung von Redundanz:
- Vermeide doppelten Code (Redundanz), um Wartbarkeit und Änderbarkeit zu verbessern.
- Nutze Funktionen und Klassen, um Code logisch zu organisieren und zu wiederverwenden.
- Effiziente Ressourcennutzung:
- Achte darauf, Ressourcen wie Speicher und CPU effizient zu nutzen.
- Schließe Ressourcen, wenn sie nicht mehr benötigt werden, um Lecks zu vermeiden.
- Gute Dokumentation:
- Dokumentiere den Code klar und konsistent, um anderen Entwicklern die Arbeit zu erleichtern.
- Beschreibe Schnittstellen, Funktionen und wichtige Entscheidungen.
- Einhalten von Coding Standards:
- Befolge die geltenden Coding Standards für die verwendete Programmiersprache.
- Konsistenz in der Formatierung und im Stil fördert die Lesbarkeit und Wartbarkeit.
- Tests und Testautomatisierung:
- Schreibe umfassende Tests, um sicherzustellen, dass der Code korrekt funktioniert.
- Automatisiere Tests, um eine konsistente Überprüfung bei Codeänderungen sicherzustellen.
- Versionierung und Backups:
- Verwende ein Versionskontrollsystem wie Git, um den Code zu verfolgen und zu sichern.
- Erstelle regelmäßig Backups, um Datenverlust zu verhindern.
- Performanceoptimierung:
- Identifiziere und behebe Engpässe in der Performance, um eine reibungslose Ausführung sicherzustellen.
- Sicherheit:
- Berücksichtige Sicherheitsaspekte und verhindere potenzielle Schwachstellen.
- Validiere Benutzereingaben.
