[Linux-Biella] Mio Script: Tabella RGB

[Paul TT]

Daniele Segato wrote:
> 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!
>   
io invece dico: 8, come un tab
(anche se invero per il web meglio metter meno spazi ;P)
e dico: leggi Documentation/CodingStyle nei sorgenti del kernel ;P
(e capirai anche il perche' degli 8 spazi)
> 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)
>   
che corrisponde a 8 spazi, infatti conviene usare _un_ tab, che e' un 
carattere solo ma indenta come deve ;P
> 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
>
>   
tutte cose ben spiegate nel CodingStyle da linus
giuste

-- 
La Compagnia de' Viaggiatori in Arme e' un libro:
http://www.lacompagniadeviaggiatoriinarme.it/