RFC: Reduzierung der Präprozessor-Nutzung

[fschrempf]

@biologist

Sehe ich ehrlich gesagt anders: Das war alles schön eingerückt. Und zwar genau aus dem Grund. Da haben hier einige die Nase gerümpft und gemeint, dass das unüblich sei, Präprozessor-Anweisungen gleichermaßen einzurücken. Dann musste Clang her und jetzt ist es halt „so halb“ eingerückt.

Mal ganz ehrlich, egal wie der Code formatiert ist gibt es durch den Mix aus normalem Code, den der Compiler interpretiert und Präprozessor-Code, den der Präprozessor interpretiert eine erhebliche Verschlechterung der Lesbarkeit.

Mir persönlich fällt es einfach sehr schwer Code zu lesen, der ständig von Blöcken unterbrochen wird, die nur bedingt compiliert werden und ich weiß, dass das anderen auch so geht weshalb es allgemein als schlechter Stil gilt, wenn man unnötig den Präprozessor strapaziert. Wenn das bei dir anders ist, ist das ja schön aber das steht halt einfach im Gegensatz zur allgemein vorherrschenden Meinung unter Entwicklern.

Siehe z. B. auch:

• c++ - Why are preprocessor macros evil and what are the alternatives? - Stack Overflow
• c# - Quote needed: Preprocessor usage is bad OO practice - Stack Overflow

@biologist

Also mir ist unklar, wo genau das Problem liegt, wenn einem VSC mit entsprechender Kolorierung sogar anzeigt, was gerade greift und was nicht.

Das Syntax-Highlighting zeigt mir vielleicht welcher Block mit meiner aktuellen Config aktiv ist, aber das verhindert eben nicht, dass man die Auswirkungen von Änderungen auf inaktive Blöcke gerne übersieht bzw. nicht einmal compile-testet.

@biologist

Das Problem ist halt, dass ESPuino inzwischen Unmengen an Kombinationsmöglichkeiten hat, die keiner testet.

Genau! Und man kann die Kombinationen in der Config auch kaum testen, weil es eine Vielzahl von Abhängigkeiten zwischen den einzelnen Config-Optionen gibt, die nirgends abgebildet sind. Das heißt man muss im Voraus irgendwoher wissen oder aufwendig recherchieren wie die Optionen zusammenhängen. Genau da kommt Kconfig wieder ins Spiel. Dort werden die Abhängigkeiten zwischen den Optionen abgebildet und berücksichtigt. Das geht theoretisch so weit, dass man Compile-Tests mit einer randomisierten Config machen kann um sicherzustellen, dass alle Kombinationen zumindest korrekt compilieren.

@biologist

Inzwischen bin ich davon abgekommen und beäuge jeden Feature-Request erstmal kritisch und hinterfrage, ob das überhaupt nennenswert genutzt wird.

Das ist sicher eine gute und sinnvolle Strategie.

@biologist

aber da muss halt wieder zusätzlicher Kram installiert werden, der die initiale Einrichtung noch aufwändiger macht, als sie jetzt eh schon ist.

Nein, eben nicht. Wir verwenden mittlerweile das Buildsystem des esp-idf SDKs. Das verwendet bereits Kconfig für die Konfiguration des SDKs und alle Abhängigkeiten sind bereits vorhanden. Dort würden sich die ESPuino-spezifischen Optionen einfach einfügen lassen.

@biologist

Was ich sagen will: Mitnichten zieht ESPuino nur irgendwelche Nerds an und daher sind viele Änderungen und Notwendigkeiten vielen Usern gar nicht klar. Ihr dürft auf keinen Fall erwarten, dass hier sonderlich viele User ständig am Ball bleiben.

Auch wenn das Handling mit den settings-Files schon irgendwie „raw“ ist, bieten sie ja doch eine halbwegs gute Übersicht (aufgrund der ganzen Kommentare und Beschreibungen) und wenn man ein Jahr später nochmal ein Update macht und sich diese Files aufgehoben hat, dann ist da, finde ich, auch ein gewisses Maß an Nachvollziehbarkeit gegeben.

Das sehe ich anders. Ja, wir wollen die Schwelle für nicht Software-affine Leute senken und ja, das Handling der Settings-Header ist sehr „raw“ und m. E. für diesen Personenkreis eben gerade nicht geeignet. Aber diese Diskussion gehört jetzt wieder ganz klar in Konfiguration via Kconfig und hat wenig mit dem eigentlichen Thema hier zu tun.