#1 L'Arte del chiedere aiuto

Visto che in questi giorni i thread di aiuto sulla programmazione si stanno moltiplicando ho deciso di fare un piccolo post su COME chiedere aiuto.

Perchè c'è anche un modo specifico? Beh no, ma c'è sicuramente un modo per:

- far capire meglio il problema a chi vi legge
- far perdere meno tempo, sia a voi che aspettate una soluzione, sia a chi vuole aiutarvi
- farvi imparare di più anche solo chiedendo aiuto
- qualche volta farvi addirittura accorgere da soli del vostro errore.

Quando volete aprire un thread di aiuto riguardante un problema di programmazione vi prego perciò di seguire queste linee guida:


- Iniziate con il dire che cosa state sviluppando
es. Algoritmo di pathfinding, Clone di Tetris, Crysis 3.

- Proseguite con il dire cosa state usando!
Il postare dentro la sezione di un determinato linguaggio non basta, elencate anche eventuali librerie o tool che state utilizzando che possono essere collegate al problema.

IL MIO AMBIENTE DI SVILUPPO MI DA UN ERRORE!

- Dite che tipo di errore avete:
- un errore di compilazione?
- un errore di linking?
- conosco la differenza tra errore di compilazione ed errore di linking?
Anche se non conoscete la differenza, se il vostro ambiente di sviluppo vi da un errore:

- Fate il COPIA\INCOLLA del vostro errore!
Non fate perdere tempo a chi vuole aiutarvi e non perdetene voi, se non postate il vostro errore la prima risposta al thread sarà: copiaci l'errore.
Non descrivete l'errore in linee generali del tipo "mi da un errore" o "mi da un errore quando scrivo questa riga", copiare l'errore non è un optional.

- Fate il copia\incolla del vostro codice
Copiate la parte di codice che vi da problemi. Se non avete un errore di compilazione bensì un errore logico (es. il gioco parte ma non funziona come dovrebbe) allora prima di copiare pagine di codice cercate di individuare dove può essere il problema, se in una funzione specifica o in una parte ristretta del codice, e copiate solo quello. In alternativa zippate tutti i vostri sorgenti e metteteli sul vostro dropbox\file uploader di fiducia.
Ricordate di usare i tag [ CODE ] e [ /CODE ] (senza spazio) per il vostro codice

IL MIO GIOCO CRASHA E NON CAPISCO PERCHE'!

- Cercate di indicare dove\quando crasha
Cercate di essere il più chiari possibili sul crash:
sembra avvenire a caso? Capita all'avvio? Capita solo se si fa una determinata cosa nel gioco?
E più specificatamente DOVE crasha il gioco? A che riga di codice? e cosa dice la finestra di output del vostro ide\debugger?

- Fate il copia\incolla del vostro codice
Anche per questa voce, copiate il codice incriminato e tutto il codice collegato alle variabili\funzioni che causano il crash. Se è troppo, zippate e hostate l'archivio da qualche parte. In quel caso è meglio se postate tutto il vostro codice completo del progetto dell'ide usato, così chi vi aiuta può almeno provare a compilarlo e vedere dove avviene il crash.


IL GIOCO PARTE MA NON FUNZIONA COME VORREI!

Questi sono gli errori "logici", sono i più comuni e possono andare dai semplici bug alla totale non comprensione dell'algoritmo che si vuole implementare.
Se volete fare una cosa, es. spostare un oggetto in 3D\2D, fare collisioni tra poligoni o sprites e avete in testa una possibile idea sul come realizzarla, assicuratevi che il vostro codice faccia effettivamente quello che avete in testa. Spiegate in dettaglio cosa volete fare e commentate il vostro codice.

COSA NON FARE

- Non rispondete mai usando toni presuntuosi a chi sta cercando di aiutarvi.

- Non scrivete mai solamente "non funziona", scrivete "crasha alla riga x e in output dice: ", "non compila e da il seguente errore: alla riga x"

- Se avete provato qualcosa che vi è stato suggerito non rispondete in modo generico del tipo "niente non funziona neanche così ", dite cosa succede in dettaglio come avete fatto prima se succede qualcosa di diverso.

