Suche Menschen die meinen C#-Code kritisieren!

Ich weiß dass ist nicht unbedingt Professionell aber mir hat Strg + Z/Y immer geholfen XD oft mache ich das solange bis der code wieder da ist, kopier mir was draus und mache mit Y alles wieder rückgängig ^^ das hat bei mir bis jetz immer gereicht. aber ich hatte auch noch keine großen gravierenden Team-projekte.
Vielleicht kannst du mir ja sagen wie man das mit Unity in Zusammenhang bringt.
Ich meine mit nem normalen Projekt ist es klar, das würde ich vielleicht sogar hinkriegen, auch wenn ich das GIT Desktop übel blöd finde, weil man da nichtmal ordner hat, wie beim Online-Portal, aber man kanns ja an VisualStudio koppeln...
Wenn man aber Unity hat kann man Unity nicht sagen "lad mal die Skripte vom GIT-Ordner" und GIT kann man leider auch nicht sagen "benutz einfach den unity Ordner" Ich hab dann mal versucht n Rep an demselben ort wie Unity ist zu erstellen... aber dann hat er natürlich ALLES erstmal geladen... 50k Änderungen ich dachte ich setz aus XD Und das blöde ist dass man dem auch nicht sagen kann "bitte benenne dich mal anders als den Ordner den du erstellst" und wenn ich mein Projekt nicht unbedingt Scripts nennen will, oder Assets, dann sieht das übel aus^^
Ich hab nen plugin für Unity versucht, das hat zumindest in Soweit funktioniert, dass es lokal irgendwie da war... aber beim commit hats dann angefangen die ladezeit war nichtmehr lustig, erstmal haufenweise fehler, und der Push hat dann gar nicht geklappt, dann kam irgendwann gar keine fehlermeldung mehr, online ist aber auch nicht aufgetaucht... irgendwann hatte ich einfach die schnauze voll XD

Also kA wie nützlich das Teil sonst ist aber in Punkto Benutzerfreundlichkeit kriegt das Teil von mir so viele 6en dass man daraus ein Haus bauen könnte. Den Rest gucke ich mir mal an aber ich wills nur so weit wissen wies später im Job auch nötig ist. Ich bin schließlich Programmierer und kein Projekt-Manager ^^ es würd mich tierisch aufregen wenn der Hauptteil meiner Arbeit nicht ist mir Algorithmen auszudenken sondern eher irgendwelche krankhaften Versionierungstools zum laufen zu bekommen.
 
Nochmal wegen dem Auszug aus der Equals Methode, hier geht es nicht um Performance (würde in diesem Fall sowieso vom Compiler "wegoptimiert"), sondern Lesbarkeit. Die If-Abfrage ist zu 100% überflüssig = 3 Zeilen nutzloser Code, der Wahrheitswert kann direkt zurückgegeben werden. Es handelt sich auch nicht um einen Fall eines "Einzeilers", der Wahrheitswert wurde vorher auf die gleiche Weise ermittelt...

Wie eine Equals-Methode zu implementieren ist (funktional), ist durch das Interface, welche diese Methode zum "überschreiben/überladen" bereitstellt, vorgeschrieben. Kann dir diesen Artikel empfehlen für C#:
https://docs.microsoft.com/en-us/do...ators/how-to-define-value-equality-for-a-type

Sehe bei mir keinerlei Leerzeilen für sogenannte Sinnabschnitte innerhalb Funktionen, wie auch bei Texten/Artikeln/Büchern erhöhen (sinnvolle) Absätze die Lesbarkeit.
 
Okayy... Also das mit den Leerzeil... oh Leerzeilen! ich les die ganze Zeit Leerzeichen und denke mir so: die hier? XD Und dachte du meinst die Codeeinrückung...
Aber jetzt bin ich neugierig: Leerzeilen? Wo wie dann warum macht man die denn? Sinnabschnitte? Absätze im Quellcode? das ist mir ja noch nie eingefallen :o
 
xD

