Icon Ressource

Ressource Deuglyfying C/C++, Teil 1 : Der Projektstart

Lowl3v3l

Mitglied
devCommunity-Experte
Lowl3v3l erstellte eine neue Ressource:

Deuglyfying C/C++, Teil 1 : Der Projektstart - Dieser Text führt anhand von 10 Fragen zum erfolgreichen Start eines C/C++-Projektes.

In diesem HowTo werden 9 für den Aufbau von Open-Source-Projekten in C/C++ essentielle Fragen gestellt, und jeweils in der Erfahrung sinnvolle Antworten auf diese oft übersehenen Designentscheidungen gegeben, die in Kombination zu einem guten Projektdesign führen und viele Inkonsistenzen und Fehler von vorn herein ausschließen können.

Es handelt sich hierbei natürlich um eine von Vorurteilen und dem Ethos, gute Programme schreiben zu wollen, gefärbte Perspektive, die keinen Anspruch auf...
Erfahre mehr über diese Ressource...
 

german

Aktives Mitglied
devCommunity-Experte
Verfügt ein Projekt nicht über eine Lizenzangabe so gilt der rechliche Normalfall : "All rights reserved", der jedem anderen jede Nutzung des Codes verbietet.
In dem Zusammenhang frage ich mich gerade welcher rechtliche Normalfall hier im Forum gilt? Wenn wir mal ein paar Zeilen posten um Hilfestellung zu geben, dann gehen wir doch automatisch davon aus, dass das ggf. per Copypasta übernommen wird. Also eher Public Domain statt eine in irgendeiner Form restriktive Lizenz. Hmm...
 

LimDul79

Neues Mitglied
In dem Zusammenhang frage ich mich gerade welcher rechtliche Normalfall hier im Forum gilt? Wenn wir mal ein paar Zeilen posten um Hilfestellung zu geben, dann gehen wir doch automatisch davon aus, dass das ggf. per Copypasta übernommen wird. Also eher Public Domain statt eine in irgendeiner Form restriktive Lizenz. Hmm...
Frage ist zum einen, ob das was gepostet wird genug Schöpfungshöhe hat, um geschützt zu sein - zum anderen könnte man sowas in den Nutzungsbedingungen des Forums vermutlich lösen.
 
  • Like
Reaktionen: Mat

Lowl3v3l

Mitglied
devCommunity-Experte
Ich bin kein!!! Anwalt, aber soweit ich weiß, gibt es da erstmal große Probleme mit dem Mangel an Präzedenzurteilen. Es ist ja noch nicht einmal klar, ob eine einzelne zentrale Lizenzdatei im Projekt reicht, daher mache ich es grundsätzlich so, die Lizenz auch in jeder Datei zu haben um ganz sicher zu sein was(soweit ich das sagen kann!) aber vermutlich ein Overkill ist. Generell ist denke ich eine Sache das grundsätzliche "wo kein Kläger da kein richter", davon dass man das mal eben einfach so per Nutzungsbedingungen macht würde ich abraten, da sollte man vorher einen guten Anwalt drüber sehen lassen wenn man das plant, ob das statthaft ist und man sich nicht irgendwelche Nebenwirkungen eintritt.

Die Frage worauf es defaultet weiß ich nicht, aber meine Vermutung ist auch da "all rights reserved", schließlich könnte man auch bei GitHub argumentieren, dass damit die Drittverwendung in Kauf genommen wird, aber dennoch ist da der Default das normale Copyright.
 

Lowl3v3l

Mitglied
devCommunity-Experte
Ob das reicht ist leider nicht so klar. Ich empfehle, falls du da eine Lizenz suchst, was in die Richtung CC-0 oder WTFPL :)
 

german

Aktives Mitglied
devCommunity-Experte
Ja, CC-0 ist auch in Deutschland anerkannt und wird dort wo es möglich ist automatisch als Public Domain gewertet. Hab das mal so geschrieben. Wenn's vielleicht auch nichts nützen sollte, schaden tut es nicht ;)
 

JR Cologne

Administrator
Teammitglied
Frage ist zum einen, ob das was gepostet wird genug Schöpfungshöhe hat, um geschützt zu sein - zum anderen könnte man sowas in den Nutzungsbedingungen des Forums vermutlich lösen.
Genau, das Urheberrecht gilt natürlich grundsätzlich überall, wo Werke geschaffen werden, die in irgendeiner Weise eine gewisse Schöpfungshöhe vorweisen können und den Kriterien des Urheberrechtsschutzes gerecht werden. In diesem Sinne gilt das selbstverständlich auch für dieses Forum.
Der Standard ist demnach auch hier, dass alle Rechte beim Urheber liegen.

