• Mitspieler gesucht? Du willst dich locker mit der Community austauschen? Schau gerne auf unserem ComputerBase Discord vorbei!

News Valve: Quelltext von CS:GO illegal auf GitHub veröffentlicht

Cool Master schrieb:
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.

Na wenn du das sagst :rolleyes:

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.

Cool Master schrieb:
Hab das mal für dich angepasst ;)

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.
 
Zuletzt bearbeitet:
MR2007 schrieb:
[...]ohne viel (unnötigen) Spaghetti OOP[...]

Häh? :confused_alt:

Cool Master schrieb:
Der Code ist Clean. Ohne Kommentare bei so einem Projekt zu arbeiten wäre Selbstmord.

Schließt sich gegenseitig aus.

new Account() schrieb:
Finds ich nicht, bzw. widersprichst du dir ein bisschen selbst
Kommentare: warum? -> Sinn erklärend
Code: was?

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...
 
Slurpee schrieb:
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)
 
Zuletzt bearbeitet:
new Account() schrieb:
Nicht korrekt. Der Kommentar muss nicht JEDES mal angepasst werden. Mehr s.u.
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 :)
 
  • Gefällt mir
Reaktionen: Slurpee
new Account() schrieb:
Dass es nicht immer gemacht wird, trifft auf vieles zu, das die technische Schulden erhöht.

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...
 
Zuletzt bearbeitet:
Slurpee schrieb:
Wäre also nicht schlecht, wenn man die Möglichkeit dafür auf ein Minimum reduziert, meinst du nicht?
Natürlich. Deswegen gibts auch keine unnötigen Kommentare und kein Kommentarverbot.


#basTi schrieb:
Falls sich das Verhalten einer Methode ändert hat dies meist auch einen Grund (das "warum").
Ich beziehe mich mal auf mein Beispiel.

Ein user:
// mitigate Singularity
velocity+=1


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

// Read Configuration file as string

über dem Aufruf...
Bei deinem Beispiel bist du richtig. In deinem Beispiel beschreibt der Kommentar aber auch nicht das warum.
Mein Beispiel: s.o.

Slurpee schrieb:
Das sagen auch die, die schlechte oder zu wenig haben, oder einfach nicht reflektieren.
 
new Account() schrieb:
Ich beziehe mich mal auf mein Beispiel.

Ein user:
// mitigate Singularity
velocity+=1


Ein weiterer User:
// implicitly fires two actions
count+=2

(jeweils Instanzen von "Integer")
Ich verstehe deinen Code nichtmal mit Kommentar.

Was du aber machen könntest (ohne den Code zu verstehn):

method mitigateSingularity {
velocity+=1;
}
 
#basTi schrieb:
Ich verstehe deinen Code nichtmal mit Kommentar.
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
 
new Account() schrieb:
1) Robotik, wo bestimmte Positionen von Gelenken Singularitäten haben können. Durch die Addition von 1 vermindert man das Problem.
Siehe meinen Edit. Viel selbsterkärender und auch einfacher für zukünftige Änderungen.

new Account() schrieb:
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.
 
  • Gefällt mir
Reaktionen: Slurpee
new Account() schrieb:
Natürlich. Deswegen gibts auch keine unnötigen Kommentare und kein Kommentarverbot.

Versuchst du mich absichtlich falsch zu verstehen? Die Aussage hat jedenfalls nichts mit dem von mir Gesagtem zu tun...

(jeweils Instanzen von "Integer")

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.

Natürlich, das File wird gelesen, weil da die Konfiguration drin ist.


Das sagen auch die, die schlechte oder zu wenig haben, oder einfach nicht reflektieren.

Genau wie diejenigen, die Clean Code nicht verstanden haben, es angeblich immer besser wissen...
 
#basTi schrieb:
method mitigateSingularity {
velocity+=1;
}
Inwiefern ist das besser wie ein Kommentar?
Es erhöht unnötig die Komplexität und stört Lokalität.

#basTi schrieb:
Die "+2" ist schonmal richtig schlecht wegen hardcodings. Sollte irgendwo definiert sein, auch wenn es nur eine Konstante ist.
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).


Slurpee schrieb:
Warum kein eigener Datentyp?
DRY, Bugs vermeiden, Kosten - nicht jede Applikation braucht ihren eigenen Integer Datentyp.

Slurpee schrieb:
Natürlich, das File wird gelesen, weil da die Konfiguration drin ist.
Trivial ersichtlich -> warum ein Kommentar?
 
new Account() schrieb:
DRY, Bugs vermeiden, Kosten - nicht jede Applikation braucht ihren eigenen Integer Datentyp.

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.


Trivial ersichtlich -> warum ein Kommentar?

Und jetzt rate mal, was das Ziel von Clean Code ist...
 
Slurpee schrieb:
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?
Ich habe geschrieben es ist vom Typ "Integer"...
Slurpee schrieb:
Und jetzt rate mal, was das Ziel von Clean Code ist...
nicht alles ist trivial ersichtlich oder ohne andere Nachteile trivial ersichtlich zu machen
 
new Account() schrieb:
Ich habe geschrieben es ist vom Typ "Integer"...

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.

nicht alles ist trivial ersichtlich

Wenn man es entsprechend verpackt, schon.
 
Slurpee schrieb:
Wenn dein integer eine velocity beschreibt, und velocity ein fester Teil deiner Applikation ist, ist es standard,
Standard bei euch !=> gut
Slurpee schrieb:
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...
Und du weißt es natürlich für allen Code auf der Welt besser.
Oder wie soll ich das verstehen?
 
new Account() schrieb:
Standard bei euch !=> gut

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?

Ich erkenne schlechten Code, wenn ich ihn sehe und du wärst auch nicht der erste, der schlechten Code durch "technische Notwendigkeit" erklärt...
 
Slurpee schrieb:
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)...
weder noch
Slurpee schrieb:
Sagt der Typ, der wahrscheinlich keinen einzigen commit durch unser review kriegen würde...
Danke fürs Kompliment.
 
Zurück
Oben