RPG Game verschlüsseln

[TwoFace]

Wenn "v1, v2, v3 etc." für diese Leute Bezeichnungen mit genug Wiedererkennungswert sind, sodass sie auch nach 3+ Tagen noch was damit anfangen können, dann ist das doch gut und alles passt. Genauso kenn ich Mathematiker, die im Kopf 6823779498 Rechenschritte überspringen, während sie dir etwas, das für sie selbstverständlich ist, vermeintlich auf dein Niveau runtergebrochen, zu erklären versuchen, und im Endeffekt peilst du gar nix. Kommt also immer auf den Menschen an. Wenn ein Programmierer, der Geld für seinen Job bekommt, seinen eigenen Code nicht mehr blickt, dann ist das in erster Linie peinlich.

[Corti]

Und das meinte ich mit "jetzt kommt Superbrain....", denn mit dem Argument kannst du alles auskontern, prinzipiell kannst du bei jeglicher Form von Tipp oder Ratschlag sagen "es gibt aber Leute, die müssen das nicht" und wenn jetzt jemand seine Variablen v1, Horst und Pimmelnase nennt ist das ganz toll, weil es für genau denjenigen sicherlich perfekt ist, unkritisierbar. Die Annahme, dass jeder von uns ein individuelles schneeflockiges Superbrain sei, ist aber unfug. Es birngt nichts Inkompetenz in Sinne der Hypertoleranz aktzeptabel zu diskutieren.

Es gibt Sachen, die werden aus einem Grund gemacht, z.B. so zu coden, dass es leicht lesbar ist. Und "leicht" nicht im Sinne von "für einen individuellen Grenzfall" wodurch "sh2ngg11" wieder zur perfekten Benennung für eine Variable werden würde, sondern allgemeingültiger. Bei Programmierneulingen ists oft so, dass kein Bock, kein Verständnis dafür da ist warum man nicht "hin••••••••n, hauptsache läuft irgendwie" arbeiten sollte. Jetzt kommt TwoFace, du würdest sagen "hey, wenn das genau für dich richtig ist, dann mach das so", das ist schön. Damit kann jeder für sich sagen "egal welche Eigenart, die von Fachleuten sind 150 Jahren für dumm erklärt wurde ich auch habe, sie ist perfekt, ich sollte genau so bleiben.", Unwissenheit, Faulheit, alles perfekt gerechfertigt durch Hypertoleranz.

Ding ist: v3, blablubb, t4b sind für keinen Menschen auf der Welt bessere Variahblennamen als itemCount, cursorPosition und <Skills>StackPointer. Man kann die schlechteren Namen in Kauf nehmen wenn man der Meinung ist, davon mehr zu haben. Zeitersparnis verglichen mit dem Ausschreiben, oder "och nöö kein Bock die richtig zu benennen", was auch immer. Hier viel Zeit zu sparen ist ein Irrglaube, vielfach erwiesen, allgemein bekannt, einfach weil korrektes Bennenen wirklich minimalst Zeit kostet. Und auch wenn es Leute gibt, die mit "Blablubb, blablub und blubbbla" als Namen arbeiten können, es gibt niemanden(ich lehne mich aus dem Fenster), der damit besser arbeiten kann als mit richtigen Namen, die etwas aussagen.

[Rusk]

Was ich jetzt schon hassen werde: ich komme zu einem neuen Arbeitsplatz und muss an einem Programm weiterschreiben, bei dem der vorheriger Entwickler sich nicht die Mühe gemacht hat, vernünftige Variablennamen zu vergeben (von Kommentaren ganz zu schweigen).
Besser kann es ja nicht beginnen.

[TwoFace]

Ist ja was ich sage. Es muss für denjenigen, der es entwickelt perfekt sein. Ob wer anders durchpeilt ist doch übertrieben egal. Mit "Superbrain" hat das nichts zu tun. Nur damit, dass man das, was man fabriziert, auch im nachhinein noch nachvollziehen können sollte. Und das tut schließlich jeder auf seine Art.

Jetzt gibts ja aber auch Leute, die ihre Varis und Switches extra so benennen, dass der Code an sich für andere schwer nachvollziehbar wird und dann wird auch evtl. der ganze Code entsprechend auf der Basis aufgebaut. "Leicht lesbar"ist für jeden was anderes. Was für dich total simpel ist könnte für mich der komplizierteste Shit ever sein, genauso umgekehrt. Die perfekte Definition für "leicht" gibt es also nicht. Nur eine Annäherung an "leicht verständlich", wobei sich das dann auch wieder von Mensch zu Mensch und von Denkweise zu Denkweise unterscheidet. Dein Hirn ist schließlich nicht genauso vernetzt wie das von jedem anderen, der mit dem Maker arbeitet. Deine Kritik an "Hypertoleranz" ist genau dann berechtigt, dass, wenn jemand seinen Code irgendwie macht, er dann nicht funktioniert und der Entwickler selbst nicht einmal mehr in der Lage ist, nachzuvollziehen, woran das überhaupt liegt.

