Invio materiale - Linee guida per la pubblicazione

Le regole che seguono ti aiuteranno a inviare del materiale potenzialmente pubblicabile.

Premessa

Il WebMaster in carica vaglia tutti i progetti inviati prima di pubblicarli.
Seguendo i punti sottoelencati risparmierai a te stesso e al WebMaster (che ringrazia anticipatamente) molto tempo e fatica, in particolare ti risparmierai l'eventualità di veder negata la pubblicazione.

E' nell'interesse del Sito Comune e degli stessi Collaboratori che il materiale pubblicato sia dibuona qualità, per varie ragioni.

Noterai che molte delle regole elencate sono solamente dettate dal buon senso.

I progetti inviati si possono distinguere in due macro-categorie: "educazionali" o "pronti all'uso".

Definaimo "educazionali" i progetti che si prefiggono lo scopo di insegnare come eseguire un compito o risolvere un problema.

Definiamo "pronti all'uso" i progetti che sono o contengono componenti subito riutilizzabili che eseguono un compito o risolvono un problema.

Nota: nelle seguenti regole noterai i seguenti verbi in maiuscolo, ecco come interpretarli:

Regole Generali

Queste sono le caratteristiche minime che un progetto inviato al Sito Comune DEVE avere per poter essere pubblicato:

- NON DOVREBBE essere presente sul Sito Comune nessun progetto che fa la stessa cosa nello stesso modo.

- DEVE utilizzare componenti standard: quando il WM carica il progetto, questo non deve dare errori di "componente non trovati" a meno che questi non siano oggetto del progetto stesso, inclusi nel file zip inviato e chiaramente indicato.

- DEVE compilare: Quando il WebMaster preme CTRL+F5 (compilazione completa) il progetto si deve avviare senza alcun errore.

- DEVE essere progettato il più genericamente possbile per funzionare nelle più svariate condizioni, fatta salva esplicita indicazione.
Esempi:
- Nel codice non possono esserci riferimenti espliciti alla cartella "C:\WINDOWS\" che può variare da PC a PC.
- E' invecie ammesso che un progetto funzioni solo su WindowsXP® poichè sfrutta alcune sue peculiarità, ma questo DEVE essere indicato chiaramente.

- NON DEVE contenere moduli, form, classi, componenti o riferimenti che non sono utilizzati.

- Il nome del file inviato NON DEVE contenere spazi, per evitare problemi con il download.

Regole per i progetti "pronti all'uso"

Questo tipo di progetto DEVE avere tutti i requisiti sopra descritti e DOVREBBE semplicemente limitarsi alle regole di buona programmazione:

- DEVE essere scritto con l'indentazione del codice.
Non sono accettati listati con allineamento a sinistra simili a un tema.

- DOVREBBE utilizzare esplicitamente le proprietà dei controlli.
E buona norma che venga sempre indicata la proprietà a cui ci si sta riferendo, scrivendo Text1.Text = "ciao" e non Text1 = "ciao".
Questo è tanto più importante se si tratta di un progetto "educazionale": non è educativo insegnare che un oggetto può diventare una stringa.

- DEVE essere autosufficiente.
"Pronto all'uso" significa che posso prendere il progetto (o il controllo, la classe, il modulo oggetto del materiale inviato) lo inserisco nel mio programma e questo funziona.
NON DEVE cioè perdere funzionalità (o peggio, non funzionare più) se viene cambiato il contesto di esecuzione.

- DOVREBBE essere presente file (.doc, .txt, .rtf, .html, .pdf, .hlp) che spiega come usare il progetto inviato.
Ricorda che il Sito Comune non è un magazzino dove accatastare i progetti ci avanzano.
Deve essere usato e considerato come una risorsa preziosa per noi e per gli altri.
E' importante per tutti che sul Sito Comune ci sia materiale di qualità.

Regole per i progetti "educazionali"

Un progetto "educazionale" DEVE seguire le regole generali e DOVREBBE avere tutte caratteristiche di un progetto "pronto all'uso".
Inoltre, proprio perchè il suo scopo è quello di insegnare a programmare in Visual Basic, il suo codice deve essere sottoposto ad ulteriori attenzioni.

- DEVE essere commentato.
Se il codice fa qualcosa (e si spera che lo faccia) si deve spiegare cosa fa, come, perchè lo fa così e qual è lo scopo di ogni blocco di codice.
In generale si dovrebbe inserire un commento che indichi lo scopo di ogni sub e funzione, e per ogni micro-blocco della sub o funzione aggiungere ulteriori commenti più dettagliati.
Vedi anche le convenzioni per scrivere codice Visual Basic

- DEVE essere presente un file (.doc, txt, rtf, html, pdf, hlp) che spieghi il problema che si intende affrontare, come lo si affronta ed eventuali link o suggerimenti per approfondire l'argomento.

Adesso, se hai spuntato tutti i punti di questa check list contrassegnati da un "DEVE", confrontandoli con il materiale che stavi per inviare, significa che con tutta probabilità questo materiale verrà pubblicato.
Se ti manca qualcuno di questi punti correggi il tuo progetto e riprova.