# SCL/ST: Blockkommentar vs Zeilenkommentar



## Perfektionist (23 Januar 2013)

was nehmt Ihr? Ich als AWL-Geschädigter würde ja Zeilenkommentar spontan vorziehen, aber ist das der "gute" SCL/ST-Stil?

Entschuldigung mal gleich vorab, wenn ich hier eine absolute Geschmacksfrage gestellt haben sollte und seit gewiss, dass ich die Frage nicht stelle, um anschließend jemanden bekehren zu wollen - ich fang mit SCL gerade erst an


----------



## Blockmove (23 Januar 2013)

Beides 

Zeilenkommentare habe ich z.B. hinter End_IF. Das erleichert bei geschachtelten Abfragen die Übersicht erheblich

Blockkommentare helfen - mir zumindest - auch zum Gliedern des Ablauf


```
// **********
// @x Wichtig
// **********

// **************************
// @x.y Nicht ganz so wichtig
// **************************

// @x.y.z Weniger wichtig
// ----------------------

// Kommentar
```

Die "@x" kannst du recht komfortabel suchen

Wichtig ist halt, dass man sich vorher ein System überlegt.
Bei mittelmäßig komplexen SCL-Bausteinen fange ich oft erst mit den Kommentaren an und schreibe dann den Code.

Gruß
Dieter


----------



## MasterOhh (23 Januar 2013)

Ich beschreibe eigentlich immer nur was der nachfolgende Quellcode bewirken soll. Das reicht von 2-3 Wörtern bis hin zu mehreren Zeilen Text.
Einzelne Programmzeilen kommentiere ich aber nicht. Dafür achte ich drauf, dass meine Variablennamen so gewählt sind das man selbst beim lesen des Codes die Funktion recht schnell heraus bekommt.

Wenn Bausteine zu komplex werden um sie im Quelltext ausreichend zu beschreiben, erstelle ich eine detailiertere Zusatzdoku.

Aber die Anlagen die ich programmiere sind rein für den Eigengebrauch bei uns in der Firma. Deshalb bin auch ich für die Instandhaltung und Erweiterung (steuerungstechnisch) verantwortlich. Meine Dokus / Kommentare sind also nur für mein Zukunfts Ich gedacht und keinem 3ten....


----------



## Blockmove (23 Januar 2013)

MasterOhh schrieb:


> Aber die Anlagen die ich programmiere sind rein für den Eigengebrauch bei uns in der Firma. Deshalb bin auch ich für die Instandhaltung und Erweiterung (steuerungstechnisch) verantwortlich. Meine Dokus / Kommentare sind also nur für mein Zukunfts Ich gedacht und keinem 3ten....



Dann wollen wir alle mal für dich beten und hoffen, dass deine Anlagen vor dir das Zeitliche segnen.
Programme gehören grundsätzlich so geschrieben, dass ein anderer sie verstehen kann. Punkt, Ende, Aus!

Ein Problem mit der Zusatzdoku ist, dass sie halt irgendwann mal so nach 10Jahren unauffindbar ist.
Deshalb soviel wie möglich in den Code. Besonders wenn es komplexe Berechnungen sind.

Gruß
Dieter


----------



## Larry Laffer (23 Januar 2013)

Hallo,
im Prinzip sehe ich es so ähnlich wie Dieter.
Bevor ich ein Script schreibe erstelle ich mir erstmal die Block-Überschriften. Allerdings habe ich keine Such-Indexe - ist aber vielleicht noch mal eine Idee ...
Direkte Zeilenkommentare habe ich eher selten - es aber aber manchmal Sequenzen, deren Sinn trotz Kopf-Beschreibung nicht gleich ersichtlich ist - und da gibt es dann ergänzende Zeilenkommentare ... Ganze Romane habe ich allerdings nicht im Script ...

Gruß
Larry


----------



## Perfektionist (23 Januar 2013)

Blockmove schrieb:


> Dann wollen wir alle mal für dich beten und hoffen, dass deine Anlagen vor dir das Zeitliche segnen.
> Programme gehören grundsätzlich so geschrieben, dass ein anderer sie verstehen kann. Punkt, Ende, Aus!


Zwinkerer an Larry (er weiß, warum), auch wenns nun von meiner Seite her auch Spam ist.  ​neee, im Ernst, passt schon, bin auf weitere Schilderungen Eurer Arbeitsweisen gespannt. Die Idee mit dem @x hatte ich ähnlich auch schon, ich leite in AWL meine Hauptüberschriften mit // ***** ein, um mit der Suchfunktion durch meinen Code zu navigieren. Keine Ahnung, warum ich dies gegenüber Netzwerkaufteilung vorgezogen habe - fällt mir vielleicht aber wieder ein. Vielleicht lag es daran, dass ich Copy-Paste (welch verachtenswerte Vorgehen  ) auf diese Art und Weise praktikabler fand. Naja, habs halt schon immer (seit ich mich bei S7 im Jahr 2000 für AWL entschieden habe) immer so gemacht.