@german
Das bloße Kopieren und Übernehmen deines als Teil eines Beitrags veröffentlichten Codes ist, zumindest in einigen Fällen, vermutlich auch ohne Lizenz und bei einer entsprechenden Schöpfungshöhe gestattet, weil es in Deutschland erlaubt ist, im privaten Kontext urheberrechtlich geschützte Werke zu vervielfältigen (Privatkopie).

Aber ihr habt natürlich auch genauso recht damit: Wo kein Urheber ist, der sich irgendwie beschwert oder von einer Urheberrechtsverletzung Kenntnis nimmt, da folgt meist auch keine rechtliche Konsequenz - selbst, wenn massiv gegen das Urheberrecht verstoßen wird.
Und wenn es dann doch mal zu Klagen kommt, ist es auch nicht immer so leicht, den Sachverhalt zu beurteilen und entsprechend ein Urteil zu fällen.
Insbesondere bei Code und Software kann man sich da lange drüber streiten, was urheberrechtlich relevant ist, wer überhaupt der rechtmäßige, ursprüngliche Urheber ist, usw...
 

german

Aktives Mitglied
devCommunity-Experte
Somit ist meine Profilnachricht als Beruhigung für diejenigen zu verstehen, die sich unsicher sind, ob sie ein Problem mit mir bekommen könnten ... ;)
 

Mat

Mitglied
Weiterhin sollten zu jedem Projekt noch Dateien gehören, die die Verwendung von Tools bestimmen(und im Regelfall im Wurzelverzeichnis des Projektes liegen sollten, wie die Konfigurationsdateien für CI, Buildsystem oder static analyzer) und solche, die der Projektbeschreibung für Menschen dienen.
Wie steht ihr zu Config-Dateien für IDEs / Editoren im Repo? Also zum Beispiel ein .vscode-Ordner, VS-Mappe (*.sln), Docker-Dateien oder IntelliJ-Projekteinstellungen.

Ich hab da unterschiedliche Meinungen zu gehört. Von 2 hab ich sogar gesagt bekommen, dass sie reinen IDE- und Toolagnostischen Code bevorzugen (ggf. mit Buildanleitungen in einer Doku oder woanders). Ich find das etwas extrem und puristisch, aber ich kann schon ein bisschen nachvollziehen, wenn man keinen Bock auf die vielen Mülldateien hat.

Ich finde, ein Projekt sollte direkt aus einem Clone heraus direkt in gängigen IDEs funktionieren und gebaut werden können. Teilweise sind dafür Tool-Konfigurationsdateien oder Skripte erforderlich. Dazu würde ich auch bestimmte IDE-Einstellungen zählen (im Grunde alles, was nicht abhängig ist vom Rechner des Entwicklers - Ausnahmen sind sowas wie Architekturen und SDK-Versionen).

Leider scheinen viele IDEs diverse Userspezifische Dateien zu erstellen und auch immer wieder Einstellungen mit absoluten Ordnerpfaden. Und wenn man dann die Git-Versionierung aktiviert, muss den ganzen Müll per Hand ignorieren. Es gibt zwar gute ignore-Vorlagen, aber die lassen in der Regel immer noch viele userspezifische Konfigurationsdateien zu. Bei Intellij Java wird zum Beispiel der JDK-Name in einer Config-Datei gespeichert. Der JDK-Name ist frei wählbar. :rolleyes: Und Visual Studio war ja auch immer sehr speziell mit Mülldateien.. wobei das etwas besser geworden ist.

Auch automatisch generierte Dateien sollten meiner Meinung nach komplett raus bleiben (ich sehe immer wieder, wie Leute die kompilierten Binärdateien mit reinpacken oder bei Java den *.class-bytecode). Bei generierte Dokus oder Dateien, die für Releases / automatisch verlinkte Downloads benötigt werden, würde ich noch beide Augen zudrücken.
 

dominik

Mitglied
@Mat: Ich committe Dateien, die für die allgemeine Nutzung konzipiert sind (Skripte, .editorconfig, docker-compose.yml) und setze solche in die Gitignore, die Arbeitsplatz-spezifisch sind (.idea).

Generierten Code und Build-Artefakte committe ich gar nicht*, weil dadurch Inkonsistenzen entstehen können. Was passiert, wenn ein Entwickler den Code ändert und dann vergisst, den Build neu durchzuführen?

