Was braucht ein gutes Thema, um gelesen und beantwortet zu werden?

[marc]

Ich hatte heute Morgen ein Interessantes und nettes Gespräch mit Sebastian Wichmann von Flashhilfe.de, was mich dazu angeregt hat dieses Thema hier zu erstellen. Denn es wurde zwar oft in einzelnen Themen und Beiträgen darauf hingewiesen und gemeckert, aber so einen "Wie geht das" Thread gibt es dazu noch nicht wirklich.

Also: Was muss denn eigentlich in einer Frage alles enthalten sein, damit man beim Beantworten oder auch schon gleich bevor man das Thema eigentlich anklickt "Spaß" hat? Viele der Dinge stehen bereits in einem recht alten Beitrag von Thorsten zum Umgang in einem solchen Forum und im Internet. aber Dinge ändern sich und ich würde mich freuen, wenn dieses Thema als Verweis für diejenigen verwendet werden kann, die hier Hilfe benötigen.

Der Titel eines Themas (Thread-Titel)

Wähle einen Aussagekräftigen Titel

Es ist wichtig für dich als Fragenden, dass du den Kern deiner Frage schon im Titel wieder gibst. Dreht es sich also um eine Frage zu Animationen mit Hilfe von Tweenings, dann ist es sinnvoll das auch dort zu erwähnen. Also "Problem mit Tweening" macht hier mehr Sinn als "Hilfe!!!!".


Inhalt und Form des Beitrages

Formuliere dein Anliegen so genau wie möglich und so kurz wie nötig

Versuche kurz zu beschreiben was du erreichen möchtest und wo dein Problem auftritt. Vermeide ellenlange Geschichten. Gib aber alle nötigen Informationen die jemand braucht, um dir helfen zu können. Geht es zum Beispiel um Eine Frage zu Menüs oder Einstellung ist es Sinnvoll auch immer einen Screenshot mit anzufügen (auch bei vielen anderen Fragen/Problemen ist das natürlich nicht verkehrt). Ist dein Problem programmiertechnischer Natur, dann sollte auch der Quellcode nicht fehlen oder zumindest die Ansätze von dir. Geht es um Dinge die eine Ablaufbeschreibung erfordern, damit man Sie nachvollziehen kann, um dir zu helfen, dann schreibe eine.


Zitate

Zitiere nur, was für deine Antwort auch relevant ist

Bei Zitaten ist es wichtig, dass der entsprechende Kontext zitiert wird, um den es dir geht. Es hilft niemandem, wenn man sich den komplette Beitrag deines Vorredners noch einmal durchlesen muss, um dann von dir zu hören "Stimm, sehe ich genauso".


Ich würde mich freuen, wenn ihr vielleicht selber auch noch Tipps habt, die gerade die, die hier neu sind noch benötigen, um einen "guten" Thread erstellen zu können. Außerdem lege ich jedem noch einmal das oben genannte Thema "Umgangsformen im Netz und im Forum" an Herz.

Danke und viel Spaß weiterhin im Flashforum!

[Martin Kraft]

Ist eine gute Idee, das mal zusammenzufassen!

Ich würde noch folgende Punkte hinzufügen:

Was ist der richtige Forenbereich für mein Problem?(keine Mehrfachpostings)
Es gibt hier ja für fast alles einen Spezialbereich und an den sollte man sich auch halten. Einfach nochmal in einem anderen Bereich zu posten, weil man sich übersehen fühlt verwirrt nur.

Worum geht es überhaupt? (Vom Großen ins Kleine)
Häufig hilft es zu wissen, was überhaupt ereicht werden soll. Manchmal verbeist man sich nämlich in einem Detail, obwohls schon im Ansatz hapert und es dafür eine viel elegantere Lösung gäbe...

Welche ActionScript-Version? (Im Einsteigerbereich)
Sonst bekommte man Ratschläge im flaschen AS-Dialekt

Wo steht der Code den ich gepostet habe?
In der Zeitleiste (von welchem Objekt), direkt auf einem Objekt, in einer Klasse...?

Ist mein Beitrag verständlich und einigermaßen korrekt in Grammatik und Rechschreibung?
Manche Fragen scheitern einfach daran, das sie so verworren formuliert und falsch geschrieben wurden, dass sie keiner versteht. Ich bin da auch nicht so der Held, aber es hilft, Lindwurmsätze zu vermeiden, keine unverständlichen Abkürzungen und Slang-Begriffe zu verwenden und den Post nochmal auf Vertipper und Rechtschreibefehler Korrektur zu lesen.

Ist mein Beitrag ordentlich gegliedert?
Es gibt hier viele Möglichkeiten, seinen Beitrag auszuzeichenen und zu gliedern und so die Gedanken für andere besser verständlich und einfacher lesbar zu machen.

