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.
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".
Geändert von TwoFace (23.05.2013 um 13:50 Uhr)
Undzwar auf möglichst langem Zeitraum, ist keine leichte Angelegenheit, wenn die Events auch mal über ein paarZitat
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.
--
Solange es hier falschzitierende Ärsche gibt, dulde ich keinerlei Zitatboxen, die von mir sein sollen.
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.
--CortiWins GitHub DynRPG < Charguide < [2k3] Zahlen und Werte < [2k3] Kurven als Wertetemplates < [2k3] DynRPG Werkstatt
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Hello from the otter side
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
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.
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.
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.
--CortiWins GitHub DynRPG < Charguide < [2k3] Zahlen und Werte < [2k3] Kurven als Wertetemplates < [2k3] DynRPG Werkstatt
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Hello from the otter side
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Geändert von Corti (23.05.2013 um 15:46 Uhr)
Ihr vergleicht Programmieren mit Makern.
@Deamonic: Anwendungsentwicklung funktioniert immer nach denselben Prinzipien.
Maker ist wie Assembler zum Klicken ;-)
--CortiWins GitHub DynRPG < Charguide < [2k3] Zahlen und Werte < [2k3] Kurven als Wertetemplates < [2k3] DynRPG Werkstatt
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Hello from the otter side
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Und dann haben die neuen Maker RGSS, was schließlich ebenfalls programmieren ist.
--
Egal wo in der Anwendungsentwicklung: Kommentare und Dokumentation sind wichtiger, als man denken mag!
Und es ist nicht egal, ob man das irgendwie hinklatscht oder sich eine saubere Struktur überlegt! Sowohl für denjenigen, der es erstellt, als auch für etwaige andere Personen!
Man sollte zumindest darauf achten eine gewisse Konsistenz in sein Skript/seinen Quelltext zu bringen. Damit meine ich, dass man bestimmte immer wiederkehrende Probleme auch möglichst auf die gleiche Art und Weise löst (von der Schreibweise und Logik her) - so ist es im Nachhinein viel einfacher auf einen Blick zu erkennen »Was geht dort ab und wann bin ich wo im Quelltext/Skript angelangt?«
Klar ist für jeden "klar verständlich" anders zu definieren, aber dennoch kann mir keiner erzählen, dass er einfacher durch seine Sachen blickt, wenn er keine Kommentare oder Dokumentation hinterlässt und nicht konsistent arbeitet. Auch sollte man für wiederkehrende Aufgaben - auch im Maker - eine Art Funktion schreiben/skripten. So garantiert man a) dass es auf die gleiche Art und Weise funktioniert - an jeder Stelle, an der es eingesetzt wird, und b) ist die Wartung viel einfacher, denn eine Funktion abzuändern ist einfacher, als an tausend Stellen im Quelltext/Skript nach dieser Funktion zu suchen und sie anzupassen bzw. zu copy/pasten.
Und apropos RGSS - schaut euch den originalen RGSS-Quelltext an, der ist auch komplett kommentiert und dokumentiert…
PeAcE
MorDen
--»Ein Traum kann auch die Wehmut nach der verlorenen Vergangenheit sein…«
»Manchmal ist eine Enttäuschung auch einfach nur das Ergebnis zu hoher Erwartungen.«
__________________________________________________________________________
Wobei die Kommentare ein gutes Beispiel dafür sind, wie man es eigentlich nicht machen sollte, weil sie in der Regel so aussehen:
Das fällt genau in die Kategorie von unnötigem Kommentar, die Corti irgendwo weiter oben angesprochen hat. Es sollte z. B. eigentlich offensichtlich sein, dass $game_player.refresh höchstwahrscheinlich genau das tut: Das Spieler-Objekt refreshen. Andernfalls hat man bei der Methoden-Bennenung was falschgemacht.
Und bei komplexeren Dingen, bei denen man sich eine Erklärung wünschen würde, steht dann hingegen meist garnichts o_o
--"Banjo, you're a BEAR... and I will teach you... THESE MOVES!"
@Cepanks
Da muss ich dir dann durchaus Recht geben. Ich meinte damit ja auch nicht, dass die Kommentare und Dokumentation der RGSS-Parts jetzt sonderlich gut ist - ich weiß, dass sie das im Gegenteil eher nicht ist. Ich wollte damit nur sagen, dass diese halt auch kommentiert sind.
Im Allgemeinen sollte man natürlich versuchen seine Variablen, Funktionen, Klassen und Methoden einfach nachvollziehbar benennen - davon kann man nur profitieren! Sollte ein Funktionsaufruf o.Ä. natürlich selbsterklärend sein - wenn man denn die Sprache in der sie geschrieben ist, lesen kann - ist ein Kommentar natürlich einfach nur unnötig und verwirrt eher, als dass er unterstützt. Man sollte im Allgemeinen nicht jede einzelne Zeile kommentieren, nützlicher ist es eher einen kompakten Kommentar vor eine Verzweigung oder Schleife zu packen, der beschreibt was sie macht - sollte das nicht schon von vornherein ersichtlich sein. Ist zumindest meine Meinung, die natürlich nicht jeder teilen muss^^
PeAcE
MorDen
--»Ein Traum kann auch die Wehmut nach der verlorenen Vergangenheit sein…«
»Manchmal ist eine Enttäuschung auch einfach nur das Ergebnis zu hoher Erwartungen.«
__________________________________________________________________________
Guck dir das obligatorisch-typische Spiel auf einer Makerengine an:
Erklären den einfachsten Doofmist und tun's genau dann nicht, wenn's mal von Nöten wäre.
Es überträgt sich sozusagen von hinter auf vor die Kulissen.
--
Solange es hier falschzitierende Ärsche gibt, dulde ich keinerlei Zitatboxen, die von mir sein sollen.
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.
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.
--
Geändert von The_Burrito (23.05.2013 um 19:22 Uhr)
Für simple Funktionen ist es simpel einen Kommentar zu schreiben.
Eine komplizierte Funktion welche man mit nur viel Denkarbeit und Trial&Error schreiben konnte ist hingegen schwer zu kommentieren, vor allem wenn man nicht sofort kommentiert nachdem man die Funktion geschrieben hat sondern erst im Nachhinein.
Generell bevorzuge ich sehr einfach verständliche und konsequente Namensgebung für Variablen und Methoden beizubehalten, sodass man die meisten Methoden nicht kommentieren muss.
Was man kommentieren sollte sind Ausnahmefälle, Vorbedingungen für die Ausführung einer Funktion, Schleifeninvarianten (bei komplexen Schleifen), oder wenn man gewisse Schritte zur besseren Effizienz "weniger" übersichtlich schreibt weil es sich um eine kritische Funktion handelt.
Außerdem, wenn die Bibliothek veröffentlicht werden soll, liebe ich es immer wenn in die Kommentare auch geschrieben wird, ob es sich um eine heavy- oder lightweight Methode handelt.
Berechtigungen
Zitieren