z.B. eine Leerzeile, welche das hinzufügen eines Triggers zum YesButton vom hinzufügen eines Triggers zum NoButton trennt (ohne den Code weiter zu bewerten).
C#:
            ...
            EventTrigger.Entry entry = new EventTrigger.Entry();
            entry.eventID = EventTriggerType.PointerDown;
            entry.callback.AddListener((data) =>
            {
                initKoikoi = false;
                ((Player)Board.players[Turn ? 0 : 1]).Koikoi++;
                StartCoroutine(Global.KoikoiAnimation(() =>
                {
                    allowInput = true;
                    Turn = !Turn;
                    PlayMode = 1;
                }, Global.prefabCollection.KoikoiText));
                Destroy(Koikoi);
            });
            GameObject.Find("Koikoi/YesButton").GetComponent<EventTrigger>().triggers.Add(entry);

            entry = new EventTrigger.Entry();
            entry.eventID = EventTriggerType.PointerDown;
            entry.callback.AddListener((data) =>
            {
                initKoikoi = false;
                Global.players = Board.players.Cast<Player>().ToList();
                SceneManager.LoadScene("Finish");
            });
            GameObject.Find("Koikoi/NoButton").GetComponent<EventTrigger>().triggers.Add(entry);
            ...

Wüsste jetzt nicht wie ich dir dies erklären könnte, man trennt einfach Dinge welche nicht direkt im Zusammenhang miteinander stehen durch eine Leerzeile... Würde wahrscheinlich selbst in dieses Beispiel noch weitere Leerzeilen einfügen, allerdings müsste ich mich dann ggf. mit dem Code auseinandersetzen.
 
Ah verstehe... gut darauf bin ich echt noch nie gekommen...
Aber andererseits würde sich das vermutlich erübrigen wenn ich mehr Funktionen Abdocken würde hm? ^^

Oder halt statt leerzeichen Kommentieren, was ich auch öfter tun sollte XD
 
Kokujou schrieb:
Aber andererseits würde sich das vermutlich erübrigen wenn ich mehr Funktionen Abdocken würde hm? ^^
da solltest du eh drauf achten, da du dir damit duplicated code sparen kannst, aber vorallem dein Projekt leichter verstaendlich wird, vorausgesetzt du benennst deine Funktionen ordentlich :)
Denke es gibt auch CPDs (Copy Past Detectors) für C#, die genau nach solchen Code suchen. Gehört aber oft mit in dem Bereich CI.
 
Naja versteh mich nicht falsch doppelter Code ist quasi nicht vorhanden.
Aber es gibt komplizierte Beispiele wie das was du gepostet hast.
Das sieht z.B. sehr sehr ähnlich aus auf den erstne Blick... Aber wenn man genauer hinsieht...
Das was in der Delegatfunktion passiert ist total unterschiedlich, die Namen sind Unterschiedlich und was übrig bleibt wäre eine dreizeilige Funktion, die ne Delegatfunktion als Eingabe hätte, erklär mich für verrückt aber das klingt nicht wirklich sehr sinnvoll XD

ähnliches findet man in der ellenlangen Update-Funktion in der Main.cs, alles was ich hier tun kann ist ein paar Codeabschnitte in Funktionen Abdocken damit die eigentlich Update-Funktion nur sowas wie ein grober Plan ist und die Funktionen dann später definiert werden, also wirklich NUR zur Lesbarkeit und nicht zur Kürzung.

Anders formuliert meine Prioritäten sind so:
1. Alles was Performance- oder Speicherprobleme verursachen könnte
2. Dinge die meinen Code verkürzen könnten
3. "Elegantere" Lösungen die aber ähnlich viel Code brauchen (neuere UI-Systeme oder dergleichen)
6. Dinge die den Code "lesbarer machen" und vom allgemeinen Verständnis abweichen

und ja ich hab 4. und 5. nicht vergessen :P Und damit meine ich sowas wie, klar Variablen nicht xyz zu benennen das ist natürlich wichtig, sinnvolle Benennung darauf achte ich meist schon, auch wenn mir oft die Worte fehlen und ich deswegen den englischen und deutschen Wortschafts aufschöpfe XD
Und irgendwo seh ich auch ein dass Superklassen wie die Update-Routine verdammt schwer einsehbar sind.
Aber ich fange sicher nicht an meinen ganzen Code auf Groß- und Kleinschreibung zu testen XD oder ob Unterstrichte Richtig gesetzt sind, ob das Leerzeichen nachm Komma ist oder ob die Kommasetzung in den Kommentaren richtig ist XD oder ob ich für die Kommentare mal // und mal /* */ verwende
 
