Coding Richtlinien/Empfehlungen

[AlexSchliebner]

Hi @all,

ich habe jetzt auf die Schnelle nichts passendes gefunden, daher eröffne ich dieses neue Thema:

Welche Kriterien würdet Ihr ansetzten, um das Coding in einem Flash-Projekt zu beurteilen?

Ich würde für ein gutes Projekt folgendes voraussetzen:

1. zentralisierter Code: sofern möglich nicht verteilt auf Frames, Symbole und Ebenen - schon gar nicht geschachtelt
2. separate Code-Ebene: sofern Code auf einem Frame platziert werden muß (z.B. "stop();"), kommt hierfür nur eine eigene - ansonsten leere - Ebene in Frage
3. möglichst viel Code auslagern: Einbinden des codes erfolgt dann über include oder Klassendefinitionen in der Library
4. möglichst objektorientiertes Coding: anstelle von prozeduralem Coding
5. Kommentierung: der Code muß ausführlich kommentiert sein

Was meint Ihr zu dieser Aufzählung? Habt Ihr weitere Kriterien?

Wenn jemand eine Quelle mit einer fertigen Kriterienliste kennt - her damit! Gibt es sowas direkt von MM?

Welche Kriterien würdet Ihr ansetzten, um das Coding in einem Flash-Projekt zu beurteilen?

Was zählt ist nicht der Weg, sondern das Ziel.

Wie der Code lautet ist doch völlig egal, solange das Projektziel erreicht wurde. Wichtig ist das Aussehen des Codes nur dann, wenn das Projektziel wiederverwendbarer Code ist.

Und ob der dann funktions- oder objektorientiert ist, wird immer eine "Glaubensfrage" sein, beides hat Vor- und Nachteile.

[DoTheSinWave]

Was zählt ist nicht der Weg, sondern das Ziel.

jo richtig.
Wichtig wären die Kriterien nur, wenn es sich um ein Tutorial handlet, und besonders da. Vielleicht auch noch bei Projekten, an dessen Code mehr als eine Person arbeiten.

[bokel]

Es kommt drauf an, wofür du das brauchst.

Ich war z.B. mal als Zeuge in ein Gerichtsverfahren verwickelt, da fragte mich der Gutachter, ob der Code denn auch "ingenieursmäßig dokumentiert" sei. Als ich das verneinen musste, hat ihn die sonstige Struktur des Codes überhaupt nicht mehr interessiert. Sprich, was nicht dokumentiert ist, kann noch so schön sein, es hat vor Gericht den gleichen Wert wie Spaghetticode.

Was "ingenieursmaessig dokumentiert" genau bedeutet, bzw. was schon reicht, um als solches durchzugehen, kann ich dir aber auch nicht sagen, dass müßtest du dir zusammengooglen.

mfg .r

Ich hab im Studium auch eine Menge über "ingenieursmäßiges" Programmieren gehört. Nur, wer fängt denn an, zuerst einmal Nassi-Shneiderman-Diagramme oder irgendwelche anderen Struktogramme zu entwerfen, bevor er mit dem Scripten anfängt? In der Praxis fehlt da doch meist die Zeit.

Außerdem interessiert die meisten Kunden überhaupt nicht, wie das Script erstellt wurde, nur das Ergebnis zählt.

[projecktx]

hmmm alles schöne und gute vorsätze....

aber realität ist... ich hab jetzt ne idee , egal wie komplex sie auch ist... das grundgerüst steht in ein paar stunden (Ohne flussdiagram)...

da wo mir feinheiten einfallen hinterlasse ich einen kommentar als notiz...

ist alles nachher fertig und läuft einwandfrei... hab ich immer noch zeit alles auszukommentieren (wenn ich denn die zeit habe)....

^^ meine art zu arbeiten... bin zugegebenermassen hektiker ...aber wenn ich erst immer aufschreiben oder auskommentieren würde was ich gerade mache denke oder mir als idee in den kopf kommt... würde es A länger dauern , b hätte ich die hälfte wieder vergessen und c hät ich nach dem erstellen des swf / der anwendung..... ne ganze menge bekritzeltes papier hier rumfliegen was weder ich noch sonstjemand braucht

mal abgesehen davon.. so oft wie hier schon die diskussion um.. Gerippte" swf war die "decompiliert" wurden um an des AS code zu kommen.... hat unübersichtliecher verworener code, hat auch seine vorteile! .... solange man alleine arbeitet wohlgemerkt....

Gruss Sascha

[bokel]

Welche Kriterien würdet Ihr ansetzten, um das Coding in einem Flash-Projekt zu beurteilen?

Eure Postings sind sicher richtig, aber keine Antwort auf die Frage (wenn ich die Frage richtig verstanden habe ).

mfg. r

[projecktx]

ok um diese frage ecplizit zu beantworten.