- Non aprite il thread se non avete almeno provato mezza giornata a risolvere il vostro problema da soli
Chiedere aiuto per qualcosa che potevate anche risolvere da soli con un po' di sforzo è come arrivare ad un boss di un gioco, morire la prima volta e usare un cheat per passare oltre, rovina il divertimento e non vi fa imparare nulla (e il prossimo boss vi distruggerà comunque).



CONSIGLI FINALI:

- Usate il debugger
Molti coder alle prime armi ignorano l'esistenza del debugger, dei breakpoint e delle funzionalità avanzate del loro stesso IDE. Imparate a debuggare bene il vostro codice. Imparate a mettere breakpoint e controllare passo passo i valori delle vostre variabili. Saper usare il debugger è fondamentale per qualsiasi coder che si rispetti.

- Commentate parti di codice
Qualche volta un buon metodo per scovare un bug, specialmente quando "un minuto fa questo non accadeva" è il commentare pezzi di codice o chiamate a funzioni. Commentandole non verranno eseguite, e qualche volta potrete risalire alla funzione che causa il problema.

- Stringhe di debug e file di log sono i vostri più fedeli alleati
Anche se spesso usare il debugger è praticamente necessario il buon programmatore ha sempre qualche funzioncina di debug sua: una classe che scrive un file con il log passo passo dell'esecuzione del vostro programma, delle funzioni che stampano a schermo stringhe di testo tipo "Camera.Position.X = xxxx" sono sempre utilissime. E' anche molto utile utilizzare printf e funzioni varie per stampare testo su console o direttamente sulla output window del vostro ide (ad esempio Debug.Write in C# o OutputDebugString su VC++).
Tenete sempre controllo i valori delle variabili importanti del gioco o della classe che state implementando.

- Imparate ad usare gli Assert
assert è una funzione comune nei linguaggi di programmazione e potete facilmente anche implementarvela da soli:
data una espressione la funzione assert deve mandare un messaggio di errore se il parametro passato è falso (innescando anche un break del debugger o tornando il numero di riga del codice magari! ).
In pratica è qualcosa tipo assert ( bool ); e va usata per controllare che alcune situazioni non si possano mai verificare. Qualche esempio:
assert(gameLevel<0); //la variabile gameLevel non dovrebbe mai essere negativa, se succede dammi un errore!
assert( player.isJumping && player.isCrawling) //il giocatore non dovrebbe mai essere capace di saltare e strisciare allo stesso momento.
assert(currentLevel); //il puntatore a questo oggetto non deve mai essere null!
Qualsiasi linguaggio usate dovreste aver accesso ad una funzione assert sul linguaggio stesso o sulle librerie standard.
Gli assert sono particolarmente utili per debuggare macchine a stati con stati multipli e per verificare i puntatori.

- Compilate ed eseguite passo passo
Non mettetevi a scrivere centinaia di righe di codice se non sapete bene cosa state facendo, compilate il vostro codice spesso per vedere se ci sono errori e specialmente eseguite ogni volta per assicurarvi che quello che state scrivendo funzioni a dovere. Non aspettate di aver implementato un complesso algoritmo prima di eseguire il gioco. Controllate che il codice si comporti in modo corretto anche prima di aver finito, per far ciò ricollegatevi alla voce "Usate il debugger".

- Studiate il linguaggio
Far pratica è il miglior modo per imparare, e sbagliare mentre si impara qualcosa di nuovo è normalissimo. Se siete alle prime armi potete velocizzare il vostro apprendimento affiancando un libro sul linguaggio che utilizzate allo sviluppo del vostro gioco.

- Studiate la documentazione delle librerie
Se state utilizzando librerie esterne, siano complessi engine\librerie 3d (XNA, Ogre, Irrlicht, DirectX, OpenGL ecc) oppure piccole librerie di supporto, non dimenticate che spesso e volentieri vi viene fornita la documentazione completa in un sacco di formati diversi (html, pdf, chm). E anche nei casi in cui non c'è documentazione separata potete imparare il funzionamento delle classi della liberia guardando i files .h (nel caso di C++ o linguaggi simili) o direttamente i sorgenti se disponibili.

- Non mollate!
La programmazione di videogames non è la cosa più facile in cui vi cimenterete, ma con la giusta dose di pazienza e voglia di imparare andrete sicuramente avanti. Se un problema vi sembra insormontabile riposate e tornateci sopra a mente fresca, oppure cercate di trovare una soluzione alternativa chiedendo sul forum anche semplicemente "voi come fareste per fare questo?"


In bocca al lupo con la programmazione e con il vostro thread di richiesta di aiuto!

#2 RE: L'Arte del chiedere aiuto

Eclipse santo subito!

#3 RE: L'Arte del chiedere aiuto

+1000 like

PS: eclipse scusa se mi permetto, non è meglio metterne una copia in The Source?

#4 RE: L'Arte del chiedere aiuto

si lo faccio subito.

edit: spostata e fatto il redirect!

#5 RE: L'Arte del chiedere aiuto

grande

altri consigli base di debugging (che non richiede per forza sapere usare il debugger): logs, logs, logs. Sia text output nella console che (possibilmente) log files

e ASSERTS:

http://www.codeproject.com/KB/cpp/assert...riend.aspx

#6 RE: L'Arte del chiedere aiuto

hai ragionissimo! asserts e logs su file o su console sono strumenti basilari anche quelli, ho aggiunto le voci

#7 RE: L'Arte del chiedere aiuto

c'è poco da dire :

+1

#8 RE: L'Arte del chiedere aiuto

Stending ovescion per eclipse

#9 RE: L'Arte del chiedere aiuto

Thread molto bello e dettagliato... direi troppo.
Non vorrei sembrare disfattista, ma sappiamo bene che chi chiede aiuto, lo fa per qualcosa di urgente, che serve immediatamente, proprio per non "perdere tempo" a fare ricerche o leggere guide varie.
Questo tipo di "guida all'utilizzo", viene saltato a pie' pari da chi si fa prendere dalla fregola di risolvere tutto e subito.
Come chi, e non del tutto a torto, si iscrive al forum solo per chiedere una informazione.



Vorrei concludere con una suggestiva immagine.

#10 RE: L'Arte del chiedere aiuto

una versione "ristretta" di quello che ha scritto eclipse è:

-prima di chiedere aiuto provare a risolvere il problema da soli usando tutti i mezzi possibili (debuger-google- etc...)

-accettare qualunque risposta e non offendere mai

-quando si chiede aiuto dare più informazioni possibili
(ad esempio se si parla di codice: postare il codice e i log del debug....)

-essere positivi e non mollare

#11 RE: L'Arte del chiedere aiuto

(07-09-2011 12:45)Gabriele ha scritto:  una versione "ristretta" di quello che ha scritto eclipse è:

-prima di chiedere aiuto provare a risolvere il problema da soli usando tutti i mezzi possibili (debuger-google- etc...)

-accettare qualunque risposta e non offendere mai

-quando si chiede aiuto dare più informazioni possibili
(ad esempio se si parla di codice: postare il codice e i log del debug....)

-essere positivi e non mollare

non dimentichiamo la ricerca nel forum

#12 RE: L'Arte del chiedere aiuto

(07-09-2011 17:55)theGiallo ha scritto:  non dimentichiamo la ricerca nel forum

Quello viene prima di tutto.

#13 RE: L'Arte del chiedere aiuto

(07-09-2011 12:10)Spaventacorvi ha scritto:  Thread molto bello e dettagliato... direi troppo.
Non vorrei sembrare disfattista, ma sappiamo bene che chi chiede aiuto, lo fa per qualcosa di urgente, che serve immediatamente, proprio per non "perdere tempo" a fare ricerche o leggere guide varie.
Questo tipo di "guida all'utilizzo", viene saltato a pie' pari da chi si fa prendere dalla fregola di risolvere tutto e subito.
Come chi, e non del tutto a torto, si iscrive al forum solo per chiedere una informazione.

Da ora in poi o si segue quel modello o come risposta oltre ad eventuali suggerimenti verrà linkato questo thread. In modo che piano piano tutti gli utenti, anche i nuovi, vengano a conoscenza della "netiquette"