Kommentare im Quellcode

[klaus_kraemer]

Das Handbuch sagt:


Sie können ihre Programmierung kommentieren. Dazu gibt es zwei Möglichkeiten:
1. Kommentare beginnen mit „//“ und stehen am Anfang einer Zeile.
2. Anstelle einer Anweisung können Kommentare an beliebiger Stelle stehen (Strichpunkt beachten), die durch /* */ eingerahmt werden. Z.B.

/* Dies ist ein Kommentar */
// Das ist noch ein Kommentar
u=5;/* Und dies ist noch Kommentar */; u4=5

Das gelb unterlegte stimmt insofern nicht, als es möglich ist, Kommentare (beider Arten) auch hinter Code in derselben Zeile unterzubringen. Wer das aufgrund des Handbuchs nicht probiert, erhält unübersichtlicheren Code.

Wichtiger aber:
Warum gibt es denn keine intuitive Möglichkeit, ganze Blöcke (wie in jeder normalen Programmiersprache auch) durch einfache Kommentarklammerung auszukommentieren? Da könnte man gleichzeitig auch den Grund des Ausklammerns mit unterbringen, anstatt primitive "//"-Orgien zu feiern.

Beim EibPC geht es nur zeilenweise und ganze Blöcke haben dann in jeder Zeile ein "//" vorne. Das ist unheimlich unübersichtlich und unpraktisch.

Stellt doch bitte die Kommentarklammer "/* ...... */" so zur Verfügung, dass sie auch über Zeilenschaltungen hinweg wirkt.

Statt so etwas

///* -------------------------- Rollladen Wetterschutz ------------------------ */
//:begin RolloWetterschutz(Name, GAStatUnwetter)
//:info $Wetterschutzmakro$\\
//$Name (wegen Eindeutigkeit) entsprechend dem Makro Rollladen$\\
//$Gruppenadresse der Unwetterstatus-GA$
//
//:var storedPosition@
//storedPosition@ = 0f16;
//
//if change(GAStatUnwetter) then {
//    if ( (GAStatUnwetter == EIN) and (Name_DayAutoCloseLamel != dayofweek()) and (Name_DayAutoCloseTotal != dayofweek()) ) then {
//        storedPosition@ = Name_PosAktuell;
//        Name_isUnwetter = EIN;
//    } endif;
//    if ( (GAStatUnwetter == AUS) and (Name_DayAutoCloseLamel != dayofweek()) and (Name_DayAutoCloseTotal != dayofweek()) ) then {
//        Name_isUnwetter = AUS;
//    } endif;
//} endif
//
//:return Name_isUnwetter
//:end​

würde ich das

/* -------------------------- Rollladen Wetterschutz ------------------------ */
/* Auskommentiert zum Test neues Modul
:begin RolloWetterschutz(Name, GAStatUnwetter)
:info $Wetterschutzmakro$\\
$Name (wegen Eindeutigkeit) entsprechend dem Makro Rollladen$\\
$Gruppenadresse der Unwetterstatus-GA$

:var storedPosition@
storedPosition@ = 0f16;

if change(GAStatUnwetter) then {
    if ( (GAStatUnwetter == EIN) and (Name_DayAutoCloseLamel != dayofweek()) and (Name_DayAutoCloseTotal != dayofweek()) ) then {
        storedPosition@ = Name_PosAktuell;
        Name_isUnwetter = EIN;
    } endif;
    if ( (GAStatUnwetter == AUS) and (Name_DayAutoCloseLamel != dayofweek()) and (Name_DayAutoCloseTotal != dayofweek()) ) then {
        Name_isUnwetter = AUS;
    } endif;
} endif

:return Name_isUnwetter
:end

ENDE Auskommentierung RolleWetterschutz */​

Nur zweite und letzte Zeile:

Das würde sich durch zusätzliche "//" vor diesen Zeilen auch schnell und problemlos umschalten lassen.

Also große Bitte: Passt die Kommentarfunktion an den allgemeinen Programmierstandard an!

[klaus_kraemer]

Und noch ein Ärgernis mit Kommentar, der sich so gänzlich anders verhält, wie ein auskommentieren funktionieren sollte - nein: muss!

Ich wollte nur mal testen, wie sich der Weboutput gestaltet, wenn ich eine kleine Änderung mache, die beim nächsten Flashen mitkommt.

image.png

Also schnell mal Zeile 108 kopiert, Zeile 109 geändert und eine horizontale Linie "<hr>" statt Leerzeilen. Jetzt kommts:

Danach noch Zeile 108 "auskommentiert"? Pustekuchen

Beim Übersetzen motzt nämlich der Compiler:

 +---+ EibParser - v5.508 (Windows 64 Bit Version) +---+

Keine Haftung für Schäden, die durch die Benutzung des Programms entstehen.
Datei: "S:\EIB_KNX\EibPC2-Projekte\Amselweg7-EibPC02_tmp\tmpMacroOut.txt" wurde geschrieben

Datei: "S:\EIB_KNX\EibPC2-Projekte\Amselweg7-EibPC02_tmp\tmpMacroFuncOut.txt" wurde geschrieben
Syntax-Fehler:
! Falsche Anzahl von Argumente von Solar_txtBF+$<br>$+Solar_txtMaxTempBoiler+$<br>$+Solar_txtPumpenschalter+$<br>$+Solar_txtdKollBoiu+$<br>$+Solar_txtdVorlRuel+$<br>$+Solar_txtEin+$<br>$+ !
ID:10
EibParser wurde mit Fehler beendet.​