Beim Maker gibts kein richtig und falsch. Nur ein "funktioniert wie ich will" und ein "funktioniert nicht wie ich will".

[MagicMaker]

Es muss für denjenigen, der es entwickelt perfekt sein.

...

Undzwar auf möglichst langem Zeitraum, ist keine leichte Angelegenheit, wenn die Events auch mal über ein paar
kurze Zeilen oder nur sehr einfache Befehle ohne komplizierten Zusammenhang zueinander hinausgehen.

Also ich hab ja stellenweise selbst mit annährend vorhandener Struktur und vielen Notizen erhebliche Probleme,
nach ein paar Wochen selber noch zu verstehen, was ich da eigentlich zusammengezimmert hab. Das kann sehr
aufhaltend sein, wenn später Bugs auftauchen, von denen man vorher nichts bemerkt hat und partout die Ursache
nicht auftreiben kann, da sitz ich jetzt auch schon lange fest.

[Corti]

Also ich hab ja stellenweise selbst mit annährend vorhandener Struktur und vielen Notizen erhebliche Probleme,
nach ein paar Wochen selber noch zu verstehen, was ich da eigentlich zusammengezimmert hab.

...

Und das ist nichts was einem peinlich sein sollte. Es sich selbst einfacher machen in der Zukunft wieder durchzusteigen heisst nicht "omg, das hieße ja ich bin unfähig, coole Progranmmierer brauchen das nicht", stattdessen zeugt es von Verstand sich Notizen zurückzulassen.

[TwoFace]

Bugs kann man aber locker eingrenzen. Testplay: Was passiert / was läuft falsch? Woran könnts demzufolge liegen? Keine Ahnung? Mal auf F9 draufklatschen, schaun was für Werte die Varis haben und welche Switches ON / OFF sind. Rückschlüsse ziehen. Immer noch keine Ahnung? Eventcode durchchecken von vorne bis hinten. Ablauf wiederholen.

Klappt bei mir immer relativ gut. Auch wenn ich denk, dass ich den Fehler eh nicht find, irgendwann find ich ihn dann schon. ^^

[WeTa]

Bugs kann man aber locker eingrenzen. Testplay: Was passiert / was läuft falsch? Woran könnts demzufolge liegen? Keine Ahnung? Mal auf F9 draufklatschen, schaun was für Werte die Varis haben und welche Switches ON / OFF sind. Rückschlüsse ziehen. Immer noch keine Ahnung? Eventcode durchchecken von vorne bis hinten. Ablauf wiederholen.

Klappt bei mir immer relativ gut. Auch wenn ich denk, dass ich den Fehler eh nicht find, irgendwann find ich ihn dann schon. ^^

...

[Thuin8]

Bugs kann man aber locker eingrenzen. Testplay: Was passiert / was läuft falsch? Woran könnts demzufolge liegen? Keine Ahnung? Mal auf F9 draufklatschen, schaun was für Werte die Varis haben und welche Switches ON / OFF sind. Rückschlüsse ziehen. Immer noch keine Ahnung? Eventcode durchchecken von vorne bis hinten. Ablauf wiederholen.

Klappt bei mir immer relativ gut. Auch wenn ich denk, dass ich den Fehler eh nicht find, irgendwann find ich ihn dann schon. ^^

...

Auch wenn das beim Maker vielleicht unwahrscheinlicher ist als bei größeren Applikationen, die nicht auf dem Maker entwickelt werden: es kann auch mal sein, dass man einen Bug erst spät entdeckt, weil er vielleicht von komplett anderen Switches und Variablen hervorgerufen wird, als man anfangs meinen mag. Und da ist es dann auch schön, wenn man den Code noch Monate später ideal lesen kann und nicht mehr überlegen muss welche Variabel was bedeutet.

Ich persönlich finde es zum Beispiel schon sehr ärgerlich, dass Variablennamen in der Länge sehr stark begrenzt sind. Ich muss da oft deutlich mehr kürzen als ich eigentlich gerne würde. Eventuell könnte man dadurch entgegenwirken, wenn man bestimmte Gruppierungen in den Variablen benennen könnte, aber auch das ist ja leider nicht möglich.

