Autor Thema: PMD-CPD Analyse nach Duplikaten, Codeverdopplungen, Copy & Pastes und so  (Gelesen 1859 mal)

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 596
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
https://pmd.github.io/latest/pmd_userdocs_cpd.html

Ich habe mal CPD, den Copy & Paste Detektor über FHEM gejagt.

Die Karl-Theodor Maria Nikolaus Johann Jacob Philipp Franz Joseph Sylvester Buhl-Freiherr von und zu Guttenbergs sind im Anhang aufgeführt.

Den Grund, warum man Duplikate vermeiden sollte spare ich mir an dieser Stelle, o.g. Link hat eine nette Zusammenfassung. Für mich kann ich nur sagen, das Dupletten im Code einer der größten Schandflecke sind von die wo's gibt. Ich wäre zutiefst betrübt wieder eine Diskussion zu erleben warum gerade in FHEM 1:1 Code-Duplikate ein Muss oder "schon in Ordnung" sind.

« Letzte Änderung: 11 April 2020, 10:16:51 von RichardCZ »
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline JoWiemann

  • Tester
  • Hero Member
  • ****
  • Beiträge: 2876
PMD-CPD Analyse nach Dupletten
« Antwort #1 am: 11 April 2020, 09:58:18 »
Besserwisser: Du sprichst von Dublette(n)?!

Wobei eine Dublette und ein Duplikat unterschiedliche Sachverhalte beschreiben.


Gesendet von iPad mit Tapatalk
« Letzte Änderung: 11 April 2020, 10:01:26 von JoWiemann »
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 596
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:PMD-CPD Analyse nach Dupletten
« Antwort #2 am: 11 April 2020, 10:07:36 »
Besserwisser: Du sprichst von Dublette(n)?!

Wobei eine Dublette und ein Duplikat unterschiedliche Sachverhalte beschreiben.

Ja, da ist das Englische "Dupe" mit mir durchgegangen.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22650
Antw:PMD-CPD Analyse nach Dupletten
« Antwort #3 am: 11 April 2020, 10:26:42 »
Zitat
Ich wäre zutiefst betrübt wieder eine Diskussion zu erleben warum gerade in FHEM 1:1 Code-Duplikate ein Muss oder "schon in Ordnung" sind.
Das wirst du von mir auch nicht hoeren, ich vermeide Duplikate, wo ich kann, stellenweise schon krankhaft.

Allerdings ist FHEM ein Gemeinschaftsprojekt, und aus Sicht eines Benutzers ist ein Modul, was Code kopiert, besser, als gar kein Modul. Das heisst nicht, dass ich das toll finde, ich weiss aber nicht, wie ich das ohne Maintainer abzuschrecken verbessern soll. Ich sehe den typischen Maintainer als den Familenvater, der ein Problem mit FHEM loesen kann, dafuer zwangsweise ein bisschen Perl lernt, aus Nettigkeit sein Code spendiert, aber nicht vor hat seine Familie fuer FHEM zu verlassen, und ein Perl-Guru will er auch nicht werden.

Ich mache mir sorgen, dass Deine unsanften Hinweise, auch wenn alleine betrachtet meist richtig sind, manche davon abhalten ein Modul zu veroeffentlichen. Nach dem Motto: lieber die Klappe halten, als ausgelacht werden.

Ich bin immer noch bei meinem urspruenglichen Vorschlag: mach Beispielmodule, und wir empfehlen diese als Grundlage fuer Neulinge.
Gefällt mir Gefällt mir x 5 Liste anzeigen

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5642
Naja, für mich kann ich es beantworten. In GSI habe ich Code welcher funktioniert und den brauche ich auch in JsonMod. Weil Module self-contained sein sollen kopiere ich den halt rüber. Wenn wir das lockern sollten wäre ich happy den code auszulagern und in beiden Modulen zu verwenden. Um ehrlich zu sein weiß ich zwar nicht wo die Regel steht aber ich meine mich an Diskussionen zu erinnern und das Fazit war 'ein Modul, eine Datei'. Eventuell ist das aber gar nicht mehr aktuell (?)
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 596
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:PMD-CPD Analyse nach Dupletten
« Antwort #5 am: 11 April 2020, 11:32:43 »
Familenvater, der ein Problem mit FHEM loesen kann, dafuer zwangsweise ein bisschen Perl lernt, aus Nettigkeit sein Code spendiert, aber nicht vor hat seine Familie fuer FHEM zu verlassen, und ein Perl-Guru will er auch nicht werden.

