Introduzione.

Questo post è indirizzato esclusivamente ai programmatori che abbiano interesse ad orientarsi nel codice sorgente di BEEing.
Per migliorare la lettura del codice ed il lavoro in team, abbiamo definito alcune semplici specifiche che vanno dalla definizione dei nomi delle variabili, dei metodi, ecc.. alla struttura dei package.

Specifiche:

NOMI COMPOSTI:

Java impone che i nomi di metodi,di variabili … vengano scritti con l’iniziale minuscola.
Se sono nomi composti, ogni nuova parola deve iniziare con la lettera maiuscola.

***************************************************************
setPostName(final String postName){
…..
…..
}
***************************************************************

DIVISIONE ALL’INTERNO DEI PROGETTI:

Il codice sorgente di BEEing è organizzato in packages ed in cartelle.
La divisione in cartelle rispetta le specifiche del pattern MVC (Model View Control), e separa nettamente GUI (View),  Model e Controller:

• GUI: Parte di grafica. Spesso viene fatta un ulteriore divisione in GUI_WIDGETS, GUI_COMPONENTS, GUI_WINDOWS…
• MODEL: Sezione relativa al Database.
• CONTROLLER: Cartella destinata a contenere classi di utiliti, classi astratte …

***************************************************************

NOMI DEI PACKAGE:

In BEEing si è scelto di definire in nomi dei package in questo modo:

Prima parte: org.sf.bee.

Seconda parte: nome del progetto o identificativo della sezione: (esempio search, admin, wiki …);

Terza parte: nome della cartella in cui si trova il package: gui (se si trova in una cartella GUI), gui.components (se si trova nella cartella GUI_COMPONENTS);

Quarta parte: components, widgets, windows a seconda del tipo di componente. Non viene inserita se è già stata specificata al terzo punto;

Quinta parte: pagectrls, nel caso si tratti di un componente che funga da controller della pagina. In questo modo è molto facile distinguere tra classi principali e classi secondarie.

Sesta parte: nome esplicito ed identificativo della funzionalità della classe. Tutto in minuscolo e senza separatori.
ESEMPIO:

***************************************************************

UTILIZZATE NOMI INTELLIGENTI:

Scrivendo i nomi chiaramente non avrete bisogno di scrivere commenti troppo descrittivi.
Esempi di nomi per i metodi:
doSave, doRemove … –> il prefisso do rende l’idea di un’azione, quindi può essere utilizzato per i metodi chiamati al click su un bottone, su un link …;

getText, getName … –> il prefisso get, in italiano “dammi”, dedicatelo a quei metodi che devono restituire qualcosa;

setText, setName … –> viceversa adoperate la parola set, in italiano “imposta”, per quei metodi che devono inizializzare o aggiornare dei dati (normalmente vengono passati, come argomenti, i dati da aggiornare);

init, initComponents… –> il prefisso init dev’essere utilizzato per indicare una inizializzazione. Normalmente tutti i metodi che iniziano con init vengono posti vicini nel codice.

E’ buona norma che i metodi abbiano una lunghezza massima intorno alle 15 righe. Quando iniziano ad essere 20 – 30 sarebbe buona norma pensare di dividere i metodi in due o più; in questo modo sarà più facile manutenere e debuggare il codice.

Un’altra tecnica spesso utilizzata per aver maggiore chiarezza consiste nell’inserire delle righe bianche per dividere le varie parti di un metodo.

***************************************************************

CURARE LA FORMA:

Cercate di dichiarare le variabili sempre prima del codice così da poterle ritrovare facilmente. –>
Utilizzate sempre le costanti (nome della variabile tutto maiuscolo). –>
Quando potete, anteponete al tipo di variabile la keyword final. –>


Andiamo nel dettaglio…

Cercate di dichiarare le variabili sempre prima del codice così da poterle ritrovare facilmente.

Utilizzate sempre le costanti (nome della variabile tutto maiuscolo).

All’interno di una classe (Prova.java):
public static final String BTN_ADD = “btnAdd”;
All’interno di un’altra classe che debba utilizzare lo stesso bottone della classe Prova (Test.java):
public static final String BTN_ADD =  Prova.BTN_ADD;
In questo modo non dovrete ricercare per tutta la classe (o addirittura su più classi) una stringa da modificare (es. da “btnAdd” a “btnNew”), basterà farlo per una sola costante.

Formattate bene il codice; molti strumenti di sviluppo offrono delle funzioni che consentono una strutturazione automatica.

Quando potete, anteponete al tipo di variabile la costante final.

L’applicazione della keyword final alle variabili è un’ottimizzazione in quanto constente di allocarle direttamente in memoria così che possano essere reperite più velocemente.
Naturalmente comporta alcune limitazioni, in quanto dopo la dichiarazione, potrete inizializzare la variabile UNA sola volta.

Applicando final ad una classe, impedisce la creazione di sottoclassi (N.B. non confondere il concetto di sottoclasse, subclass, con istanza della classe).

Se applicata ai metodi ne impedisce l’override.

Alcune variabili, quelle relative ai componenti grafici, è buona norma inizializzare SOLO una volta per ogni istanza di classe.

L’utilizzo di questo metodo comporta i seguenti vantaggi:
- performance migliori
- drastica riduzione di null pointer exception e di pagine bianche.
Mal che vada, non vedendo il componente, potrete farvi immediatamente un’idea su chi ha originato l’errore.

AUTORE: Roberto Fratti