ioBroker / ioBroker.repochecker

Check the ioBroker adapter github repositories if they can be added to public ioBroker repository
MIT License
8 stars 7 forks source link

Check setObject #9

Open Jey-Cee opened 5 years ago

Jey-Cee commented 5 years ago

Ich hab da noch eine Idee für den Adapter Checker: Prüfung im Code ob "setObject" ein mindestmaß an Attributen (common) festlegt. Besonders role, name, type und unit sollten geprüft werden. Wobei Unit nur beim Type number wichtig ist. Hier könnte man auch gleich Vorschläge für role und unit machen.

Anmerkung von Ingo: Am besten das setObject gar nicht genutzt wird sondern setObjectnotexists und so ;-)

Also so wie hier:

setObjectNotExists(id, {
      type: 'state',
      common: {
        name: 'Mein Name',
        role: 'button',
        type: 'number',
        desc: 'Was bin ich',
        unit: 'h',
        read: true,
        write: true,
        def: 0
      },
      native: {}
    })
Apollon77 commented 5 years ago

Am besten prüfen das setObject hsr nicht bei States verwendet wird.

mcm1957 commented 1 year ago

Bitte aufpassen dass da nicht zuvile false Positiv's razskommen. Ich spezifiziere die Parameter des common Objects nicht unbedingt direkt im call zu setObject(NotExists). Ergo müsste der Checker hier prüfen ob ein Object, irgendwo anders voobereitet und übergeben wird. Ergo wird diese Prüfung m.E. ziemlich schwer sein wenn der Test nur mittels Textparsing erfolgen soll.

Apollon77 commented 1 year ago

Es geht darum das "setObject(" nicht genutzt werden sollte. "setObjectNotExists(" ist ok ... Aber die Krux liegt im Detail das setObject für "nicht state" objekte vllt ok ist ... ist blödsinn aber ok

mcm1957 commented 1 year ago

@Apollon77 Ja -gegen den ZUSATZ Punkt setObject zu prüfen hab ich nix einzuwenden. Nur der eigentliche Originalissue regt an die Optionen des setObject Aufrufs zu prüfen. Und das wird mit reiner Testanalyse wohl schwer gehen - auf diesen Aspekt des Originalissues bezieht sich meine Anmerkung.

Zum Thema setObject reduzieren kann ich nur Folgende Idee einbringen - diese erfoodert allerdings einen Anpassung im jscontroller, genaue rim adapter Package: a) jsController / setObject Code im adapter prüft ob der Aufruf für ein state Objekt erfolgt. Ist das der Fall wird einmalig (je Adaterstart) eine Wanring gelogged. b) Dieser Check wird mittels (neuer) Option im io-package.json aktiviert; der adapter-creator setzt die Option per default c) der Adapterchecker prüft ob diese Option i n io-package gesetzt ist. Wenn nicht gibt's ne Warnung.

Damit wäre sichergestellt, dass existierende Installationen bzw. Releases nicht plötzlich mit Warnungen unangenehm auffallen. Andrerseits kann der Adapterchecker den Entwickler auf das Aktivieren der Option hinweisen. Und der Entwickler sollte ja seinen Adapter kurz benutzen und damit die Warnings sehen und reagieren ...

GermanBluefox commented 1 year ago

Es geht schon um Code Analyse. Es ist seit kurzem bekannt und möglich dank "acorn" aber es ist schon ein Aufwand so was zu implementieren. PR ist willkommen.