Kokujou schrieb:
Aber ich fange sicher nicht an meinen ganzen Code auf Groß- und Kleinschreibung zu testen XD oder ob Unterstrichte Richtig gesetzt sind, ob das Leerzeichen nachm Komma ist oder ob die Kommasetzung in den Kommentaren richtig ist XD oder ob ich für die Kommentare mal // und mal /* */ verwende
vielleicht solltest du das nochmal überdenken und
"6. Dinge die den Code "lesbarer machen" und vom allgemeinen Verständnis abweichen" eine höhere Priorität geben.
 
Ich versteh den Sinn dahinter einfach nicht. Ich meine so funktioniert das heute nichtmal mehr.
Ich hab meine ganzen Programmierkenntnisse nur durch IntelliSense erworben. Ich will was machen, schreibe was und kriege schon Vorschläge was für Funktionen ich dafür verwenden kann XD
Das letzte wonach ich dabei gucke ist "hmmm das ist groß geschrieben also ist es ne Funktion, oh das ist klein also ist es ne Variable" XD das sieht man doch meistens durch die Darstellung, sind diese Konventionen überhaupt noch aktuell? Immerhin übernimmt das doch die Entwicklungsumgebungen mit ihren unzähligen hilfsmitteln Codefärbungen und und und
 
S.Giny schrieb:
Ich bin zwar kein C# Entwickler, mir aber sehr sicher, dass der Compiler das intern ohnehin zum Einzeiler umwandelt
So ist es.
1543620448459.png
 
  • Gefällt mir
Reaktionen: Sgt_H4rtman
Cool^^ was ist das Reverse Engeneering? (das ist garantiert die falsche Vokabel...)
 
Kokujou schrieb:
Aber andererseits würde sich das vermutlich erübrigen wenn ich mehr Funktionen Abdocken würde hm? ^^

Ging nur um ein Beispiel für Leerzeilen ohne den Code zu bewerten.

Kokujou schrieb:
Oder halt statt leerzeichen Kommentieren, was ich auch öfter tun sollte XD

Im Gegenteil, wenn Inline Kommentare für das Verständnis deines Codes notwendig werden, spricht das für schlechten (unverständlichen) Code. "Summary" Kommentare für Funktionen, Klassen, etc. sollten i.d.R. ausreichend sein.

Kokujou schrieb:
Ich versteh den Sinn dahinter einfach nicht. Ich meine so funktioniert das heute nichtmal mehr.
Ich hab meine ganzen Programmierkenntnisse nur durch IntelliSense erworben. Ich will was machen, schreibe was und kriege schon Vorschläge was für Funktionen ich dafür verwenden kann XD
Das letzte wonach ich dabei gucke ist "hmmm das ist groß geschrieben also ist es ne Funktion, oh das ist klein also ist es ne Variable" XD das sieht man doch meistens durch die Darstellung, sind diese Konventionen überhaupt noch aktuell? Immerhin übernimmt das doch die Entwicklungsumgebungen mit ihren unzähligen hilfsmitteln Codefärbungen und und und

Ob das noch aktuell ist? Ja, und das wird es auch bleiben. Wenn du jemals in diesem Bereich arbeiten willst, wirst du nicht um Coding Style Guidelines herumkommen, ggf. solltest du dich mal mit statischer Code-Analyse auseinandersetzen wie es schon vorher im Thread erwähnt wurde (z.B. FxCop). Die Lesbarkeit deines Codes wird durch einen einheitlichen Stil erheblich verbessert. Gerade wenn mehrere Entwickler an einem Projekt arbeiten ist dies zwingend notwendig.
 
  • Gefällt mir
Reaktionen: CitroenDsVier
Das klingt unschön... aber wenn ich nicht drumrum komme muss es eben sein... Verstehen tu ich's immer noch nicht... Ich meine ob ich meine Methode jetzt groß oder klein schreibe... wie schon gesagt findet man doch am Ende eh alles durch intellisense, die Codefärbung erledigt dann den Rest, aber wenn die Welt denn drauf besteht^^

