Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsValve: Quelltext von CS:GO illegal auf GitHub veröffentlicht
Nein. Der Lizenznehmer bzw. Kunde hat das nicht zu entscheiden. Der einzige der das entscheidet ist wer das Geld für die Entwicklung stellt (Auftraggeber) und selbst da kann der Entwickler noch nein sagen oder der Entwickler selber.
Ich wiederhole mich: es gibt nicht zwingend einen Auftraggeber. Und Geldgeber ist dann der Kunde. Das widerspricht deiner Aussage damit in keinster Weise. Und wenn der Kunde sich dann mit dem Portemonnaie zwischen zwei Optionen entscheidet, beeinflusst er sehr wohl die Lizenz. Nur ist er, wie ich auch schon gesagt habe, hier oft nicht zu einer informierten Entscheidung faehig. Das aendert aber an der Sache nichts.
new Account() schrieb:
Überhaupt nicht vergleichbar mit einem neuen Spiel.
Du sitzt immer noch dem Irrglauben auf, dass bei einer Distribution das Geld zweckgebunden ist. Das ist aber nirgends der Fall. Eine RHEL Lizenz finanziert die Entwicklung des Kernels, GNOME und etlicher apps, SystemD, dbus, PulseAudio, NetworkManager, JBoss, Ansible, CEPH, LibreOffice, und etlicher weiterer Projekte.
Genauso wie ein Fortnite Skin die Weiterentwicklung der UE4 mitfinanziert oder eine CS Box Half Life Alyx. Die Zweckbindung, die du suggerierst, gibt es einfach nicht.
Wieso soll das sogenannte "geistige Eigentum" eines Maschinenbauingenieurs oder was auch immer mehr Wert haben als das eines Softwareentwicklers? Voelliger Unfug und diskriminierend obendrein. Das Patentwesen ist in jeder Branche gleich schaedlich und obendrein nutzlos, solange man die Durchsetzung nicht erzwingen kann, also fuer immer.
Der Grund ist, dass du mit Kommentaren das Wissen an mehreren Stellen ablegst, einmal im Code und einmal als Kommentar, was bedeutet, dass du deine Kommentare jedes mal anpassen musst, wenn der Code sich ändert, was, wie du dir vielleicht vorstellen kannst, nicht immer gemacht wird.
Im schlimmsten Fall habe ich jetzt veraltete Kommentare über Code, der eigentlich auch selbst Preis geben könnte, was da passiert, wenn der Entwickler sich ein bisschen mehr Mühe gegeben hätte...
Der Grund ist, dass du mit Kommentaren das Wissen an mehreren Stellen ablegst, einmal im Code und einmal als Kommentar, was bedeutet, dass du deine Kommentare jedes mal anpassen musst, wenn der Code sich ändert, was, wie du dir vielleicht vorstellen kannst, nicht immer gemacht wird.
Nicht korrekt. Der Kommentar muss nicht JEDES mal angepasst werden. Mehr s.u.
Dass es nicht immer gemacht wird, trifft auf vieles zu, das die technische Schulden erhöht.
Slurpee schrieb:
Im schlimmsten Fall habe ich jetzt veraltete Kommentare über Code, der eigentlich auch selbst preis geben könnte, was da passiert, wenn der Entwickler sich mehr Mühe gegeben hätte...
Das stimmt einfach nicht.
Ein Vorschlag: Code beschreibt was gemacht wird, Kommentare warum - als generelle RICHTLINIE.
Dein Vorschlag geht schon deswegen nicht, weil man das warum z.B. nicht in Funktionsnamen packen kann.
Beispiel:
Ich habe eine Klasse, welche Methoden hat.
Die Klasse wird (DRY) in verschiedenen Situationen eingesetzt. Dementsprechend gibt es für die Verwendung der Methoden der Klasse unterschiedliche Gründe.
Ich habe nun die SItuation, dass in zwei Situationen die Gründe nicht klar sind. Deswegen möchte ich das irgendwie im Code vermerken.
Du sagst nun, ich solle es im Funktionsnamen/Methodennamen machen.
Folgende Möglichkeiten bestünden:
in der Klasse zwei zusätzliche Methoden (mit entsprechender Erklärung im Namen) hinzufügen, welche die eigentlich einzusetzende Methode aufrufen: Schlechter wie ein Kommentar, da verwirrend und mehr Aufwand als einfach ein Kommentar. Zusätzlich ist das häufig einfach nicht möglich, da man nicht der Autor der Klasse ist. Auch dürfte es das Kompilat verschlechtern; auch wieder zwei Stellen zum Ändern des Codes
Abwandlungen von oben: z.B. für jede Methode eine Kopie der Klasse erstellen.
den Methodenaufruf in eine separate Funktion packen mit der Erklärung im Funktionsnamen -> meist Performanceoverhead; auch wieder zwei Stellen, wo man etwas ändern muss
Macros/Aliasse nutzen, falls vorhanden -> Äquivalent zu einem Kommentar - mit zusätzlichen Nachteilen
Über jede Verwendung einen Kommentar drüber packen - die Lösung könnte so einfach sein
Witzig wie es bei allen Clean-Code-Empfehlungen immer Leute gibt, welche es ins Extreme treiben müssen, und vergessen was überhaupt der Sinn hinter den Empfehlungen ist.
Fürs coden gibt es leider bis heute noch nicht DAS Rezept.
Wie bist du eigentlich auf diesen Trichter gekommen?
Ergänzung ()
flmr schrieb:
Du sitzt immer noch dem Irrglauben auf, dass bei einer Distribution das Geld zweckgebunden ist. Das ist aber nirgends der Fall. Eine RHEL Lizenz finanziert die Entwicklung des Kernels, GNOME und etlicher apps, SystemD, dbus, PulseAudio, NetworkManager, JBoss, Ansible, CEPH, LibreOffice, und etlicher weiterer Projekte.
Nein, sitze ich nicht.
Im Gegenteil: Mir war das schon vor dem Post bewusst.
Das dürften übrigens alles Tools sein, die für den Support relevant sind.
flmr schrieb:
Genauso wie ein Fortnite Skin die Weiterentwicklung der UE4 mitfinanziert oder eine CS Box Half Life Alyx. Die Zweckbindung, die du suggerierst, gibt es einfach nicht.
Ich kann dir jetzt schon sagen, dass keiner ein monatliches Abo für Jahre für "nichts" abschließen wird, bzw. bezahlen wird, wenn er das Spiel auch so einfach spielen könnte (und nach 1 Woche durchgespielt hat).
Spieler haben ganz andere Interessen/Anforderungen, wenn sie auf der einen Seite einen Supportvertrag an ne Distro zahlen und auf der anderen Seite ein Spiel kaufen, das sie durchspielen können.
Bei Fortnite zahlen die Spieler auch nur für anderes mit, weil sie unbedingt die Skins haben möchten, und nicht, weil sie UE4(was auch immer das ist) finanzieren möchten.
Da wo es Sinn macht, gibt es bereits weiterführende (und auch zweckorientierte) Zahlungen:
WoW -> Abo fürs ewig weiterzocken
Skins/Ingame-Währung kaufen/sonstige -> ewig weiterzocken mit F2P Option
DLCs -> für mehr Content ein bisschen mehr zahlen (hier wird ggf. auch der Nachfolger teilfinanziert)
keine Extras -> man zahlt nur das Spiel, ggf. kommen Bugfixes raus (Man hat ja eigentlich auch einen Anspruch darauf, dass das Produkt funktioniert)
Wenn du mit s.u. das "warum" meinst, dann hast du eben doch unrecht.
Falls sich das Verhalten einer Methode ändert hat dies meist auch einen Grund (das "warum").
Wenn du beides im Code hast, musst du beides Pflegen. Ich kenne vielen Legacy Code wo der Code was anderes macht als es das Kommentar vorgibt, weil eben die Pflege nur am Code passiert. Deswegen die "Clean Code" Richtlinien.
Und keiner sagt, dass es gar keine Kommentare geben soll. Doch wenn Möglich soll der Code sich selbst erklären.
Wenn du weiter über das Thema "Clean Code" von Uncle Bob diskutieren willst, dann mache doch bitte inen Thread im "Programmieren" Unterforum auf. Bin gerne dabei darüber zu streiten. Erwähne im Eingangsposting einfach alle hier
Wäre also nicht schlecht, wenn man die Möglichkeit dafür auf ein Minimum reduziert, meinst du nicht?
Das stimmt einfach nicht.
Ein Vorschlag: Code beschreibt was gemacht wird, Kommentare warum - als generelle RICHTLINIE.
Dein Vorschlag geht schon deswegen nicht, weil man das warum z.B. nicht in Funktionsnamen packen kann.
Warum du etwas tust, ist IN einer Methode eine der wenigen Ausnahmen, bei denen ich einen Kommentar akzeptieren würde und auch nur, wenn du dieses etwas nicht sinnvoll in eine Methode auslagern kannst. Der Grund für den Aufruf der Methode selbst sollte wiederum aus dem Zusammenhang der aufrufenden Methode erkennbar sein.
Beispiel:
Ich habe eine Klasse, welche Methoden hat.
Die Klasse wird (DRY) in verschiedenen Situationen eingesetzt. Dementsprechend gibt es für die Verwendung der Methoden der Klasse unterschiedliche Gründe.
Da musst du jetzt aber schon ein konkreteres Beispiel bringen. Wenn du eine Klasse aus zwei unterschiedlichen Gründen nutzt, die sich so stark voneinander unterscheiden, dass der Name der Klasse/Methoden nicht mehr passt, hast du direkt gegen das Single Responsibility Prinzip verstoßen.
Aus welchem Grund ich die Methode aufrufe, muss von außen vollkommen irrelevant sein, dass ist ja grade der Witz an der ganzen Aktion.
Beispiel:
File.ReadAllText() liest eine Textdatei in einen string ein, was aus Millionen verschiedenen Gründen passieren kann. Wenn du den Aufruf allerdings in der Methode LoadConfiguration() siehst, dürfte es klar sein, da brauch ich doch kein
// Read Configuration file as string
über dem Aufruf...
Witzig wie es bei allen Clean-Code-Empfehlungen immer Leute gibt, welche es ins Extreme treiben müssen, und vergessen was überhaupt der Sinn hinter den Empfehlungen ist.
Fürs coden gibt es leider bis heute noch nicht DAS Rezept.
Clean Code kommt sehr nah ran. Das Problem ist, dass die wenigstens sich genug damit beschäftigt haben, um es wirklich zu beherrschen. Sie kommen dann an einen Punkt, an dem das Verständnis aufhört und dabei Mist raus kommt. Ergo: Clean Code funktioniert nicht.
Ist das selbe mit Objektorientierung. Es gibt Leute, die kapieren es einfach nicht und programmieren prozedural, ohne es zu merken und wenn man sie darauf hinweist, ist OOP unsinnig, nicht praxistauglich etc. pp
Wie bist du eigentlich auf diesen Trichter gekommen?
Berufserfahrung. Ist auch echt nicht böse gemeint, ich hab mich damit auch lange schwer getan und nicht alles verstanden. Aber je länger man sich damit beschäftigt, desto mehr wird einem klar, dass das Problem nicht CC, sondern das mangelnde Verständnis dessen und die darauf folgende falsche Verwendung war...
Ein weiterer User:
// implicitly fires two actions
count+=2
(jeweils Instanzen von "Integer")
Slurpee schrieb:
Da musst du jetzt aber schon ein konkreteres Beispiel bringen. Wenn du eine Klasse aus zwei unterschiedlichen Gründen nutzt, die sich so stark voneinander unterscheiden, dass der Name der Klasse/Methoden nicht mehr passt, hast du direkt gegen das Single Responsibility Prinzip verstoßen.
Aus welchem Grund ich die Methode aufrufe, muss von außen vollkommen irrelevant sein, dass ist ja grade der Witz an der ganzen Aktion.
Beispiel:
File.ReadAllText() liest eine Textdatei in einen string ein, was aus Millionen verschiedenen Gründen passieren kann. Wenn du den Aufruf allerdings in der Methode LoadConfiguration() siehst, dürfte es klar sein, da brauch ich doch kein
Weil es auch zwei unterschiedliche Domänen in spezifischen Kontexten sind.
1) Robotik, wo bestimmte Positionen von Gelenken Singularitäten haben können. Durch die Addition von 1 vermindert man das Problem.
2) irgendetwas anderes, wo Aktionen gezählt werden - und zwei Zeilen vorher wurde eine Methode ausgeführt, welche als zwei Aktionen gezählt werden
Die "+2" ist schonmal richtig schlecht wegen hardcodings. Sollte irgendwo definiert sein, auch wenn es nur eine Konstante ist.
Man könnte es auch ganz anders lösen aber anhand einens so kleinen Beispiels schwer. Ist ja nur ein Statement von dir.
Deine Beispiele zeigen mir, dass du evtl doch mal einen Blick in "Clean Code" werfen solltest.
Da fängt das Problem doch schon an. Warum kein eigener Datentyp? Stichwort primitive obsession, Unterschied zwischen einem Objekt und einer Datenstruktur (Wird im Clean Code erklärt).
Mal ganz davon abgesehen, ist wohl nichts leichter, als einen integer increment in eine sinnvoll benannte Methode zu packen, wie #basTi schon geschrieben hat...
Bei deinem Beispiel bist du richtig. In deinem Beispiel beschreibt der Kommentar aber auch nicht das warum.
Mein Beispiel: s.o.
Ist es nicht, wenn es inherent die 2 ist, und die 2 durch die 2-3 vorherigen Methoden bestimmt wird.
Die Alternative wäre die Konstante direkt eine Zeile vorher zu definieren (sogar mti einem entsprechenden Variablen Namen). Das stimmt, macht es aber nicht inherent schlechter als einen Kommentar (dürfte aufs selbe rauslaufen).
Häh? Was hat ein struct "velocity" (Oder was auch immer dein int sein soll), der einen int enhält mit DRY oder Bugs zu tun? Irgendwie schmeißt du grad bloss mit Buzzwords um dich.
Und ich habe gesagt, dass Integer hier der falsche Datentyp ist. Wenn dein integer eine velocity beschreibt, und velocity ein fester Teil deiner Applikation ist, ist es standard, die Daten und dazugehöriges Verhalten(Wie man z.b. die Singularität abwendet) in einen eigenen Datentyp auszulagern.
Warum sollte man das machen?
Statt einen Kommentar schreibe ich jetzt gleich ein struct?
Mit mehreren Methoden, damit ich auch noch Zugriff auf den normalen Wert habe und bei einer speziellen Nutzung dann den modifizierten?
Slurpee schrieb:
Genau wie diejenigen, die Clean Code nicht verstanden haben, es angeblich immer besser wissen...
Sagt der Typ, der wahrscheinlich keinen einzigen commit durch unser review kriegen würde...
Warum sollte man das machen?
Statt einen Kommentar schreibe ich jetzt gleich ein struct?
Mit mehreren Methoden, damit ich auch noch Zugriff auf den normalen Wert habe und bei einer speziellen Nutzung dann den modifizierten?
Das du überhaupt noch zusätzlich über direkten Zugriff sprichst, sagt mir genug. Entweder, du hast etwas, das komplex genug ist, um einen eigenen Typen mit Verhalten zu schreiben(Objekt), oder es ist so trivial, dass ich keinen Kommentar für einen einfach Inkrement brauche(Datenstruktur). Und wenn es komplex genug ist, gibt es keinen direkten Zugriff, absolutes no go, lernt man auch wieder im CC.
Und du weißt es natürlich für allen Code auf der Welt besser.
Oder wie soll ich das verstehen?
Entweder, du hast etwas, das komplex genug ist, um einen eigenen Typen mit Verhalten zu schreiben(Objekt), oder es ist so trivial, dass ich keinen Kommentar für einen einfach Inkrement brauche(Datenstruktur)...