*Ausnahme sind generierte Protobuf-Stubs in Go, weil die als Abhängigkeit heruntergeladen werden müssen.
 

Lowl3v3l

Mitglied
devCommunity-Experte
Grundsätzlich bin ich nur für config-Dateien, wenn sie für den Buildprozess selbst erforderlich sind, und dann sollten sie so allgemein wie möglich sein. Solche für IDE's und Editoren -> Nein. Für nen Code-Formatter : Ja. Wenn die Dateien ohne Probleme generiert werden können erst recht nicht(Ich würde zum Beispiel nie ein von CMake generiertes Makefile ins Repo packen).
IDE-Dateien oder so rein zu werfen ist einfach ganz grundsätzlich schlechter Stil, das ist auch afaik gemeinhin anerkannt.
Zu dem "es sollte gleich funktionieren" : jede gängige IDE unterstützt die meisten gängigen Buildsysteme, so daß ein Import komplett banal ist.
 

Mat

Mitglied
Build-Artefakte committe ich gar nicht [...] Was passiert, wenn ein Entwickler den Code ändert und dann vergisst, den Build neu durchzuführen?
Guter Punkt, das sollte vielleicht über Releases oder notfalls eine Build Pipeline geregelt werden, die das Artefakt nach jedem Versionsupdate generiert und woanders hinterlegt.

Solche für IDE's und Editoren -> Nein. [...] Zu dem "es sollte gleich funktionieren" : jede gängige IDE unterstützt die meisten gängigen Buildsysteme, so daß ein Import komplett banal ist.
Haha, Visual Studio lässt grüßen :p
(zumindest meine Erfahrung damit)
 

Lowl3v3l

Mitglied
devCommunity-Experte
Also zumindest mein Visual Studio 2019 kann NMake, CMake, für Linux-Projekte GNU-Make und ich glaube mit ein paar Tricks auch Ninja und SCons. Das ist eigentlich ziemlich viel. Andererseits, wenn man blöd genug ist, dieses Monstrum zu benutzen kann ich leider nur sagen : "Lernen durch Schmerz".
 

Lowl3v3l

Mitglied
devCommunity-Experte
Ich sollte das vielleicht präzisieren, damit man mir nicht einseitigen Microsoft-Hass vorwirft : so denke ich über ausnahmslos JEDE C/C++-IDE die ich je gesehen habe. Ich bin bereit über diese Dinger zu diskutieren, wenn jemand es schafft, eine zu bauen, die mit weniger als 5 GB Ram und 5 GB Festplattenspeicher wenigstens so viel kann, wie mein Emacs ;)
 

german

Aktives Mitglied
devCommunity-Experte
Persönlich möchte ich die Annehmlichkeiten einer IDE nicht missen. Aber du hast natürlich Recht. Als Kompromiss nutze ich immer noch Code::Blocks. Das macht selbst mit gcc, Lib und Toolchain noch einen Schlanken Fuß mit ~1 MB. Trage ich immer auf Stick mit mir rum. Aber für Windows-spezifische Dinge bin ich bislang nicht um Visual Studio herum gekommen. Habe ich allerdings auch auf die externe SSD ausgelagert.
 

Lowl3v3l

Mitglied
devCommunity-Experte
Naja, ich habe in meinem Emacs ALLE Annehmlichkeiten, von denen mir je ein IDE-Benutzer vorgeschwärmt hat, und noch einen Haufen mehr^^
 

LimDul79

Neues Mitglied
Wie steht ihr zu Config-Dateien für IDEs / Editoren im Repo? Also zum Beispiel ein .vscode-Ordner, VS-Mappe (*.sln), Docker-Dateien oder IntelliJ-Projekteinstellungen.
Ich komme rein aus der Java-Welt. Ich hab da eine klare Meinung "Kommt drauf an".

Im beruflichen Kontext: Wenn eine IDE vorgeben ist, dann gehören auch die IDE-spezifischen Dinge mit rein. Denn dann ist sichergestellt, dass z.B. Codeformatter etc. bei allen gleich arbeiten. Wenn man auch noch den Installationsort auf der Platte vorgeben kann, sind auch ardkodierte Pfade kein Riesen-Problem (aber trotzdem scheiße)

Wenn ich ein Open-Source Projekt machen würde, was viele Leute nutzen und entwickeln sollen, dann würde ich ich auf die IDE-spezifischen Dinge verzichten, weil ich da niemanden Vorgaben machen will, welche IDE er zu nutzen hat und wie er sie zu konfigurieren hat.
 
Oben Unten