vielleicht eine interessante Offtopic-Zusatzfrage: Netzwerkunterteilung in SCL? Gibts das überhaupt? Würde es Sinn machen? Sorry, dass ich grad so ignorant bin, überhaupt zu wissen, ob SCL Netzwerke kennt. Leider sitz ich grad am falschen Rechner um das (auch unter TIA) nachprüfen zu können...


----------



## Blockmove (23 Januar 2013)

Netzwerke gibt es in SCL nicht.
Das ist auch einer der Gründe warum ich die @x.y.z verwende.
Für Variablen verwende ich in SCL die Ungarische_Notation.
Mit den vielen erforderlichen Casts / Typwandlungen kann einen der SCL-Compiler schon nerven (zumindest bei Classic). Deshalb ist es von Vorteil den Variablentyp im Namen mitzuführen.
Ist genauso wie das Rechnen mit Einheiten in der Physik

Gruß
Dieter


----------



## Thomas_v2.1 (23 Januar 2013)

Wenn der Code IEC kompatibel sein soll darf man nur Block-Kommentare mit (* ... *) verwenden. Die Zeilenkommentare kenne ich zumindest nur bei Siemens SCL.


----------



## Thomas_v2.1 (23 Januar 2013)

Blockmove schrieb:


> Für Variablen verwende ich in SCL die Ungarische_Notation.
> Mit den vielen erforderlichen Casts / Typwandlungen kann einen der SCL-Compiler schon nerven (zumindest bei Classic). Deshalb ist es von Vorteil den Variablentyp im Namen mitzuführen.



Die echte Apps Hungarian oder Systems Hungarian? ;-)
Ich finde dass man gerade durch die Typüberprüfung bei SCL auf das Mitführen des Typs im Namen verzichten kann, da man dadurch nicht wie in AWL z.B. einfach ein Integer Bitmuster auf eine Real-Variable schreiben kann.


----------



## Blockmove (23 Januar 2013)

Thomas_v2.1 schrieb:


> Die echte Apps Hungarian oder Systems Hungarian? ;-)
> Ich finde dass man gerade durch die Typüberprüfung bei SCL auf das Mitführen des Typs im Namen verzichten kann, da man dadurch nicht wie in AWL z.B. einfach ein Integer Bitmuster auf eine Real-Variable schreiben kann.



Weder die Echte- noch die Windows- sondern meine eigene ungarische Notation quasi mit schwäbischem Akzent 
Ich hab irgendwann mal eine Codesys-Einführung durchgelesen und dort wurde das Mitführen empfohlen ... Tja mir hats gefallen und drum mach ich es.

Gruß
Dieter


----------



## MasterOhh (23 Januar 2013)

Perfektionist schrieb:


> ....
> 
> vielleicht eine interessante Offtopic-Zusatzfrage: Netzwerkunterteilung in SCL? Gibts das überhaupt? Würde es Sinn machen? Sorry, dass ich grad so ignorant bin, überhaupt zu wissen, ob SCL Netzwerke kennt. Leider sitz ich grad am falschen Rechner um das (auch unter TIA) nachprüfen zu können...



In TwinCAT und Codesys gibt es dafür die Aktionen. Mit denen kann man sehr gut Ordnung in die FBs bringen. 

Was kann der SCL Editor im TIA eigentlich? Der von Step 7 war ja noch recht besch..eiden. Ich meine Sachen wie mit der Maus auf eine Variable zu zeigen und sofort deren Datentyp und Kommentar angezeigt zu bekommen oder die automatische Vervollständigung sind hilfreiche Features.


----------



## ge_org (23 Januar 2013)

Hallo,
kurz ein Wort von einem Instandhalter der seine Programmierer auf den "wirklichen Weg" zum Ziel führen will .
Wir haben das Problem, dass wir eher lange brauchen uns bei Fehlern in ein Programm einzulesen, vor allem auch deshalb weil wir bis vor ca. 2 Jahren keinen einheitlichen Standard für SPS hatten (von LOGO, FX1N, S7200, S7300....), diese Anlagen wurden allerdings übernommen (alles was Siemens oder Mitsubishi anbelangt muss ich ausbaden, weil von meinen 2 jüngeren Kollegen keiner AWL-KOP-FUP (oder Sienems und Mitsubishi) will, LOGO verwenden wir für Neuprojekte für kleine Handarbeitsstationen nicht mehr weil nach ca. 2 Jahren Betrieb Funktionalitäten verlangt werden die sie nicht oder nur mit unverhältmäßig hohen Aufwand erfüllt-->Tricksereien die keiner mehr nachvolziehen kann).
Zum eigentlichen Thema:
Wir versuchen derzeit, die einzelnen Prozesse (sprich FB, FC.. eigentlich die Anlage) in Visio darzustellen und 1:1 zu übersetzen. Vorteil sollte sein, Fehler oder Notwendigkeiten es besser/sauberer zu programmieren früher zu erkennnen um damit eine gewisse Nachvollziehbarkeit zu erreichen. Kommentare sollten damit egal sein, gilt aber eben nur dann, wenn sauber gearbeitet wird!
Als Beispiel verwendeten wir eine kleine Funktionalität in einer Anlage die mit ST programmiert wurde. Bei der Analyse sind wir auf etliche Sachen gestossen, die in der Originalversion nicht-oder unzulänglich-programmiert wurden-->aber trotzdem zu 99% funktioniert hat (aber eben 99%).