Ich mache mir sorgen, dass Deine unsanften Hinweise, auch wenn alleine betrachtet meist richtig sind, manche davon abhalten ein Modul zu veroeffentlichen. Nach dem Motto: lieber die Klappe halten, als ausgelacht werden.

Ich bin immer noch bei meinem urspruenglichen Vorschlag: mach Beispielmodule, und wir empfehlen diese als Grundlage fuer Neulinge.

Du willst Beispielmodule im gegebenen Rahmen. Das geht nicht, der Rahmen ist zu klein.
Ich kann aus einem Golf I keinen Veyron machen und einen Spoiler draufpappen und Streifen draufmalen betrachte ich nicht als "Beispielmodul".

Lass uns darüber reden den Rahmen an einigen Stellen zu verbessern, dann kann man auch wirklich auf bessere Beispiele hoffen:
https://forum.fhem.de/index.php/topic,110036.msg1040579.html#msg1040579
Was nicht bedeutet, dass die Anleitung wie man bessere FHEM Module auch in diesem Rahmen baut bereits erarbeitet wird:
https://forum.fhem.de/index.php/topic,110048.0.html (u.a.)



Diese Argumentation mit "Perl Guru" entlarvt an dieser Stelle die Diskussion als ein reines Sammelsurium von Schutzbehauptungen. Hier geht es nicht um Perl. Hier geht es um Softwareentwicklung im Allgemeinen. PMD-CPD unterstützt 20 oder 30 Sprachen, da ist Perl nur eine davon. Code Dpulikate sind in jeder Sprache ein Graus und zu vermeiden. Da gibt es auch nicht viel zu diskutieren.

Ich habe noch nie jemanden wegen seinem Code ausgelacht. Ich kann mich über Code lustig machen, nicht über die Person dahinter. Siehe
https://forum.fhem.de/index.php/topic,109511.0.html

Das Argument mit "besser als nix", "einem geschenkten Gaul" etc. verstehe ich. Was ich aber nicht verstehe, dass man bei FHEM in diesem zusammenhang die verquere Regel hat, dieser nette Amateurspender habe die alleinige Hoheitsgewalt über diesen seinen gespendeten GPL code(!) im Repo. Thema Janitors wieder. Das macht das FHEM-Entwicklungsmodell zu einem altbackenen "wir entwickeln nicht gemeinsam, sondern so nebeneinander her".

PS:

Und bitte, schiebt euch den "Perl Guru" sonstwohin. Perl macht 5% meines Skill Sets aus. Wer mich nur darauf reduzieren will, wird früher oder später seinen tiefenpsychologischen Aha-Effekt erleben.

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 596
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Weil Module self-contained sein sollen kopiere ich den halt rüber.

Bitte was sollen die sein??? Was soll das überhaupt bedeuten? Alles in einem File oder was?

Dann macht natürlich das ~1MB EnOcean.pm "Sinn". Gibt es noch mehr so Regeln von denen man wissen sollte? z.B. nur in Unterhose programmieren oder so?

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5642
Bitte was sollen die sein??? Was soll das überhaupt bedeuten? Alles in einem File oder was?
Ja, alles in einem file.
Zitat
Gibt es noch mehr so Regeln von denen man wissen sollte? z.B. nur in Unterhose programmieren oder so?
Bist heute auf Stress gebürstet. :) Und ja, ich trage regelmäßig eine Unterhose beim programmieren. Aber hey, was immer Du willst (aber bitte, bitte, keine Details hier posten!!!)  :D :D :D

smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 596
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Ja, alles in einem file.

Super. Womit der Rahmen nochmal ein Stück kleiner geworden ist.
Und meine Anleitung hier: https://forum.fhem.de/index.php/topic,110048.0.html
ist demnach "laut den gegenwärtigen FHEM Regeln"(tm) fürn Arsch. Soviel zu "Beispielmodul".

Sorry. Ich kann ja verstehen wenn man vor 15 Jahren mal falsche Designentscheidungen und irgendwelche seltsamen (um nicht zu sagen: komischen)  Regeln aufgestellt hat. Weil man es entweder nicht besser wusste oder weil es damals(!) Sinn gemacht hat. Aber der Zeitpunkt ab dem ein Verteidigen dieser Anachronismen kafkaesk wird ist verdammt nah - wenn wir ihn nicht bereits überschritten haben.