[Mr.Twister]

Formatierung / Gliederung
Wenn jemand viel schreibt, weil die Problemstellung z.B. komplex ist, würde ich immer mit sinnvollen Absätzen und fetten Überschriften arbeiten.

Ich finde es bei einer Problemstellung auch wichtig zu erwähnen, ob man bereits selbst recherchiert hat oder schon Lösungswege ausprobiert hat.
Das würde ich aber immer erst zum Schluss erwähnen.

[sonar]

Ich verweise immer wieder gerne hierauf:
Wie man Fragen richtig stellt: eine Anleitung wie man Fragen erfolgreich in Usenet, Mailing Listen und Webforen stellt.

[milchreis]

Fehlermeldungen helfen dem:
- Helfer, gleich zu sehen, worum es geht
- Frager (), die relevante Zeile/Abschnitt zu finden und diesen (und nur diesen) zu posten.

[Omega Psi]

So, ich muss mich mal eben zum Thema Programmierfragen äussern, da das Leben noch viel einfacher sein kann. Ich habe mir mal Gedanken über die 3 goldenen Regeln der Programmierfragen gemacht:

1. Wird ein Fehler geworfen, kopiere die Fehlermeldung und für diese in ein Zitat ein.

   Wenn es einen Programmierfehler (Kompilier- oder Laufzeifehler) gibt, gibt Flash (respektive der Flash Debugger) eine Fehlermeldung aus. Diese noch vor der ersten Zeile Code.

2. Formatiere den Code, um ihn lesbarer zu machen.

   Wenn Fragen gestellt werden, sind viele Mitglieder des Forums willens, dir zu helfen. Doch wenn dein Code nach Kraut und Rüben aussieht, machst du es denen, die helfen wollen oder können, nicht einfach, wenn man deinen Code nur schwer lesen kann. Bitte überprüfe deine Code auf folgende Merkmale:

   1. ist der Code vernünftigt eingerückt?
   2. benutze ich vernünftige Variablennamen? Ein verständlicher Variablenname ist immer eine große Hilfe. Richtet man sich nach den Coding conventions von Adobe, macht man es sich selbst und anderen insgesamt am einfachsten.
   3. konsistente Klammersetzung.
   4. überflüssige Leerzeilen bitte entfernen, weil sie den Code zu sehr auseinander reissen.
   5. 120 Zeichen sind genug pro Zeile... auch in echten Projekten

3. Vereinfache deinen Code. Dazu gibt es ganz einfach Mittel und Wege, die zugleich auch leichte Optimierungen im Code mit sich bringen.
   

   Arbeiten mit Arrays

   1. Deklariere Lokale Variablen und vermeiden das Arbeiten mit Indizes. Gut:

      var _clips:Array /* of flash.display.Sprite */ = []; // will be filled later
      
      processArrayOfSprites(_clips);
      
      function processArrayOfSprites(array:Array /* of flash.display.Sprite */) 
      {
        const length:int = array.length;
        var sprite:Sprite;
        for (var i:int; i < length; i++)
        {
          sprite = Sprite(array[i]); // hard cast to get an immediate error
          sprite.x = i * 10;
          sprite.y = i * 10;
        }
      }

      Schlecht:
      

      var _clips:Array /* of flash.display.Sprite */ = []; // will be filled later
      
      processArrayOfSprites(_clips);
      
      function processArrayOfSprites(array:Array /* of flash.display.Sprite */) 
      {
        for (var i:int; i < array.length; i++)
        {
          array[i].x = i * 10;
          array[i].y = i * 10;
        }
      }

      Alternativ, in vielen Fällen die zu präferierende Lösung

      var _clips:Array /* of flash.display.Sprite */ = []; // will be filled later
      
      processArrayOfSprites(_clips);
      
      function processArrayOfSprites(array:Array /* of flash.display.Sprite */) 
      {
        for each(var sprite:Sprite in array)
        {
          sprite.x = i * 10;
          sprite.y = i * 10;
        }
      }

      Das sind nur Beispiele... das bietet sich natürlich auch in anderen Situationen an, nicht nur in Schleifen.
   2. Finde die Ausnahmen und breche schnell ab, arbeite nicht mit der Regel.
      Gut:

      function processItem(item:Object):void
      {
        if (!object) return;
      
        // go on...
      }

      Schlecht:

      function processItem(item:Object):void
      {
        if (object)
        {
          // go on...
        }
      }

      Alternativ gibt es auch Fälle, in denen man Fallbacks anbieten kann, das ist natürlich aber ach nicht die Regel.

      function processItem(item:Object):void
      {
        var object:Object = item || {};
      
        // go on...
      }

Just some food for thoughts.