Hauptmenü

[FHZ] FHEM Standards

Begonnen von Martin Fischer, 29 Januar 2010, 15:33:11

Vorheriges Thema - Nächstes Thema

Martin Fischer

hallo andy..

Am Mittwoch 03 Februar 2010 schrieb Andy Fuchs:
> [...]
>
> Nunja... ich hatte ja meinen Senf zur Semantik des Codes vor einer Weile
> hier gepostet. Ebenso, wie ich mit meinen Änderungen zum FileLog verfahren
> sollte. Da hat sich niemand geregt, weshalb ich von einer erwünschten
> 'Fremdbeteiligung' bisher nicht ausgegangen bin. Deshalb hielt ich diesen
> Thread bislang mehr für eine 'interne' Diskussion.

bei weitem: nein! endlich ist das eis gebrochen ;-) und das bei den
temperaturen..

> [...]
> Grundsätzlich vertrete ich diesen Standpunkt:
>
> -  Alles GROSS geschrieben halte ich für etwas fragwürdig, ich würde
>  Klassen mit einem Grossbuchstaben beginnen und dann Camel-Case
>  weiterschreiben. - Variablen, Pointers klein beginnen und dann Camel-Case.
> - GLOBALE gross (meinetwegen auch Konstanten)
> - Weiterhin würde ich Daten vom Code trennen.
> - :UI und :TMP haben in fhem.pl m.E. nix verloren, hierfür könnte man
> Adapter schaffen
> - dto. für :MSG (dazu gibt's ja ein Log)
> - Attribute und Properties, sowie die sporadisch auftretenden STATEs könnte
> man vielleicht so organisieren, dass sie abstrakter nutzbar sind. (Im
>  Moment ist mir in einigen Bereichen die Kategorisierung dieser Werte
>  ohnehin nicht so ganz klar - kann aber auch an mangelndem fhem-Verständnis
>  meinerseits liegen)

ich bin da dicht bei dir. du steigst allerdings schon tiefer auf quelltext
ebene ein was die schreibweise angeht. ich wär schon froh, wenn wir erstmal
eine regel für die inhalte hinbekämen, die mittels "list" dargestellt wird und
dann natürlich "empfehlungen" für den quelltext zu definieren.

ein schönes beispiel ist in meinen augen:
http://pear.php.net/manual/de/standards.php

dies ist nur ein beispiel von vielen. es ist ja nicht so, das wir die ersten
sind die sich darüber gedanken machen. vielleicht kann man ja auch gewisse
sachen einfach übernehmen und viele diskussionen sparen.

> Viel schlimmer bei der Betrachtung des Codes ist für meine Augen aber die
> Lesbarkeit des Codes. Die Variablennamen sind nicht 'sprechend',
>  ebensowenig wie viele Funktionsaufrufe. Inline-Kommentare/Doku vermisse
>  ich ebenso schmerzlich. Dies sind für mich - als potentieller Mithelfer -
>  die größten Hürden. Eine gemeinsame Semantik innerhalb der Module würde
>  den Einstieg für Non-fhem-Profis deutlich erleichtern...

ja, da schliess ich mich ein, das auch mein code nicht immer sauber
dokumentiert ist. zumindest habe ich meist camel-case eingesetzt :-) aber mit
den inline kommentaren war ich auch eher sparsam ;-)

gruss martin

--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
--
Admin, Developer, Gründungsmitglied des FHEM e.V.