UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[hub01]

einige Skripte mit const-Anweisungen, z.B.:

const cUeBe1PhAnl = 1200;
const cUeBe1PhLad =  230;

zeigen manchmal folgende Meldungen an:

index1.js  1 von 7 Problemen
Cannot redeclare block-scoped variable ‘cUeBe1PhAnl ‘
index0.js(119, 7): ‘cUeBe1PhAnl ‘ was also declared here.

index1.js  1 von 1 Problemen
Definitions of the following identifiers conflict with those in another file: cUeBe1PhAnl, cUeBe1PhLad, usw.
index0.js(119, 1): Conflicts are in this file.

MOD-EDIT: Code in code-tags gesetzt!

Die Meldungen sind nicht immer da.
Die Skripte laufen auch alle ohne Probleme.

Frage:
wie findet man in Linux/Debian die beiden Dateien „index0.js“ und „index1.js“?
(nicht wo)

wann und warum werden diese Meldung angezeigt?

[Thomas Braun]

@hub01

https://wiki.ubuntuusers.de/find/

[hub01]

@thomas-braun

find / -name index0.js
=>
find: ‘/sys/kernel/debug’: Keine Berechtigung
find: ‘/sys/fs/bpf’: Keine Berechtigung
find: ‘/run/user/1000/doc’: Keine Berechtigung

MOD-EDIT: Code in code-tags gesetzt!

usw.

[hub01]

@hub01
"find" scheint die beiden Dateien nicht zu finden

[Thomas Braun]

@hub01

Logisch, der user darf die Verzeichnisse nicht betreten.

[Codierknecht]

@hub01 sagte in Cannot redeclare block-scoped variable:

einige Skripte

Wie heißen denn die Scripte in denen das auftritt?

Hast Du globale Scripte im Einsatz?

BTW: Du bist sicher, dass Du in einigen Monaten noch weißt, was sich hinter cUeBe1PhAnl, cUeBe1PhLad usw. verbirgt? Sprechende Variablennamen fressen kein Brot ;-)
https://dev.to/gervaisamoah/a-guide-to-clean-code-the-power-of-good-names-3f6i

[Ralf 2]

@hub01
Handelt es sich im JavaScript oder um TypeScript?
TypeScript schaut auf ggf. alle Scripte und wirft dann diese Meldung (oder manchmal auch nicht).
Man kann die Meldung ignorieren, oder ein Export davor setzen:

export const cUeBe1PhAnl = 1200;
export const cUeBe1PhLad =  230;

Ich setze in meinen Scripten gerne in doIt() als Function für die Hauptfunction ein, auch das wird immer wieder angemeckert, auch hier hilf ein export vor der deklaration der Function.

[OliverIO]

@hub01

wo hast du diese ausgaben herauskopiert? im javascriptadapter steht das so eigentlich nicht drin
im iobroker log ebenfalls nicht

wenn du mit vscode arbeitest, dann gibt es da so eine globalsuche

oder im javascriptadapter die suche, die über alle skripte nach deinem variablennamen sucht.
const (Konstante) variablen dürfen nicht wieder beschrieben werden, also wenn du irgendwo

cUeBe1PhAnl = 123

findest, dann ist das der Fehler.
oder du änderst const einfach in let um

[OliverIO]

@ralf-2 sagte in Cannot redeclare block-scoped variable:

TypeScript schaut auf ggf. alle Scripte und wirft dann diese Meldung (oder manchmal auch nicht).

typescript erkennt ob man eine const variable wieder beschreiben möchte und wählt dann für den transpilierten code die richtige deklaration bzw zeigt einen fehler an.

[hub01]

@thomas-braun sagte in Cannot redeclare block-scoped variable:

@hub01

Logisch, der user darf die Verzeichnisse nicht betreten.

Dann ist find keine Möglichkeit, die Files zu finden?
Oder gibt es da noch einen Parameter, oder einen anderen Weg?

[OliverIO]

@hub01

das weiß ich nicht.
du hast meine fragen noch nicht beantwortet, wo du das rauskopiert hast.

[hub01]

@codierknecht sagte in Cannot redeclare block-scoped variable:

@hub01 sagte in Cannot redeclare block-scoped variable:

einige Skripte

Wie heißen denn die Scripte in denen das auftritt?

Hast Du globale Scripte im Einsatz?

BTW: Du bist sicher, dass Du in einigen Monaten noch weißt, was sich hinter cUeBe1PhAnl, cUeBe1PhLad usw. verbirgt? Sprechende Variablennamen fressen kein Brot ;-)
https://dev.to/gervaisamoah/a-guide-to-clean-code-the-power-of-good-names-3f6i

Die Scripte lauten „PV Werte“, „PV Überschussladen“ usw.
Keine globalen Scripte.
Alle Skripte liegen in einem Ordner „HS_Skripte“.
Ob dieser Ordner global ist, kann ich nicht erkennen.

Ich kennzeichne jede Konstante und Variable mit einem Kommentar.
Zu meiner Zeit war Speicher knapp und ich tu mich so leichter beim Lesen vom Script.

//                                  // benötigter Überschuss [W]:
//                                  // --------------------------------------------
const cUeBe1PhAnl = 1200;           // 1phasig Anlauf                    (>230V*6A)
const cUeBe1PhLad =  230;           // 1phasig Hochschalten               (230V*1A)
const cUeBe1PhHyst = 100;           // 1phasig Hysterese
const cUeBe3PhAnl = 4250;           // 3phasig Anlauf                  (>3*230V*6A)
const cUeBe3PhLad =  690;           // 3phasig Hochschalten             (3*230V*1A)
const cUeBe3PhHyst = 150;           // 3phasig Hysterese
const cUeBeUm     = 1150;           // Umschaltung 1->3Ph (1x16A->3x7A) 5A ( 5,00A)

[Thomas Braun]

@hub01 sagte in Cannot redeclare block-scoped variable:

Dann ist find keine Möglichkeit, die Files zu finden?

find ist DIE Möglichkeit files zu finden.

Zur Not halt mit root-Rechten ausführen.

[hub01]

@hub01
weitere Antworten:

Es sind JavaScripts

Die beiden Meldungen hatte ich so nicht eingestellt.
Die wurden nachträglich (wohl aus Versehen) in Code-Tags gesetzt.

Die Konstanten werden nicht in mehreren Scripts verwendet und auch nicht neu beschrieben.
Aber es gibt ältere Versionen meiner Scripts, die aber nicht laufen.
Könnten davon die Meldungen kommen?

[Codierknecht]

@hub01 sagte in Cannot redeclare block-scoped variable:

Ich kennzeichne jede Konstante und Variable mit einem Kommentar.

Der Mann gilt als einer der Mitentwickler von C. Der sollte es wissen ;-)

Bei sowas wie

const UEBERSCHUSS_1PHASIG_ANLAUF = 1200;
const UEBERSCHUSS_1PHASIG_LADEN =  230;
const UEBERSCHUSS_1PHASIG_HYSTERESE = 100;
const UEBERSCHUSS_3PHASIG_ANLAUF = 4250;
const UEBERSCHUSS_3PHASIG_LADEN =  690;
const UEBERSCHUSS_3PHASIG_HYSTERESE = 150;
const UEBERSCHUSS_UMSCHALTEN = 1150;

spart man sich den Blick auf die Deklaration. Da weiß man in jeder Codezeile gleich, um was es geht.

Zu meiner Zeit war Speicher knapp

Zu meiner auch. Bei Microcontrollern ist er es z.T. immer noch.
Aber hier braucht ja der Kommentar mehr Speicher als ein sinnvoller Name.
Und im Compilat sind das eh nur Adressen. Die sind immer gleich lang - egal wie lang der Name einer Variablen oder Konstanten sein mag.

Aber bitte nicht als Belehrung verstehen. Das macht jeder wie er meint.
Ich selbst habe das auch Jahrzehnte lang eher knapp gehalten und beiße mir auch bei meinem Team die Zähne aus. Da komme ich mir ein bisschen vor wie Don Quichote ;-)
Irgendwann kommt man dann dahinter, dass sich Code bei klarer Benamsung einfach viel besser lesen lässt ... ohne jegliche Kommentare.

Ich würde da aber nicht so weit gehen wie Uncle Bob:

[OliverIO]

@codierknecht

da gibt es schöne regeln zur code quality, die sich automatisiert messen lassen
oder durch linting überprüfen lassen.

• Markiere den Anfang und das Ende von Kontrollstrukturen mithilfe von Einrückungen und platziere den Code dazwischen.
• Beschränke dich auf wenige Zeilen.
• Vermeide lange Funktionen – ein professioneller Entwickler stimmt zu, dass eine Funktion jeweils nur eine einzelne Aufgabe erfüllen sollte.
• Verwende präzise Namenskonventionen.
• Halte Zeilen kurz – offensichtlich bevorzugen Menschen kürzere Zeilen, egal ob vertikal oder horizontal.
• Nutze das DRY-Prinzip (Don’t Repeat Yourself). Du solltest denselben Code nicht im selben Skript wiederholt einsetzen, sondern wiederkehrende Aufgaben automatisieren.
• Schreibe SQL-Schlüsselwörter und -Funktionen in Großbuchstaben, um sie von Spalten- und Tabellennamen zu unterscheiden.
• Vermeide tiefe Verschachtelungen.
• Hinterlasse Kommentare und setze Prioritäten bei der Dokumentation.

[hub01]

Ist vermutlich eine Umgewöhnungssache.

Wie gesagt, tu ich mich mit Kommentaren leichter.
Die kann ich kurz, aber verständlich halten, ohne die Syntax der Programmiersprache zu berücksichtigen.
Wenn ich die Kommentare anschaue, weiß ich schnell, was der Code macht.

if ((LadeAnsteuerung == VonVisu_Ansteuerung_EIN && Wallbox_Freigabe && Wallbox_Kommunikation_IO)) {
    if (VonVisu_3PhasenLaden_zulaessig && Ueberschuss_vorhanden_3Phasen_Anlauf>Ueberschuss_benoetigt_3Phasen_Anlauf) {
    ...
    }

    else if (VonVisu_1PhasenLaden_zulaessig && Ueberschuss_vorhanden_1Phasen_Anlauf>Ueberschuss_benoetigt_1Phasen_Anlauf) {
    ...
    }

if ((iLAnst==cAnstEin && bWBFrg && bWBKommIO)) {        // Einschalten?  Freigabe?  WB-Kommunikation iO?
    if (b3PhZul && iUeVorh3PhAnl>cUeBe3PhAnl) {         // 3Phasen zulässig?  3Ph-Anlauf-Überschuss vorhanden?
    ...                                                 //   starte 3-phasig
    }                                                   //   usw.

    else if (b1PhZul && iUeVorh1PhAnl>cUeBe1PhAnl) {    // 1Phasen zulässig?  1Ph-Anlauf-Überschuss vorhanden?        
    ...                                                 //   starte 1-phasig
    }

[Codierknecht]

@hub01 sagte in Cannot redeclare block-scoped variable:

Ist vermutlich eine Umgewöhnungssache.

Ist es! Das dauert möglicherweise Jahre.

Hat man sich aber einmal daran gewöhnt, will man's nicht mehr anders haben.
Als Einzelkämpfer dient das lediglich den eigenen Idealen (und der Lesbarkeit nach Monaten oder Jahren).
Aber spätestens wenn's um Adapter-Code geht und Dir die Reviewer jede zweite Codezeile um die Ohren hauen, gewöhnt man sich ganz schnell daran :grin:

[Codierknecht]

@oliverio
OT: Die Coding-Conventions in meinem Team umfassen einige Bildschirmseiten.
Der größte Teil davon wird in der Continuous-Integration-Pipeline als allererstes automatisch geprüft.
Wird gegen die Regeln verstoßen, bricht CI ab und das ganze Team erhält 'ne nette Mail. Das übt :grinning:

[OliverIO]

@codierknecht
Sehr gut
Wobei ich eher ein Fan davon wäre das das jeder einzelne sofort sieht und nicht erst aus einer Pipeline.

Aus diesem Grund habe ich den repochecker auch erweitert das er auch lokal prüft.
Seither ist die Anzahl der rebuilds und daraus resultierende folgefehler (versionsnummer kann nicht auf npm gefunden werden) gesunken.