Abgesehen von der unterirdisch irreführenden Fehlermeldung, warum zum Teufel wird eine Kommentarzeile nicht vom Parser ordentlich ausgeblendet? In jeder anderen Programmiersprache funzt das auch!

Der Versuch, statt am Zeilenanfang mit "//", die Kommentarfunktion /* ..... */ zu nutzen, schlägt ebenfalls fehl.

Nach Löschen der Zeile 108 ließ sich das Programm anstandslos übersetzen. Das ist aber nicht gerade Sinn der der Sache, wenn man sich die ursprüngliche Programmierung eines geänderten Programmteils noch als Rückfallebene behalten möchte.

[Uwe!]

soweit ich mich entsinnen kann funktioniert der Kommentar innerhalb eines {....}-Bereiches nicht. Wäre aber natürlich wünschenswert

[klaus_kraemer]

Der Text im Handbuch sagt eigentlich eindeutig, dass das Monierte als Kommentar behandelt werden muss.

Und nein, das ist nicht wünschenswert, sondern muss so sein. Allein, was diese nicht vom User zu verantwortenden Mängel völlig unnötig an Zeit kosten. Dazu wird viel Konzentration dazu verwendet, Fehler nicht im eigentlichen Code, sondern die des EibStudio zu suchen und zu umgehen.

Das EibStudio ist die einzige Programmierumgebung, bei der ich nicht zuallerst einen Fehler bei mir suche.

[klaus_kraemer]

Ergänzend: Mich macht z.Zt. einfach sauer, dass Basics wie Handbuch, Beschreibung neuer Features darin, Beispiele, Kommentarfunktion, Fehlermeldungen sehr stiefmütterlich behandelt werden. Auch das ist Produktqualität, nicht nur der EibPC als Gerät..

Der EibPC ist super und ich möchte ihn nicht missen!

[TabSel]

Hat mich auch schon geärgert dass auskommentierte Zeilen vom Compiler moniert werden

[klaus_kraemer]

foobar0815

Sagt mal ehrlich: Sind solche Inkonsistenzen von Basics im Paket EibPC (einschließlich des den Entwicklungen am EibPC kaum folgenden Handbuchs, (siehe https://knx-user-forum.de/forum/supp...94166-handbuch) für Euch so unwichtig, dass Themen wie diese relativ konsequent unter den Tisch fallen gelassen werden? Soll sich der dumme User doch ein wenig plagen oder halt neue Features nicht verwenden, wenn er so blöd ist, mit dem Experten zu arbeiten?

Nein, das will ich Euch so noch nicht ernsthaft unterstellen, aber in meinem Hinterkopf beginnt es, zu nagen.

[Jukom]

Nichts für Ungut - aber ich finde du trägst hier ein bisschen arg dick auf!

[klaus_kraemer]

Nichts für Ungut - aber ich finde du trägst hier ein bisschen arg dick auf!

Ich finde es nicht übertrieben, die volle Funktionalität zweier nicht ganz billig erworbenen Geräte auch nutzen (können) zu wollen. Dazu gehört eine vollständige Dokumentation und dazu gehört auch, bekannte Fehler mit der Zeit zu beseitigen. Da verlange ich gar nicht, dass das immer sofort sein muss, aber kontinuierlich.

Jukom Du kannst Dich ja gerne mit weniger zufrieden geben - deine Sache.

[PharaDOS]

Ich finde es nicht übertrieben, die volle Funktionalität zweier nicht ganz billig erworbenen Geräte auch nutzen (können) zu wollen. Dazu gehört eine vollständige Dokumentation und dazu gehört auch, bekannte Fehler zu beseitigen.

Jukom Du kannst Dich ja gerne mit weniger zufrieden geben - deine Sache.

Also ich von den Support von Enertex sehr gut, er gehört zu einer der Firmen wo ich super guten support erlebe und die auch Anpassungen von Kundenwünschen in ihre Produkte übernehmen.
Und wer arbeitet macht auch Fehler. Dokumentation im IT-Umfeld ist immer problematisch. Und was stabile Produkte angeht ist Enertex auch immer dabei.
Sicherlich fehlen ein paar dinge, die kennt foobar0815 auch :-) aber auch er hat nur 2 Arme und 1 Kopf.

enertegus Also von mir ein Dickes Lob an euch, wegen support und auch der Produkte. Hoffe das bleibt so (oder noch besser) das ihr immer sehr Kundennah seit.

[klaus_kraemer]

PharaDOS enertegus foobar0815 Dein Lob, was den Support von Enertex angeht, gehe ich gerne mit.

Nur mit der Einschränkung, dass mancher Support erst gar nicht geleistet werden müsste, wenn die Dokumentation qualitativ stimmt (oder überhaupt vorhanden ist). Oder die Fehlersuche sich auf die userseitigen Fehler konzentrieren kann.

Mir ginge es einfach darum, dass statt immer neuen Features mal eine grundlegende Konsolidierung erfolgt, um auf einer qualitativ verbesserten Basis weiter zu entwickeln. Ständig alte Probleme mit- und andere einzuschleppen ist ja auch nicht der Weg.