RPG Game verschlüsseln

[Cepanks]

Und apropos RGSS - schaut euch den originalen RGSS-Quelltext an, der ist auch komplett kommentiert und dokumentiert…

...

Wobei die Kommentare ein gutes Beispiel dafür sind, wie man es eigentlich nicht machen sollte, weil sie in der Regel so aussehen:

Code:

#--------------------------------------------------------------------------
# * Remove Actor
#     actor_id : actor ID
#--------------------------------------------------------------------------
def remove_actor(actor_id)
  # Delete actor
  @actors.delete($game_actors[actor_id])
  # Refresh player
  $game_player.refresh
end

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

[Morden]

@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

[MagicMaker]

Und bei komplexeren Dingen, bei denen man sich eine Erklärung wünschen würde, steht dann hingegen meist garnichts

...

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.

[Cornix]

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.

...

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.

[Corti]

Eine Kommentarmethode , die sich bei mir im Job und im Maker bewährt hat:
Ich beschreibe als Text vollständig was die Funktion machen soll. Bevor ich auch nur eine Zeile Code tippe. Wenn die Funktion fertig ist muss ich nur noch den Text zerstückeln und verteilen ;-)

[Rusk]

Eine Kommentarmethode , die sich bei mir im Job und im Maker bewährt hat:
Ich beschreibe als Text vollständig was die Funktion machen soll. Bevor ich auch nur eine Zeile Code tippe. Wenn die Funktion fertig ist muss ich nur noch den Text zerstückeln und verteilen ;-)

...

Und vor der Kommentarmethode wird es, wie es sich gehört brav ein Ablaufdiagramm erstellt.

[Nemica]

Und vor der Kommentarmethode wird es, wie es sich gehört brav ein Ablaufdiagramm erstellt.

...

Ablaufdiagramme sind überbewertet. Aber ich hab schon mindestens eine Doku für meine Eventscripts geschrieben.

[Rusk]

Ablaufdiagramme sind überbewertet. Aber ich hab schon mindestens eine Doku für meine Eventscripts geschrieben.

...

Ich meinte das auch sarkastisch ... ich kann mich nie wirklich mit diesen Dingern anfreunden. Ich mach sie sowieso nie, einfache Notizen sind da schon das Maximum. ^^

[Nemica]

Ich meinte das auch sarkastisch ...

...

Ach lass mir meinen Spaß. xD

Und Kommentare haben auch den Vorteil, dass man sie vorm Release rauslöschen kann.

[Rusk]

Kommentare vor dem Release zu löschen verfehlen meiner Meinung nach ihren Sinn und Zweck. Außer du meintest in Form von persönlichen Notizen, was aber dann keine richtigen Kommentare wären (zumindest nicht in richtigen Programmen und im Makerspielen ist es ja eh egal, was drinsteht. Das liest sich kein Mensch durch ^^).

[Morden]

PAP, Nassi-Shneiderman und wie sie nicht alle heißen - ich bin auch kein großer Freund davon. Ich persönlich denke aber, dass sie bei komplexen Projekten durchaus Sinn machen. Ein paar kleinere Notizen oder MindMaps mache ich doch durchaus manchmal - wenn auch sehr selten xD

Und naja, Kommentare vor Release zu löschen wäre in meinen Augen - gerade bei einem Makerspiel - mehr Aufwand als Nutzen. Immerhin muss man sich dann durch jedes einzelne EventScript quälen und die Kommentare suchen und herauslöschen.

PeAcE
MorDen

[Nemica]

Wenn dein Code gut ist, dann hast du da nicht so viel, wo du durchscrollen musst.