Come documentare gli eventi?

6

La documentazione del codice è in genere correlata a un pezzo di codice, sia esso piccolo (metodo-livello) o più grande (classe o livello di spazio dei nomi). Tuttavia, si tratta sempre degli input e degli output di quel pezzo di codice, possibilmente descrivendo il suo comportamento e i caveat.

Non ha molto senso documentare gli eventi lanciati da una classe nei metodi che possono attivarli: possono essere duplicati e, dalla definizione di eventi, non ci si aspetta che l'ascoltatore si preoccupi di cosa li innesca, solo gestendoli.

Documentare tutti gli eventi nella parte superiore di una classe sembra abbastanza pesante, in quanto qualcuno disposto a ottenere una panoramica del comportamento di classe potrebbe non essere così interessato alle immersioni profonde a questa "interfaccia secondaria".

Questo problema è attenuato in linguaggi strongmente tipizzati come Java (sì, a meno che non si utilizzino classi anonime, ma non sembra così comune), poiché gli eventi saranno definiti nelle proprie classi, che possono quindi essere documentati .

Tuttavia, nelle lingue con tipi più sciolti, in cui un evento è semplicemente un identificatore di stringa e una serie di parametri, è molto più difficile trovare il posto giusto per documentare queste combinazioni id / param.

Quindi: dove dovrebbero essere documentati gli eventi licenziati in lingue che non li modellano esplicitamente?

    
posta MattiSG 21.02.2013 - 10:42
fonte

3 risposte

2

Appartiene alla documentazione laterale, che di solito è chiamata reference . Tale documentazione, come la hai delineata, non appartiene alla documentazione della classe / metodo, quindi il posto migliore è avere una documentazione dedicata per loro.

Per esempio, dai un'occhiata a come Symfony2 documenta i suoi eventi interni esposti: link

Non essere troppo veloce per ignorare gli eventi come "interfaccia secondaria". Di solito sono esattamente l'opposto, in quanto sono il modo principale per estendere la funzionalità in un modo molto semplice.

    
risposta data 21.02.2013 - 11:45
fonte
1

Innanzitutto, gli eventi non sono l'interfaccia secondaria . Appartengono completamente all'interfaccia.

Li documento in tre parti:

  • a lato del mittente: elenco di eventi che possono essere generati.
  • dal lato del destinatario: elenco di eventi che possono attivare un'azione.
  • in un modulo specifico in cui sono dichiarati tutti gli eventi: descrizione completa di ciascun evento.
risposta data 21.02.2013 - 11:42
fonte
0

Ogni metodo dovrebbe documentare i suoi gazintas e gazoutas. Le cose che entrano in un metodo includono i suoi parametri e gli stati rilevanti dell'oggetto a cui appartiene. Le cose che ne derivano includono il suo valore di ritorno, i cambiamenti rilevanti nello stato dell'oggetto, gli eventi che spara, i cambiamenti nei dati persistenti, etc. Una documentazione chiave del codice è di rispondere a "Chi sono Io? Perché sono qui? " domande. Se devi leggere il codice per imparare quelle risposte, la documentazione è insufficiente.

    
risposta data 21.02.2013 - 13:22
fonte

Leggi altre domande sui tag