* Übersichtlichkkeit ( sprich verständliche kommentare wenn nötig mit verweisen)
* vertsändliche Instanznamen und variablenbezeichnungen
* möglichst immer den programmierweg verwenden der bei erreichen der geforderten endleistung die wenigsten resourcen kostet
* eine dokumentationsebene (mit erklärungen zu dem ablauf ansich was zu beachen wäre wichtige variablen etc..
* eine generelle AS ebene
* zentraler code wenn möglich
* auslagern... hmm alles was als routine abläuft ja, allerdings auch nicht zuviel um in den ganzen files nicht den überblick zu verlieren ( ich hab hier ein projekt mit ungelogen alleine 27 as dateien bis man das durch hat und dazu dann auch noch die AS gefunden hat die nötigerweise irgendwo verschachltet in einem MC rumliegen braucht man 1 tag um sich erstmal halbwegs zurecht zu finden, obs einfacher wäre wenn es alles in einem AS layer stünde, weiss ich nicht, aber ich für meinen teil untereteile liebe in einem script als dieses eine soweit zu zerstückeln wie es geht (scrolle halt lieber als tabs anzuklicken)



~~~ zum thema "ingenieurmässige softwareentwiklung" und der frage nach einer kriterienliste...

http://softwaretechnik.adlexikon.de/...etechnik.shtml

^^ siehe da

Gruss Sascha

[derschatten-nrw]

Euer Posting erweckt in mir immer die Frage: Warum soll oder richtet man sich immer an irgendwelchen Strukturen/Richtlinien oder ähnliches. Viele Wege führen doch bekanntlich nach Rom, da ist es doch wurscht ob ich so arbeite oder es anders mache, wichtig ist doch nur das das Ergebnis am Ende zufriedenstellend ist,oder?

Teamwork ist da wohl eine Ausnahme hier geht es ja nicht anders, verschiedene Charaktere, Ansichten, Programmierstil.

[AlexSchliebner]

Ich fasse mal frei zusammen, was in den bisherigen Beiträgen am häufigsten geschrieben wurde:

1. Ein Regelwerk macht nur Sinn bei Arbeit in einem Team.
2. Das einzige Ziel, das Regeln erfordert, ist wiederverwertbarer Code.
3. Für ein Tutorial machen Regeln Sinn.
4. Wozu Regeln für den Weg, wenn das Ziel auch ohne sie erreicht wird?
5. Schöner Code als Ergebnis eines Regelwerks hat im Streifall keinen Wert.
6. Es gibt nicht nur eine richtige Lösung, Orientierung an einem Regelwerk schränkt die Sicht auf Alternativen ein.
7. Ein Regelwerk schafft zusätzliche Arbeit, bringt aber nichts.
8. Ingenieursmäßige Planung kostet Zeit, die jedoch meistens nicht verfügbar ist.

@bokel:

Eure Postings sind sicher richtig, aber keine Antwort auf die Frage (wenn ich die Frage richtig verstanden habe ).

Du hast die Frage wohl richtig verstanden, es waren (vor Deinem Beitrag) tatsächlich keine Antworten auf meine Frage dabei. Aber ob die Postings "sicher richtig" sind - ich wage es zu bezweifeln.

zu 1., 2. und 3.: Ziele, die Regeln rechtfertigen
Na da haben wir doch schonmal drei Ziele, die ein Regelwerk rechtfertigen:

• Teamwork
• wiederverwendbarer Code
• Tutorials (zugegebenermaßen kein alltagstaugliches Ziel)

Ich will noch drei hinzufügen:

• Wenn ich mein Flashprojekt von vor 3 Jahren heute wieder bearbeiten muß, ist es durchaus vorteilhaft, wenn ich mich nicht erst stundenlang durch Ebenen, Symbole und Frames wühlen muß, bevor ich den ganzen Code gefunden und wieder verstanden habe.
• Wenn ein Flashprojekt eine lange Lebensdauer hat und nach gewisser Zeit der Bearbeiter wechselt, ist es ebenso vorteilhaft, wenn bei der Erstellung Coderichtlinien beachtet wurden.
• Je größer das Projekt, je universeller der Einsatz desto wichtiger sind Planung und Regeln.

zu 4. und 5.: Regeln sind überflüssig
Wenn keines der oben genannten Ziele gegeben ist, dann kann man - von mir aus - auf Regeln verzichten. Es ist dann aber klar, daß das betreffende Werk nicht teamfähig ist, nicht gut wiederverwendbar ist, hoffentlich nie der Bearbeiter wechselt, es hoffentlich nie geändert werden muß ... - Ihr wißt was ich meine.

zu 6.: Regeln als Kreativitäts-Killer
Das ist ein Argument, das fast immer jeder Form von Ordnung entgegengehalten wird. Da schwingt so ein bisschen das Bild des chaotischen Genies mit, den Ordnung als Zwang einengt und die Kreativität erstickt. Meine Erfahrung ist dem diametral entgegengesetzt: Die Abwesenheit von Ordnung kostet mich Zeit, nimmt mir die Übersicht und die Unbeschwertheit, die ich brauche um kreativ zu sein.

zu 7. und 8.: Der Aufwand ist zu groß
Natürlich kann man es übertreiben. Zu viel Regeln und ein übertrieben genaues Vorgehensmodell sind ganz bestimmt kontraproduktiv. Niemand verlangt "Nassi-Shneiderman-Diagramme".
Das Regelwerk hingegen, das ich in meinem eröffnenden Posting vorgeschlagen habe, kostet praktisch keine Zeit und verursacht auch keinen Mehraufwand. Es erfordert wohl aber Disziplin und Konsequenz.

Noch ein letztes Argument für Planung und Regeln: Schaut Euch mal den AS2-Code der Flash-Komponenten usw. an (.../First Run/Classes/...) oder den Shop von spreadshirt und glaubt mir: Wer solche Projekte macht, der plant sogar mit dem einen oder anderen Diagramm. Und das Ergebnis ist durchaus in der Lage zu begeistern.