Aus meiner Sicht als Instandhalter:
Ein Programmiergerät brauche ich nicht, weil die Sondermaschine nicht abgenommen wird wenn bei einem Fehler keine Fehlermeldung kommt (ist aber auch nicht schlimm weil die bauen wir jetzt selber-->fehlende Fehlermeldung kostet 24 Dosen Bier-->enormer Lerneffekt).
Zum Programmiergerät musste ich bis jetzt erst 3 mal greifen (5 Jahre, 45 kleinere Anlagen-->extrem faule Sau-->Nein, aber ich kenne die Anlagen):
Fehlbedienung eines Siemens TP170 brachte die Schrittkette etwas durcheinander 
Niederdruckwetter brachte ein Schrittkette nicht weiter (Fehler war irgendwie gemein....)
Firmwareupdate wegen 314 (auch irgendwie gemein, weil lt. Siemens approx. nach 500Tagen die Timer nicht mehr so tun wie sie tun sollen, glaube ich hab den Fehler im Forum früher gefunden als der Hersteller der Anlage den Fehler trotz Wartungsvertrag zugeben wollte-->hab mir ziemlich in die Hosen geschissen weil ich noch nie ein Firmareupdate gemacht habe bzw. nicht nötig war)

Fazit: Kommentare sind wichtig, aber nicht so wichtig wie eine Dokumentation der Software, wobei ich die Dokumentation nicht als Ausdrucken/Hardcopy einiger FUP/KOP/AWL/SCL-Netzwerke ansehe.

Georg

P.S.: Keiner wird mich verstehen, aber mir ist das so was von egal.........


----------



## Blockmove (24 Januar 2013)

Visio ist eine feine Sache.
Wir Nutzen es auch intensiv zur Doku.
Aber nicht für die von dir beschriebenen Zwecke.
Wir programmieren unsere Abläufe in Graph. Besser kannst du Schrittketten in Visio nicht gar nicht dokumentieren.

Gruß
Dieter


----------



## Perfektionist (24 Januar 2013)

ach, hübsch, hier heulen die Wölfe noch lauter als ich 



Blockmove schrieb:


> Mit den vielen erforderlichen Casts / Typwandlungen kann einen der SCL-Compiler schon nerven (zumindest bei Classic). Deshalb ist es von Vorteil den Variablentyp im Namen mitzuführen.


beim SCL-Editor in TIA wird der Typ als Tooltip bzw. im Eigenschaftsfenster angezeigt.



MasterOhh schrieb:


> Was kann der SCL Editor im TIA eigentlich? Der von Step 7 war ja noch recht besch..eiden. Ich meine Sachen wie mit der Maus auf eine Variable zu zeigen und sofort deren Datentyp und Kommentar angezeigt zu bekommen oder die automatische Vervollständigung sind hilfreiche Features.


Ich hab selten Quellen in Classic benutzt, soweit ich mich erinnere, war das ja nur ein reiner Texteditor. In TIA gibt es automatische Vervollständigung, Tooltip: s.o.


----------



## ducati (24 Januar 2013)

ge_org schrieb:


> Als Beispiel verwendeten wir eine kleine Funktionalität in einer Anlage die mit ST programmiert wurde. Bei der Analyse sind wir auf etliche Sachen gestossen, die in der Originalversion nicht-oder unzulänglich-programmiert wurden-->aber trotzdem zu 99% funktioniert hat (aber eben 99%).



Naja, ich kenne kein Programm, bei dem man nach längerem Suchen nicht irgendeinen "Fehler" oder "Unschönheit" finden würde. Das hat viele Ursachen, ist aber leider so. Ansonsten verstehe ich Dich wirklich nicht, was hat das alles mit Kommentaren zu tun?
jedenfalls das Problem an Kommentaren: Bei nachträglichen Änderungen am Programm sind Kommentare immer das letzte, was mit nachgezogen wird. -> falsche Kommentare sind schlimmer als garkeine . Aber da hat sicher jeder so seine eigenen persönlichen Erfahrungen gemacht.

Gruß.


----------



## Larry Laffer (24 Januar 2013)

Perfektionist schrieb:


> Zwinkerer an Larry (er weiß, warum), auch wenns nun von meiner Seite her auch Spam ist ...


Sorry ... der Beitrag von Dieter (Blockmove), auf den du dich da beziehst ist für mich auf einer anderen Schiene angesiedelt. Vielleicht war es auch ein bißchen Spam ... aber wo er Recht hat ... da hat er Recht ... und dann darf er das auch schreiben. Ich denke mal, er sprach da aus einer gewissen schon gemachten "die Hände über dem Kopf zusammen-schlagen"-Erfahrung oder vielleicht auch aus "ich dachte bisher, ich könnte jeden fremden Code verstehen".
So kenne ich es jedenfalls von mir ... Von da her war der beitrag schon ein gutgemeinter Rat ...

Gruß
Larry


----------