Hey - warum wusste ich, dass wenn ich wieder ein Thema aufmache bei dem es nix zu Diskutieren gibt, dass dennoch eine Diskussion mit Nebenschauplätzen erfolgt? Muss irgendein FHEMVID-05 hier sein.


Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5642
...
ist demnach "laut den gegenwärtigen FHEM Regeln"(tm) fürn Arsch. Soviel zu "Beispielmodul".
Kaum zu glauben dass es überhaupt Module gibt .. ;) So, aber jetzt chill mal ein wenig und genieß das Wetter !

Mittlerweile gibt es ja einige libs die den Weg durchaus geschafft haben. Mal schauen was der Rest zu eigenen libs sagt.

vg
Joerg
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline amenomade

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6306
Wie kann man =pod Text zwischen CommandRef DE/EN deduplizieren?

Siehe z.B.
Found a 58 line (405 tokens) duplication in the following files:
Starting at line 4250 of /data/proj/fhem/trunk/fhem/FHEM/32_WifiLight.pm
Starting at line 4895 of /data/proj/fhem/trunk/fhem/FHEM/32_WifiLight.pm

Found a 94 line (305 tokens) duplication in the following files:
Starting at line 4746 of /data/proj/fhem/trunk/fhem/FHEM/42_SYSMON.pm
Starting at line 5324 of /data/proj/fhem/trunk/fhem/FHEM/42_SYSMON.pm

Found a 102 line (479 tokens) duplication in the following files:
Starting at line 1145 of /data/proj/fhem/trunk/fhem/FHEM/44_S7.pm
Starting at line 1251 of /data/proj/fhem/trunk/fhem/FHEM/44_S7.pm
« Letzte Änderung: 11 April 2020, 14:59:55 von amenomade »
FHEM 5.9 Pi 3, EchoDot, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 596
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Wie kann man =pod Text zwischen CommandRef DE/EN deduplizieren?

Siehe z.B.
Found a 94 line (305 tokens) duplication in the following files:
Starting at line 4746 of /data/proj/fhem/trunk/fhem/FHEM/42_SYSMON.pm
Starting at line 5324 of /data/proj/fhem/trunk/fhem/FHEM/42_SYSMON.pm

Also selbst bei den derzeit verfügbaren bescheidenen Bordmitteln würde ich ja sowas wie

Beispiele siehe <a href="commandref_EN.html#SYSMON">EN Doku</a> machen.
Und diese eben nur an einer Stelle pflegen.

Wo das nicht geht, geht's halt nicht. Dann müsste man sich überlegen, ob =pod in einem multilingualen Umfeld die richtige Wahl ist.

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3407
    • HMCCU
Ich bin beruhigt. Die Dupletten in meinen Modulen könnt ihr ignorieren. Da wurde das veraltete RPC Modul mit dem neuen verglichen => grüne Tonne.
Wundert mich, dass da nicht mehr doppelt ist.
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline dev0

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3578
    • _.:|:._
Antw:PMD-CPD Analyse nach Dupletten
« Antwort #13 am: 12 April 2020, 11:27:12 »
Was ich aber nicht verstehe, dass man bei FHEM in diesem zusammenhang die verquere Regel hat, dieser nette Amateurspender habe die alleinige Hoheitsgewalt über diesen seinen gespendeten GPL code(!) im Repo.

Ich muss ein wenig ausholen:

Ich bin Ersteller des 34_ESPEasy.pm FHEM Modules und des entsprechenden ESPEasy Firmware Controller Plugins. Und: nein, ich bin kein Programmierer oder Softwareentwickler, ich habe mir ein wenig Perl und C Syntax angeeignet um meine Bedürfnisse in FHEM umsetzen zu können.

Ich würde mich darüber freuen, wenn neben mir noch jemand meine Module betreuen würde (Code verbessern, an aktuelle Firmware Version anpassen, etc.). Derjenige müßte die Änderungen allerdings auch supporten bzw. ggf. zurück drehen, wenn es Probleme gibt. Es gibt ja zur Zeit leider keinen Test/Dev Zweig im svn...

Nachdem mein Pull Request des FHEM Controllers in das ESPEasy Projekt eingeflossen ist, ist das Plugin mehrfach von unterschiedlichen Mitstreitern angepasst und optimiert worden. Das finde ich toll und sinnvoll und es gab bisher nie Probleme und wenn, dann wäre das nach x Issues auf Github zurück gezogen oder gefixed worden, da bin ich mir recht sicher.



Code Duplikate und wiederverwendbaren Code erstellen:

Ich habe das ESPEasy Modul so ausgelegt, dass der Anwender die Möglichkeit hat Zugriffe auf IP Adressen/Bereich zu beschränken. Eine Möglichkeit wäre gewesen, die FHEM interne und regex basierte Variante zu benutzen. Da ich das als Netzwerker und Anwender als unbefriedigend befand, habe ich einen eigenen access controll Mechanismus eingebaut, der die Eingaben von IPs, Komma separierten Listen, Netmasks (bitmask oder dotted decimal) oder regex erlaubt und umgehe dabei den FHEM internen Mechanismus.
Klar, man jetzt sagen, warum nicht einen Patch an den Core Entwickler schicken und hoffen, dass es eingebaut wird. Mit Sicherheit ist mein Code weder optimiert, zu teuer (lahm) und nicht auf Angriffe getestet, um ihn in allen Modulen zu verwenden. Das kann ich als "Anweder" auch nicht leisten.
[EDIT:] Ggf. wäre es viel sinnvoller gewesen nach einem entsprechen CPAN Modul zu suchen, dass das viel besser kann, aber auch da ist die jetzige FHEM Policy mMn nicht sehr sinnvoll: Mach alles alleine mit möglichst wenig Abhängigkeiten... Zumindest hatte ich das damals so im Kopf.

Mein Gedanke war ursprünglich mal den Code in eine NetUtil.pm oder so auszulagern, um ihn Anderen zugänglich zu machen. Aber dann wäre ich, nach jetzigen Vorgehen (eine Datei - ein Maintainer), der Maintainer dafür gewesen und hätte die Verantwortung dafür übernehmen müssen. Das wollte und hätte ich nicht leisen können. Ganz abgesehen von dem bashing "wer braucht den sowas -  das können wir auch jetzt schon alles mit einer regex definieren".

Ich fände es gut die Prinzipien von "ein Modul -> eine Datei" und "ein Modul und niemand anderes geht daran" aufzuweichen und zu überdenken.

Was könnten die Nachteile sein, wenn "globale" Entwickler Code von anderen anfassen? Klar, irgendetwas funktioniert nicht mehr und der "globale Entwickler" hat nicht die Möglichkeit das nachzuvolluiehen, weil er zB. die Hardware nicht hat, die sich buggy verhält. Dann muss das zurück gedreht werden, aber viel besser __vorher__ in einem eigenen Branch vorab zur Verfügung gestellt werden. Auch wenn das bisher nicht so funktioniert hat wie es sollte...



Wie dem auch sei:

Selbst wenn @RichardCZ eine Heuschrecke seien sollte, die nach x Wochen/Monaten/Jahren weiter zieht, wäre mMn etwas positves in FHEM bewegt worden, wenn man darauf eingeht und seine Art und Weise beiseite läßt. Die Art und Weise von einigen alten Hasen ist teilweise auch recht hart und läßt Hobbyisten erstarren.
« Letzte Änderung: 12 April 2020, 12:02:52 von dev0 »
Zustimmung Zustimmung x 2 Liste anzeigen

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 596
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:PMD-CPD Analyse nach Dupletten
« Antwort #14 am: 12 April 2020, 12:20:19 »
Was könnten die Nachteile sein, wenn "globale" Entwickler Code von anderen anfassen? Klar, irgendetwas funktioniert nicht mehr und der "globale Entwickler" hat nicht die Möglichkeit das nachzuvolluiehen, weil er zB. die Hardware nicht hat, die sich buggy verhält. Dann muss das zurück gedreht werden, aber viel besser __vorher__ in einem eigenen Branch vorab zur Verfügung gestellt werden. Auch wenn das bisher nicht so funktioniert hat wie es sollte...

Meine - wiederholte - Anspielung auf das "Janitors"-Konzept des Linux-Kernels geht ja noch nicht einmal so weit wie "Globaler" Entwickler.
Die Aufgabe eines Janitors ist es Code sauber zu machen (Stichwort: Refactoring, Dokumentation) und das beinhaltet explizit NICHT Änderungen an der Funktionalität.

D.h. ja, ohne Testsuite kann es natürlich schon mal zu Regressionen kommen, aber das sollte die Ausnahme und nicht die Regel sein, denn ein Janitor geht ja mit der Maßgabe an den Code eben nix funktional zu verändern. Ergo sollte (sollte!) eine Umformatierung des Code, perlcritic/PBP Anpassungen, Namespace Aufräumarbeiten etc. gar nicht am User ankommen.

Leider - und da muss man als Janitor auch sehr diszipliniert sein - ist es nicht nur "nix funktional ändern", sondern manchmal sogar: Behalte den gegenwärtigen Fehler bei obwohl Du es besser weist.