Aber kommen wir mal zurück zum Thema :3 Und zwar der Performance und Codekürzung und allem was ich auch als Relevant erachte, aber ja ihr habt Recht in den Rest arbeite ich mich auch ein.
 
Kokujou schrieb:
Das klingt unschön... aber wenn ich nicht drumrum komme muss es eben sein... Verstehen tu ich's immer noch nicht... Ich meine ob ich meine Methode jetzt groß oder klein schreibe... wie schon gesagt findet man doch am Ende eh alles durch intellisense, die Codefärbung erledigt dann den Rest, aber wenn die Welt denn drauf besteht^^

Man kann alles irgendwie finden wenn man lang genug sucht, allerdings findet man Dinge schneller wenn Ordnung herrscht. IntelliSense ist sehr praktisch wenn man die API noch nicht kennt, sobald man diese beherrscht, wird IntelliSense mehr und mehr überflüssig. Farben im Editor helfen auch, allerdings kann hier nur sehr limitiert differenziert werden, durch die Schreibweise kann diese Differenzierung wesentlich besser sichergestellt werden sodass Farben nur als Ergänzung dienen.

Ob du deine Methode groß oder klein schreibst hängt einfach vom verwendeten Coding Style ab. Wenn 2 Entwickler an einem Projekt arbeiten und der eine seine Methoden groß schreibt der andere klein, dann ist die Schreibweise nicht mehr geeignet für eine Differenzierung. Nun stell dir vor es sind 100 Entwickler und jeder hat eine andere Schreibweise, einmal PascalCase, einmal camelCase, einmal snake_case, einmal Kebab-Case, einmal sTudLycAPs (Witz), ... für die gleiche Art von Konstrukt (z.B. Methode), dann wird daraus sehr schnell sehr schwer lesbarer Code.

Je früher man sich das eintrichtert desto besser :)

Kokujou schrieb:
Aber kommen wir mal zurück zum Thema :3 Und zwar der Performance und Codekürzung und allem was ich auch als Relevant erachte, aber ja ihr habt Recht in den Rest arbeite ich mich auch ein.

Wenn ich du wäre würde ich als erstes Versuchen reine Logik von "Oberfläche" zu trennen und die Anzahl Zeilen pro Methode massiv zu verringern. OOP hilft hier sehr, kann dir diese Seite empfehlen bzgl. Design Patterns: https://www.dofactory.com/net/design-patterns

Allerdings solltest du nicht zwanghaft versuchen Design Patterns anzuwenden. Wann man welches Design Pattern anwendet, sollte sich aus dem gegebenen Problem ergeben (es sollte offensichtlich sein). Hierfür benötigst du allerdings erst das Verständnis wie diese Design Patterns aufgebaut sind.

Sobald du mehr Struktur in deinem Code hast (z.B. durch OOP), hast du einen besseren Überblick und kannst dich mit "Performance Optimierungen" auseinandersetzen.

/edit:
Einen anderen Tip den ich dir noch nahelegen möchte:
Verwende kein Strg+C/V! Solltest du wirklich die Notwendigkeit haben etwas Kopieren zu müssen, dann schreib es ab!
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: CitroenDsVier
Okay... hatte eben schon einen recht langen Text geschrieben, den verwerfe ich aber mal um dir eventuell mehr zu helfen. Ich beziehe mich dabei nur auf diese eine Aussage von dir:
Kokujou schrieb:
Ich versteh den Sinn dahinter einfach nicht. Ich meine so funktioniert das heute nichtmal mehr.
Ich hab meine ganzen Programmierkenntnisse nur durch IntelliSense erworben. Ich will was machen, schreibe was und kriege schon Vorschläge was für Funktionen ich dafür verwenden kann XD
Das letzte wonach ich dabei gucke ist "hmmm das ist groß geschrieben also ist es ne Funktion, oh das ist klein also ist es ne Variable" XD das sieht man doch meistens durch die Darstellung, sind diese Konventionen überhaupt noch aktuell? Immerhin übernimmt das doch die Entwicklungsumgebungen mit ihren unzähligen hilfsmitteln Codefärbungen und und und

