[Linux-Biella] Mio Script: Tabella RGB

[Daniele Segato]

On Tue, 2009-01-27 at 19:51 +0100, Del Vecchio Lorenzo wrote:
> Non sapevo si definisse identazione la tecnica di cui parli ed ignoravo
> fosse una vera e propria regola (magari non scritta nei manuali).
> 
> E' a discrezione o esistono vere e proprie regole??
> Ad es. oltre a quelle qui riportate:
> 
> http://it.wikipedia.org/wiki/Indentazione
> 
> Ossia esiste una regola tipo tre spazi a inizio ciclo, due se annidato
> ecc. o si va un po' a discrezione??


sono regole di buona programmazione

il codice deve essere leggibile e possibilmente commentato dove non è
ovvio ciò che viene fatto.

il che serve se qualcun altro dovrà mettere mano al tuo codice ma serve
anche a te se dovessi riprenderlo in mano dopo un po' di tempo

indentare significa, in sostanza, scrivere ordinato: facendo in modo che
sia chiaro anche visivamente le relazioni contenitore/contenuto

esempio:

ad un compilatore non frega nulla com'è indentato il codice (a meno che
non sia python)

ma se non indenti bene un codice verrai considerato un programmatore
scarso da chiunque senza neppure guardare cos'hai scritto

tu chiedi 3 o 4 spazi
e io ti dico:
chissenefrega!

basta che adotti una convenzione e la mantieni

in genere segli un carattere o un insieme di caratteri per indentare
ci sono diverse scuole di pensiero
1) TAB = un indentazione (io sono per questa)
2) 4 spazi = un indentazione
3) 8 spazi = un indentazione

scegline una e usala in tutto il tuo codice o adattati a quella del
progetto su cui stai lavorando
tutti gli editor di testo seri ti lasciano impostare questa cosa

altre buone regole di programmazione sono:

a) evitare i nomi di variabili che non fanno capire cos'è la variabile
(es. k+w/(f-h) = ???? che cazzo sta facendo questo ????) o per lo meno
spiegare cosa sono le variabili (ad esempio se è una formula fisica dove
k è una costante, w una velocità angolare, f una forza e h un'altra
costante ci può anche stare... [anche se non esiste credo una formula
del genere])
b) adotta una convenzione per le parentesi o adattati a quella del
progetto e seguila

if (...) {
    // stuff here
}

oppure
if (...)
{
    // stuff here
}

c) se stai programmando ad oggetti in genere si mettono prima tutti i
metodi e dopo tutte le variabili di classe

d) un metodo/funzione non dovrebbe mai essere troppo lungo, se è troppo
lungo stai scrivendo codice non riusabile! Spezzalo in più funzioni.

e) se stai usando più di 3-4 incapsulamenti nello stesso metodo hai
pensato male la cosa nella maggior parte dei casi

esempio:
for (...) {
    if (...) {
        for(...) {
             while(...) {
                  if(...) {
                       // codice illeggibile e mal pensato
                  }
             }
        }
    }
}


comunque cerca "best practice" per il linguaggio da te scelto. Cerca di
seguirle e il resto viene con l'esperienza