Ich habe z.B. an etlichen Stellen ein

my $x = shift || return 'blah';

lassen müssen, obwohl eindeutig ist, dass man

my $x = shift // return 'blah';

meinte. FHEM behandelt an ungefähr 1000 Stellen eine Eingabe von 0 "als gäbe es sie nicht", aber das zu korrigieren ist eigentlich schon knapp hinter der Grenze des Wirkbereichs eines Janitors.


PS: Eine Heuschrecke, die erst nach Jahren weiterzieht ist IMHO keine Heuschrecke mehr.


Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22650
Zitat
Es gibt ja zur Zeit leider keinen Test/Dev Zweig im svn...
Das ist falsch, siehe svn list svn+ssh://svn.fhem.de/branches, und keiner kraeht danach, wenn jemand einen Neuen anlegt.
Das Problem ist: es ist eine Privatveranstaltung, keiner macht sich die Muehe es zu testen. Die Entwickler nicht (die wollen ihren eigenen Kram entwickeln), und die Benutzer nicht, die wollen ein stable branch mit den neuesten Features.

Der Hintergrund zu den Maintainer-Prinzip: es hat sich nach anfaenglichen Experimenten ohne eine Richtlinie als sinnvoll erwiesen, wenn jemand weiss, was in einem Modul "los ist". Sonst baut jemand ein Feature ein, was unter anderem Namen schon gibt, und unvertraeglich mit einem dritten ist. Wenn ein Benutzer ein Problem meldet, dann zuckt der urspruengliche Entwickler sein Schulter (er hat den Mist nicht eingebaut), und der Wohlwollende auch, der will/kann gar nicht Support leisten.
Es geht darum, einen Verantwortlichen fuer ein Modul zu haben. Wenn mehrere es schaffen, das unter sich zu organisieren, ist es mir egal, aber ich will einem Maintainer garantieren, dass er die Chance hat, die Uebersicht zu behalten.

Kein Regel ohne Ausnahme: wenn ein neuer Regel (z.Bsp. bei der Formatierung der Doku) in Developer kommuniziert, und nach Monaten nicht angewendet wird, dann wird es trotzdem durchgefuehrt. Ist aber selten, und war bisher nur auf die Doku bezogen.

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 596
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Wie wäre es mit einem OPT-OUT?

Wer keinen Janitor in seinem Code haben möchte, macht am Anfang eine Zeile

# FHEM-TAGS: NOJANITOR

(dann können wir uns auch noch andere Tags überlegen), und dann wird der Code in Ruhe gelassen.
Ist zwar IMHO kontraproduktiv, weil es u.U. globale Aufräumarbeiten wie min/max torpedieren kann und deswegen auch OPT-OUT und nicht OPT-IN. Wer sich dem explizit entgegenstellen will, soll das auch sagen.

Aber ich verstehe die Bedenken von Maintainern schon. Vermutlich ist die ganze Geschichte - wie so vieles - einfach nur Vertrauenssache.

"Ich habe ein Modul für das ich verantwortlich bin, da will ich nicht, dass mir das einer zerschiesst."

Dann gebe ich hiermit zu Protokoll, dass diese Sichtweise eines Maintainers richtig ist. Ich würde das genauso sehen. Wenn ich für etwas verantwortlich bin und eine drite Seite grätscht rein und verursacht eine Regression, dann drücke ich vielleicht einmal das Auge zu, beim zweiten Mal ist der OPT-OUT so schnell drin, so schnell kann keiner svn commit sagen. Bzw. ich klage bitterlich und verlange nach einem besseren Janitor.

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5642
Ich erlaube mir das Thema 'ein Modul - ein file' vs 'eigene libs' nochmals noch oben zu bringen. Bisher hat sich niemand gemeldet was idr entweder bedeutet 'kein Interesse' oder die Frage ist untergegangen.

Im ersteren Fall ist es ok. Von meiner Seite aus würde ich es begrüßen die Möglichkeit zu haben. In der Praxis findet es ja auch schon teilweise statt, ist aber imho nirgendwo sauber geregelt.
« Letzte Änderung: 12 April 2020, 12:59:55 von herrmannj »
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25738
Ich wäre dafür zu versuchen einen modernen Programmierstil ein zu führen.
Klassen Unterteilung und Bibliotheken wo wir mehrfach vorkommenden Code auslagern.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net
Zustimmung Zustimmung x 1 Liste anzeigen

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 596
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Ich erlaube mir das Thema 'ein Modul - ein file' vs 'eigene libs' nochmals noch oben zu bringen.