Du möchtest von uns, dass wir deinen Code kritisieren. Das machen wir. Wir sagen dir wo bei deinem Code das größte Problem liegt. Dieses Problem interessiert dich allerdings nicht. Doch um die Probleme zu lösen, die dich interessieren, muss erstmal dieses eine beseitigt werden.
Daher die folgende Erklärung. Sie behandelt etwas technisches Wissen, ein wenig Geschichte, etwas über Programmieren aber besonders eine Begründung weshalb wir es uns erlauben können schönen Code zu produzieren..

C# ist eine sogenannte High Level Programming Language. Das sind Programmiersprachen die dafür entwickelt wurden dass man verständlich programmieren kann und nicht die ganzen Abtraktionen und die Kmplexität von Maschienensprachen hat. Und warum? Nicht weil Programmierer dumm sind, sondern wenn überhaupt weil wir faul sind! Wir wollen uns das leben nicht unnötig schwer machen und erst recht nicht für ein und das selbe Problem 1.000 unterschiedliche Lösungen haben. Eines dieser Probleme ist z. B. die Speicherverwaltung. Wir wollen nicht jedesmal den Speicher händisch freigeben, stattdessen möchten wir sagen "Lösch die Referenz Nummer X von den Daten Y!" und sobald diese Daten keine Referenzen mehr hat, soll sie automatisch gelöscht werden. Wir wollen uns nicht merken in welchen Adressen diese Daten sich befinden und uns auch nicht merken wie viele Referenzen es für die Daten gibt. Aus dem Grund haben faule Leute angefangen gute Lösungen für diese Art von Problemen zu entwickeln und stellten sie der Allgemeinheit bereit. Somit konnten sich andere Leute auf andere Probleme konzentrieren und bessere Lösungen finden. Und eine High Level Programming Language ist eine solche Lösung. Bei C# handelt es sich um eine solche Sprache. Sie erlaubt es dir mit sehr wenig Wissen über Maschienensprache etwas zu entwickeln, was eine Maschiene versteht. Damit das überhaupt möglich ist gibt es den Compiler. Er kümmert sich darum die Sprachen zu übersetzen und weil er weiss, dass wir faul sind führt er auch gewisse Optimierungen durch.

Doch wie führt uns das zu einen guten Codestyle? Ganz einfach. durch diesen Luxus, den uns High Level Programming Languages geben können wir uns darauf konzentrieren, dass der Code den wir schreiben für Menschen verständlich ist. Erst bei sehr kritischen Fällen müssen wir uns damit beschäftigen was der Compiler nicht für uns geschaft hat.

Gut lesbar ist der Code dann, wenn er einheitlich ist, eine übersichtliche Struktur hat und wir uns kleine Teile rauspicken können, mit denen wir uns beim lesen beschäftigen.
Dadurch wird der Code verständlich und wir können nachvollziehen was dort passiert.
Wenn wir jetzt noch durch Kommentare oder aussagekräftigen Methodennamen sagen, was in einem dieser kleinen Teile passieren soll, dann können wir sogar überprüfen ob im Code das steht, was gemeint ist. Anders: Wenn wir verstehen was der Code macht und wir wissen was er tuen soll, dann können wir sagen ob er das auch macht was er soll- wir können logische Fehler finden.

Auf dieser Grundlage, also sauberen Code, können wir mit entsprechenden Wissen auch überprüfen ob Performanceprobleme vorliegen oder ob alle Operationen notwendig sind.

Auch beim Kollaborieren gibt es dadurch Vorteile. Wird von jedem Code geschrieben, den alle verstehen, dann kann man auch über die Arbeit disktuiren. Und aus dem Grund werden Style Guides verwendet. Es sind Regeln die dafür sorgen dass jeder das versteht was der andere Schreibt, vergleichbar mit Dialekten. Um so weiter ein Style Guide verbreitet ist, destso besser, denn dann kann man auch Leute bei Problemen um Hilfe bitten, mit denen man sonst nicht zusammen arbeitet.
Außerdem erleichterst du es dir Code zu verstehen der älter als 12h ist. Und zwar richtig zu verstehen und nicht nur zu wissen was er in etwa machen soll.