Ich bin da also insgesamt sehr nah bei Cortis Meinung: Code sollte möglichst gut strukturiert sein, möglich gut kommentiert werden und die oberste Devise ist, dass der Code auch gut zu lesen ist. Ansonsten wird man irgendwann Probleme bekommen, wenn man mal eine Programmierpause einlegt und dann erst nach Wochen oder gar Monaten wieder vor diesen Codezeilen sitzt und nicht mehr weiß, warum man jetzt genau diesen einen Befehl mit eingebaut hat, der möglicherweise in der Form irgendein bis dahin unbekanntes Problem verursacht.

[TwoFace]

Und da ist es dann auch schön, wenn man den Code noch Monate später ideal lesen kann und nicht mehr überlegen muss welche Variabel was bedeutet

...

Ist ja auch richtig so. Sagt ja niemand, dass man es sich schwieriger machen muss als nötig. Ich sagte ja auch nur, dass der Code für einen selber möglichst leicht nachvollziehbar sein sollte und nicht allgemein für jeden anderen, der das Spiel im Maker öffnet.

[Thuin8]

Ist ja auch richtig so. Sagt ja niemand, dass man es sich schwieriger machen muss als nötig. Ich sagte ja auch nur, dass der Code für einen selber möglichst leicht nachvollziehbar sein sollte und nicht allgemein für jeden anderen, der das Spiel im Maker öffnet.

...

Die Aussage mag für Projekte, die man allein entwickelt noch halbwegs zutreffen. Auch auch da wären wir dann beim Superbrain. Du kannst mir nicht wirklich weißmachen, dass der "normale" Programmierer sich mehrere hundert kryptische Variablennamen, die keine eindeutige und sofort erfassbare Bezeichnung haben, über Monate hinweg merken kann.

[Corti]

Er hat schon nicht ganz Unrecht was das Individuelle angeht. Kryptisch ist für niemandem einfacher. Aber es gibt andere Sachen wie zB m_ für Member, g_ für Global, eigene Sachen, die einige Leute geil und andere scheisse finden. Man kann zB jeder Variable [0234] HeroCursorSlot die Nummer des CEs vorschreiben in der sie verwendet wird. Einige findens praktisch, andere findens nervig weil da dann so viel Zeugs im Namen steht. Ich z.B. setze als Prefix immer "< Systemname > Variablenname", zB "< Talente > Ausgewählter Held" weils eine für mich angenehme Mischung aus Datentrennung durch Syntax und lockere Lesbarkeit darstellt, aber das ist eben Geschmackssache.

Trotzdem, wenn auch nicht für jeden optimal, ist meine Syntax imo für jedermann gut lesbar. Ich finde auch nicht, dass da so ein gravierender Unterschied ist zwischen "für mich perfekt" und "für alle gut" wenn man sich nicht grade selbst anlügt. Wenn die Namen unkryptische Informationen enthalten ist das schonmal gut. Gleiche Bennenungsstruktur überall ist auch gut, für wen solls gut und besser sein wenn sich das Benennungsmuster stetig ändert?

Blablubb ist nur behindert.

[Rusk]

Ihr vergleicht Programmieren mit Makern.

[Owly]

@Deamonic: Anwendungsentwicklung funktioniert immer nach denselben Prinzipien.

[Corti]

Maker ist wie Assembler zum Klicken ;-)

[The_Burrito]

Wenn ein Programmierer, der Geld für seinen Job bekommt, seinen eigenen Code nicht mehr blickt, dann ist das in erster Linie peinlich.

...

Das ist manchmal viel schwerer als mein meinen möge. Nur weil du im Moment gerade weißt was dein Code macht, und nur weil du das in 2 Tagen auch noch weißt, heißt das nicht, dass nach 6 Monaten Arbeit an anderen Projekten, es noch immer genau so ist.
Ich wage es einmal zu bezweifeln, dass jemand der nie Kommentare schreibt und seine Variablen komplett Sinnfrei benennt (oder auch einfach nur unsprechend) sich nach einer gewissen Zeit noch daran erinnern wird, was er sich damals Gedacht hat, als er den Code geschrieben hat.

Es ist nicht peinlich seinen Code nicht mehr zu verstehen nachdem man lange Zeit was anderes gemacht hat, egal wie scheisse man ihn geschrieben hat. Es ist einfach nur strunz dumm in seinem Code keine Vorkehrungen zu treffen, sich später leicht wieder einlesen zu können, denn es kostet kaum mehr Mühe es zu tun als zu lassen.

Ist ja auch richtig so. Sagt ja niemand, dass man es sich schwieriger machen muss als nötig. Ich sagte ja auch nur, dass der Code für einen selber möglichst leicht nachvollziehbar sein sollte und nicht allgemein für jeden anderen, der das Spiel im Maker öffnet.

...

Wenn ich meinen Code so schreibe, dass ihn auch ein Fremder nachvollziehen kann, steigen damit die Chancen, dass ich es selber nach einiger Abstinenz von diesem Code auch noch tun kann.