Ich wollte da ursprünglich bitten etwas Nachforschung zu betreiben. Sprich: gibt es diese Regel wirklich irgendwo oder ist das nur so ein Mythos?
Du konntest die ja laut eigener Aussage auch nirgends finden.

Denn für gewöhnlich ist die Verwendung von mehr als einem package pro File zwar möglich, aber wird nicht als gute Praxis angesehen.
(siehe z.B. https://perlmaven.com/packages-modules-and-namespace-in-perl)

Und vom technischen her gibt es auch nicht viel zu diskutieren. Die ganze use/require Infrastruktur von Perl geht davon aus, dass man ein

use FHEM::Washlet::TOTO;

auch in einem @INC Verzeichnis unter FHEM/Washlet/TOTO.pm vorfindet.

Ich weiß, dass ich mir mit solchen Aussagen nicht viele Freunde mache, aber gegenwärtig weiß ich echt nicht wie man in einem Perl Projekt dieses filename <-> package name schlimmer machen könnte, als es gegenwärtig in FHEM praktiziert wird. Also selbst wenn ich bewusst wollte - weiß ich nicht wie. Und meine Fantasie ist nicht gering.

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3642
Ich hätte auc noch was. Als ich das 38_BEOK Modul geschrieben habe brauchte ich Perl Code für das Broadlink Protokoll.
Was lag also näher als alles was ich brauchte mir aus 38_Broadlink zu "borgen" und im Kopf meines Moduls eine Zeile zu hinterlassen :
# Broadlink protocol parts are stolen from 38_Broadlink.pm :) , THX to daniel2311Wie bitte löst man sowas elegant ? Die betroffenen Subs in eine eigene Datei auslagern ? und wer ist dann für diese Datei vernatwortlich ?
bzw. der andere Maintainer muß dabei auch mitspielen und sein Modul auch anpassen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 596
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Ich hätte auc noch was. Als ich das 38_BEOK Modul geschrieben habe brauchte ich Perl Code für das Broadlink Protokoll.
Was lag also näher als alles was ich brauchte mir aus 38_Broadlink zu "borgen" und im Kopf meines Moduls eine Zeile zu hinterlassen :
# Broadlink protocol parts are stolen from 38_Broadlink.pm :) , THX to daniel2311Wie bitte löst man sowas elegant ? Die betroffenen Subs in eine eigene Datei auslagern ? und wer ist dann für diese Datei vernatwortlich ?
bzw. der andere Maintainer muß dabei auch mitspielen und sein Modul auch anpassen.

Elegant löst man sowas so, dass es ein

FHEM::Broadlink

unter FHEM/Broadlink.pm gibt

und Du machst dann in Deinem Modul ein

use FHEM::Broadlink qw(magic_sub);

Falls ich das recht verstanden habe, diskutieren wir gerade ob wir künftig elegant wollen.
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22650
Zitat
Sprich: gibt es diese Regel wirklich irgendwo oder ist das nur so ein Mythos?

Wenn man ein Schreibzugriff aus SVN bekommt, kriegt man die:
Zitat
Standard Belehrung:
========
- nur die eigenen Module modifizieren, sonst dem Maintainer Patches schicken.
- nach FHEM kommen nur die Module, die dokumentiert und im Forum betreut sind
  (siehe MAINTAINER.txt), sonst nach contrib.
- falls das Modul nach FHEM kommt, dann bitte das betroffene Forum (wg.
  Support) und Developer (wg. allgemeine API-Aenderungen) abonnieren.
- vor dem Einchecken alles (auch Doku, mit contrib/commandref_join.pl &
  Browser) testen, und die letzten Aenderungen mit "svn diff FHEM/MyModul.pm"
  pruefen.
- neue Verzeichnisse duerfen nur nach Ruecksprache mit mir angelegt werden, das
  Gleiche gilt fuer das Einchecken von fremden Dateien wie Bibliotheken, usw.
========

Der letzte Punkt is reingekommen, weil ich CPAN nicht doppeln, oder Bibliotheken auf Lizenz pruefen will. Weiterhin ist fhemupdate.pl absichtlich starr, sprich man kann zwar ein Verzeichnis in SVN anlegen, aber das kriegen die Benutzer noch lange nicht per update.

Ich bin offen diesen Regel aufzuweichen, wenn dabei mein Bedenken beruecksichtigt wird.

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5642
absolut! Eventuell kommen ja auch noch Beiträge und Gedanken weiterer devs dazu.

Verstehe ich richtig:

- "fremd" bezieht sich auf Code "von anderen", hauptsächlich wegen möglicher Risiken mit Bezug auf die Lizenz. Aber auch um kein CPAN 2 aufzumachen.
- "eigene" Libs sind von den bestehen Regeln gedeckt wenn die im /FHEM Verzeichnis landen. (in /FHEM aber eben flat, keine sub dirs)

Über ein "nicht flat" (da geht's ja in die Richtung namespaces) könnte man reden, die Rules müssten festgelegt werden.

So richtig wiedergegeben ?


smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 596
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Wenn man ein Schreibzugriff aus SVN bekommt, kriegt man die:

Ok. Nichts darin verbietet, dass man zur Implementierung von Funktionalität X nicht mehr als 1 Modul verwenden darf.
Ich denke, damit wäre dieses "self-contained" erstmal abgehakt. Problematisch ist nur das kein Verzeichnis anlegen...

Ich habe da jetzt knapp zwei Stunden darüber sinniert und muss kleinlaut zugeben, dass mir eine richtig gute FHEM-kompatible Lösung nicht einfällt. Oder ich formuliere es mal um:

Wenn man sich HoBo anschaut, dann sieht man schon was ich mir als Ideale Lösung vorstelle:

Im root -Verzeichnis sind zwei Verzeichnisse lib und t dazugekommen. Ersteres soll Perl Module nach der regulären Nomenklatur (X::Y::Z = X/Y/Z.pm) enthalten, letzteres die zugehörigen Testfiles. Diese Vorgehensweise würde ich auch bei FHEM sehr stark ans Herz legen.

In lib tatsächlich nur Perl Module und nur nach o.g. Nomenklatur. Kein JavaScript, XML, .GZ und sonstiges Gedöns. (sowas gehört nach shared, data, resources oder so)

FHEM/lib werde ich entsprechend knicken, sobald ich die Gelegenheit dazu bekomme.

Mein Ziel ist, dass es mit der Zeit im FHEM Unterverzeichnis nur noch xx_Modulname.pm  main::-Interfaces (Hülsen sozusagen) gibt, die eigentlich nur ein use FHEM::MeinModul::Funktion qw(MeinModul_Init MeinModul_Define ...) machen, die Hauptlogik lebt aber unter lib/* und wird getestet von t/*



Tja ... aber das kann man alles machen, wenn man ne Installationsbasis von < 10 Diehards hat.  8)

Ich habe es mir auch noch einfacher gemacht und contrib erstmal gekillt. Folglich keine Ahnung wie man contrib vs. non-contrib handhaben könnte. Vermutlich müsste man ./lib & ./t nur für Modulautoren die ein FHEM/xx_Frontend.pm haben freigeben und für contrib Code sperren, womit man aber ggf. Contrib torpediert. Ist ein wenig Zweiklassengesellschaft, wofür ich keine guten Konzepte habe. Ich kann das nicht einmal mit staging/production abbilden.

Module unter ./lib anlegen würde ich nicht von "nach Rücksprache mit Nadelöhr" abhängig machen, sondern von "gemäß Nomenklatur/Hierarchie und announcement in <FHEM Forum/Development/Namespace>", aber der Modulautor macht einfach. Ähnlich wie PAUSE bei CPAN.



Auf jeden Fall, sollte das Ziel sein, dass ein Modulautor, der heute - Beispiel aus der Rippe geschnitten -

70_ONKYO_AVR.pm
71_ONKYO_AVR_ZONE.pm
ONKYOdb.pm


maintained, künftig folgendes nicht nur machen darf, sondern als "best practice" präsentiert bekommt:

* es gibt ein 70_ONKYO_AVR.pm modul, das ist aber nur ein <10-20 Zeilen Skelett

package main;

use Multimedia::AVR::ONKYO  qw(Init Define ...);

<ggf notify defs>

1;


* unter lib gibt es dann

lib/Multimedia/AVR/ONKYO.pm
lib/Multimedia/AVR/ONKYO/Zone.pm
lib/Multimedia/AVR/ONKYO/Db.pm


welche die eigentliche Codelogik in gekapselten Namespaces bereitstellen.  Ob man dann 71_ONKYO_AVR_ZONE.pm knickt oder nicht sei dahingestellt.



Gemäß FHEM Kulturgepflogenheiten ist das alles aber kein Muss. Wenn ein Autor/Maintainer alles im xx_Modulname.pm im main:: Namespace belassen will, belässt er es einfach dabei. Aber wer sein Modul auf ein höheres Level hieven will, kann das dann ja machen.

Beide Arten von Modulen können nebeneinander koexistieren. Mit der Zeit kommt vermutlich Darwin zu Wort.



Sprung in die ferne Zukunft, der Mars ist besiedelt, FHEM bei Version 97.1

Die Enkel des ONKYO Maintainers haben das nun auch gemacht, ebenso haben das die Enkel der YAMAHA_AVR und PONEER_AVR Modulmaintainer gemacht.
Nun kommen die Enkel von RichardCZ und behaupten man könne alles viel besser machen und knicken den verbleibenden Rest von xx_Frontend Modulen, bauen stattdessen ein dynamisches Laden von Modulen mit rekursivem Absiteg in die ./lib/* Hierarchie und machen z.B. ein abstraktes Modul

Multimedia/AVR.pm

was der werte User von FHEM 97.1 als AVR Device definiert und es ist ihm komplett wurst welches Gerät von welchem AVR Hersteller er hat.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22650
Zitat
So richtig wiedergegeben ?
Ja.

Ich haette gerne eine Loesung, was die Regeln per Code sicherstellt, ich will nicht taeglich schauen, dass jemand alles was fuer DateTime::Event::Sunrise benoetigt wird, eingecheckt hat und ausliefert.
Einchecken alleine ist nicht so schlimm: wenn es nicht ausgeliefert wurde, kann man es leicht entfernen.
Update kann keine Dateien (mehr) loeschen, nur verschieben, und selbst dabei habe ich ein schlechtes Bauchgefuehl.

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 596
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Ja.

Ich haette gerne eine Loesung, was die Regeln per Code sicherstellt, ich will nicht taeglich schauen, dass jemand alles was fuer DateTime::Event::Sunrise benoetigt wird, eingecheckt hat und ausliefert.

Ich hätte im Angebot:

* geradezu faschistische SVN pre-commit, post-commit und pre-vomit  ;) hooks. Aber ich bezweifle, dass die FHEM kulturkompatibel sind
* Die Möglichkeit für CI/CD Pipelines - https://gl.petatech.eu/root/HomeBot/pipelines (selber für HoBo noch nicht eingerichtet, aber das Werkzeug ist da)
https://docs.gitlab.com/ee/ci/introduction/

Sollte FHEM e.V. doch noch über eine self-hosted GitLab Infrastruktur nachdenken: https://www.turnkeylinux.org/gitlab
Läuft bei mir unter Proxmox, war in 30 Minuten eingerichtet. Updates seit Version 11 problemstlos.

Jaja - ich weiß - gestern erst noch von CVS auf SVN migriert und jetzt wieder so neumodisches Zeug.  ;)

Um auf das DateTime::Event::Sunrise zurückzukommen:

da gibt es natürlich ein

t/DateTime/Event/Sunrise/00_smoke.t

Das kann ein einfaches use auf das Modul machen.
und wenn das in so einer CI pipeline auf die Schnauze fliegt, kann man ja dem Modulautor um 2 Uhr früh via SMS Bescheid geben.


Zitat
Update kann keine Dateien (mehr) loeschen, nur verschieben, und selbst dabei habe ich ein schlechtes Bauchgefuehl.

Tja. Rollback is king. Statt:

my $destdir="/var/www/html/fhem.de";

eben

my $destdir="/var/www/html/fhem.de/active";

und unter /var/www/html/fhem.de sieht es eben aus wie

active -> 6.0
6.0
6.1
6.2

wenn einer putt ist, schaltet man zurück.

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5789
Ich brauche mal kurz einen Anstoß.
Wie kann man das PMD-CPD Analysetool aufrufen ?

Ein paar Stellen in meinen Modulen die ich diesbezüglich schon einige Zeit verbessern will kenne ich auch ohne das Ding,
aber nicht alle.

Grüße,
Heiko
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, SSChatBot, SSCal, DbLog/DbRep, Log2Syslog, SMAPortal, Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 596
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Ich brauche mal kurz einen Anstoß.
Wie kann man das PMD-CPD Analysetool aufrufen ?

Ein paar Stellen in meinen Modulen die ich diesbezüglich schon einige Zeit verbessern will kenne ich auch ohne das Ding,
aber nicht alle.

z.B.

/usr/bin/pmd-cpd --minimum-tokens 100 --files FHEM/ --language perl


im FHEM root-Verzeichnis. Dann geht er rekursiv alle "Module" in FHEM durch.

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5789
Danke für die Info Richard.
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, SSChatBot, SSCal, DbLog/DbRep, Log2Syslog, SMAPortal, Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

 

decade-submarginal