Doch welcher Entwickler möchte sich über Groß- und Kleinschreibung Gedanken machen? Über Rechtschreibfehler? Oder geschweige denn über Leerzeichen! Denn dafür müssten wir uns das alles auch erstmal merken. Wäre es nicht schön, wenn es Programme gäbe, das sich um sowas kümmeren? Aber was rede ich denn da! Sowas gibt es und wird auch sehr umfangreich eingesetzt.

Abschließend zu dem Thema "Gut lesbarer Code" möchte ich noch hervorheben, das gut lesbarer Code und und performanter Code koexistent sein können. Das verdanken wir u. A. dem Compiler, da wir uns nur für ihn an eine gewisse Grammatik halten müssen.
Bitte frag dich, weshalb dir mehrere erfahrene Entwickler raten deinen Fokus zu ändern :)
(Bei mir sind es nun mehr als 4 Jahre in denen ich professionell Software entwickele und warte. Davor ca. 5 Jahre privat, mit vielen kleinen eigenen Projekten und ein paar in einem größeren Team. Zusätzlich die Beteiligung an ein paar OS Projekten die ich sebst genutzt habe.)

Thema IDE und ihre Features: Du selbst hast bereits angesprochen, dass die IDE vieles übernimmt. Dass stimmt! Doch das macht nicht komplett eigenständig. Manche Aktionen, wie den Code zu formattieren, da musst du der IDE sagen, dass sie es machen soll (und wie).
IntelliSense soll dir helfen Typos zu verhindern und eine übersicht über die API zuerhalten. Nicht aber um schlechten Code nutzbar zu machen. Es gibt auch viele Entwickler die ab und an Tools wie vi/vim nutzen. Und zwar reiwillig. Es zeigt einen wie schön es ist, mit einer IDE zu arbeiten aber es hilft einen auch besser und verständlicher zu programmieren.

Morgen (oder heute abend) folgt noch eine Anmerkung zu deinem Code.

(Stell dir den Text mal vor, wenn ich keine Absätze in diesem Text drinne gehabt hätte. Hättest du ihn dann auch so gemütlich lesen können? Oder wäre dir der Einstieg nach einem Schluck trinken so leicht gefallen?)
 
Zuletzt bearbeitet: (Typo und eine kleine Zusammenfassung)
  • Gefällt mir
Reaktionen: im5cv, CitroenDsVier, Sgt_H4rtman und 3 andere
Also von hinten anfangend: Mit Text bist du bei mir an der falschen Adresse denn der war für mich so attraktiv wie eine riesige Wall of Text XD Aber ich muss grad reden denn ich schreibe ja selbst ganze A4 Seiten wenn ich mich in ein Thema verbeiße... aber jetzt reißen wir uns mal zusammen, eine A4 Seite krieg ich ja gerade so noch auf die reihe...

Okay ich habs ja verstanden... Aber ehrlich gesagt so schlimm find ich meinen Code gar nicht. Ich hab mir jetzt mal ReSharper drauf geschafft (Für Studenten umsonst, yeii~) und mal sehen wie das funktioniert sobald ich wieder dran sitze, denn mein Studium liebt es mich von meiner wichtigen und sinnvollen Arbeit mit unwichtigen und sinnlosen Hausaufgaben abzulenken...

Meine größte Schwäche ist dass ich bei größeren Wall of Texts direkt Blackouts kriege, egal wie schön sie strukturiert sind. Dasselbe bei Vorlesungen. Wenn mich Menschen "zuschwallen" ohne dass bei mir eine Mitarbeit vorausgesetzt wird, also Themenverträglich wenn bei mir nur die Festplatte nicht aber der Prozessor bemüht wird (;)) dann wars das. Ratet was bei meinem Studium der fall ist :'( Aber da bin ich mal wieder ein Einzelfall

Nach wie vor finde ich meinen Code sehr gut lesbar...
Das einzige was ich jetzt nicht so gut finde, so vom objektivem Draufgucken ist die Update-Routine in der Main.cs, achja und die Cards.cs überspringt ihr bitte XD da hab ich noch gar nichts gemacht ich bin mir nichtmal sicher ob die noch benutzt wird, würde ich eher anzweifeln. Die ist ein schönes Beispiel wie stark man sich doch innerhalb eines Projektes verbessern kann :)

Ansonsten hab ich jetzt schon Klassen abgedockt, Funktionen abgedockt, Sammlungsklassen für Prefabs und Variablen entwickelt was ich übrigens wirklich schrecklich finde aber... sagt mir was besseres XD die alte IMGUI durch die eingebaute Komponenten-UI ersetzt (Unity-Insider^^), Hier und da hab ich sogar Kommentiert ^^ Es ist vielleicht design-technisch nicht optimal aber es ist nicht schwer sich da reinzulesen finde ich zumindest...

Achja diese Design-Pattern sehe ich mir mal an... Was wirklich hilfreich wäre wenn ihr mir helfen würdet diese Singletons loszuwerden... generell soll man statische Variablen ja sogut wie nie verwenden weil das angeblich dem Prinzip der OOP widerspricht... Aber in dem zusammenhang ist mir nichts besseres eingefallen. kA ob ich es schonmal erklärt habe aber das ist ein Unity-Problem. Wegen dem Networking muss ich die Main.cs per Script zur Szene hinzufügen, das bedeutet aber auch dass ich die Variablen wie Prefabs nicht im Inspektor zuweisen kann. Ergo muss ich eine weitere Klasse nehmen die von Anfang an da ist und dann auf diese Zugreifen ohne dass deren Variablen dabei überschrieben werden. Und das geht meines Wissens nach nur über statische Variablen. Nun kann ich aber nichtmal das tun denn statische Variablen werden im Inspektor nicht angezeigt und darum der Singleton. Ich rede von Variable/PrefabCollection
 
Kokujou schrieb:
Was wirklich hilfreich wäre wenn ihr mir helfen würdet diese Singletons loszuwerden...

Dann lies dich mal ein in Dependency Injection, das wäre die direkte Lösung für dieses Problem... Ist meiner Meinung nach aber nicht unbedingt das größte Problem, solltest dich erst mal auf die Trennung UI und Logik konzentrieren.

Kokujou schrieb:
Nach wie vor finde ICH meinen Code sehr gut lesbar...

Da liegt das Problem und glaub mir, in 1-2 Jahren wirst du deinen eigenen Code nicht mehr lessen können...
 
  • Gefällt mir
Reaktionen: Crast
Ich hab mich ja um die Sicht eines objektiven Außenstehers bemüht. Als ich meine Bachelorarbeit geschrieben hab hab ich doch tatsächlich mal meine Mutter an den Code gesetzt XD die hat nicht nru von programmierung 0 Ahnung sondern auch von Computern allgemein. Und ich sag mal so... es hat funktioniert XD

Dependency Injektion... Also ich bin weniger ein Freund von Wall of Texts und mehr von prägnanten und zusammengefassten Erklärungen oder Beispielen also überflogen...
heißt das einfach nur dass ich die Variablen quasi zusammenfassen soll und dann als Variable einer Funktion übergeben soll. Gut das wäre eventuell möglich... Ist jetzt auch nicht wirklich der eleganteste Weg aber hey... Das könnte ich auf dem Spawn-Skript machen... müsste dann allerdings der funktion irgendwie mitteilen, dass ich das getan habe, da ja n Update-Callback läuft, dass diese Infos braucht.

Wisst ihr vielleicht wie das ist? ich kenn mich da nicht aus also folgendes:
Das Spawn Skript instanziiert die Klasse, läuft die dann schon? oder gehts mit dem Code erst weiter wenn die aktive Funktion des Spawn-Skripts beendet ist? ich meine das ist n minimaler Unterschied aber ich erinnere mich daran mit ähnlichen Vorgehensweisen schonmal Probleme gehabt zu haben.
 
Darf ich mal fragen was du studierst? Kommt mir irgendwie seltsam vor.
 
  • Gefällt mir
Reaktionen: I'm unknown und Crast
Zurück
Oben