Newsgroup: it.comp.lang.c++
Titolo: questione di stile, solamente?

Da tempo mi chiedo se certi stili di programmazione consolidati non
derivino da considerazioni che vanno oltre il semplice "gusto
personale".
esempio, c'è chi scrive:
if(condizione) {
   //statement
}
else if(condizione2) {
   //statement
       }
e chi scrive
if(condizione)
{
   //statement
}
else
   if(condizione2)
   {
       //statement
   }
è solo una questione di gusti o effettivamente uno stile è migliore
dell'altro perché rende più facili *certe cose*? Per esempio, molti
miei errori derivano dal perdere il filo quando ho una cascata di if
else innestati... In fondo anche la scelta del nome delle variabili
può portare a un codice più leggibile, quindi migliore.
il_t@sso
il_t...@freemail.it

 può portare a un codice più leggibile, quindi migliore.
Anche secondo me allineare bene le graffe aiuta a vedere a colpo
d'occhio l'inizio e la fine dei blocchi. Per quanto riguarda i nomi,
ritengo la loro corretta scelta una cosa fondamentale.
EMG

può portare a un codice più leggibile, quindi migliore.
Compra il libro di Pescio segnalato nelle faq
(su 
www.programmazione.it
) ne vale la pena e ti sara`
utilissimo.
Paolo
-----------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
-----------------------------------------------

può portare a un codice più leggibile, quindi migliore.
Senz'altro!! Ovviamente non bisogna mai esagerare con dei nomi delle
variabili troppo lunghi, ma nemmeno si può usare variabili composte da
una sola lettera, che rendono il listato confuso e poco chiaro. Io ad
esempio se ho bisogno di una variabile 'contatore' la chiamo 'cont',
oppure 'contat' di modo che sia almeno chiaro che si tratta di un
contatore. Se invece la chiamassi invece 'c' oppure 'ct' , sarebbe
molto più difficile identificare lo scopo della suddetta variabile,in
particolare se si rimette le mani sul listato dopo molto tempo. Un
altro ottimo sistema per rendere il programma chiaro é quello di
abbondare con le righe di commento, che ovviamente vanno utilizzate in
modo intelligente e non certo a casaccio.
Il Ghenio
-----
Proteggeremo il mondo della devastazione!
Uniremo tutti i popoli nella nostra nazione!
Denunceremo i mali della verità e dell'amore,
Estenderemo il nostro potere fino alle stelle.
Jesse!
James!
Team Rocket pronto a partire alla velocità della luce.
Arrendetevi subito oppure preparatevi a combattere.
Miaaaoooo, proprio cosi'!
(Team Rocket)
-----

 relativa a quella chiusa o viceversa. Ora che ho un 19" e mi sento in
Pur avendo un 19", avevo le stesse abitudini. Dopotutto erano sempre solo 25
righe visualizzabili per volta, meno i menu, la barra di stato, ecc.
Io scrivevo (e scrivo) quindi:
if (...){
    ...
}else{
    ...
}
Risparmiavo quindi 2 righe.
Ovviamente:
if (...){
    ...
} else if (...){
    ...
}
che non mi sembra perda in leggibilità.
Per le stesse ragioni scrivo anche:
... funzione (...){
...
}
e non rientro il codice della funzione, perchè anche gli 8 caratteri a
sinistra mi facevano comodo. Piuttosto però dividevo le funzioni da cose del
tipo:
/* ******
    Commento
****** /*
... funz (...){
...
}
o anche da solo una riga con qualche carattere "pieno", se un commento non
serviva, quel che basta, insomma, per vedere subito dove inizia una funzione
scorrendo il testo con PgUp e PgDn.
--
Alessandro Monti

 che non mi sembra perda in leggibilità.
Idem.  Kernighan e Ritchie formattavano cosi` (un po' tutti ai Bell Labs,
credo), e non
vedo ragione di usare uno stile diverso anche se questo monitor ha un
miliardo di
pollici (iperbole...:-) -- ogni riga non-sprecata per evidenziare quella
_goffaggine_
sintattica che sono le graffe e` una riga in piu` da investire in commenti,
spazio
bianco per evidenziare i blocchi, e cosi` via.
Non concordo invece sull'indenting (che faccio comunque di 4 caratteri, non
di 8,
per cui un livello in piu` non mi uccide...:-).
"Tot capita, tot formattationes"!-)  Questo e` uno degli enormi vantaggi di
produttivita` di Python -- evitando le graffe, e imponendo l'indent per
segnalare
i blocchi, taglia le discussioni in merito, risparmiando ore e ore per usi
piu`
produttivi:-).
Alex

produttivi:-).
Ma allora è proprio consolidata questa tua infatuazione (stavo
scrivendo formattazione !-) ) per python!
:-)
il_t@sso
il_t...@freemail.it

}
Lo faccio per le classi, metto una breve descrizione riguardo il
significato e l'obiettivo. A volte lo faccio 
anche per i metodi, ma di solito cerco nomi piuttosto espliciti.
Paolo
--------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
--------------------------------------------------

 probabilmente conviene usare il tab (impostandoti la corrispondenza
Si, io usavo il tab. Parlo di 8 caratteri perchè poi, inviando il file alla
stampante, veniva comunque convertito in 8 caratteri, perdendo quindi la
formattazione che avevo a video (settando, per esempio, la dimensione del
tab in 2 caratteri).
Poichè mi capitava spessissimo di dover stampare i listati, anche parecchio
lunghi (vi ricordate la comodissima funzione del DOS che stampava in
background?), volevo che la formattazione rimanesse come l'avevo vista sul
monitor.
Certo avrei potuto creare un filtro...anzi, l'avevo anche fatto, ma non mi
veniva mai in mente di usarlo :-)))
Comunque il tab di 8 caratteri aiutava ance a mantenere semplici le
espressioni all'interno delle righe e anche il più semplici possibili le
funzioni (più complessità, più indentazione, anche se non sempre è vero).
--
Alessandro Monti

ore per usi piu` produttivi:-).
Effettivamente le "guerre di religione" sono una gran perdita di tempo. Qualora
la "forzatura" imposta dal linguaggio non rappresenta svantaggi evidenti ed
obbiettivi, è quasi sempre una posizione vincente, imho.
AB
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Andrea Baruzzo
Via Circonvallazione, 26
Muzzana del Turgnano (UD) - Italy
e-mail: 
andrea....@ud.nettuno.it
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

che non mi sembra perda in leggibilità.
Io aggiungo un po' di spazi:
if (...) {
} else if (...) {
}
Ad ogni modo, puo' essere interessante (oltre che utile) la lettura del file
/usr/src/linux/Documentation/CodingStyle, per chi ha linux (ma di certo si
trova anche in rete), che da' alcune direttiva ai programmatori che
intendono contribuire allo sviluppo del kernel.
Saluti,
    Mardy

 Effettivamente le "guerre di religione" sono una gran perdita di tempo.
Infatti io continuo ad utilizzare
if ( cond )
{
    // blocco
}
e me ne frego di tutto quanto è stato detto. :-)))
EMG

...

Ciao EMG!
Sono d'accordo. Se ti trovi bene non c'è motivo di cambiare abitudini, a meno
che tu non lavori in team e il team abbia convenzioni diverse. Quello che conta
è essere produttivi e chiari.


e me ne frego di tutto quanto è stato detto. :-)))
Ovviamente anch'io!!


> >e me ne frego di tutto quanto è stato detto. :-)))
Credo che il problema non fosse posto nel senso di dire che TUTTI devono
usare una indentazione piuttosto che un'altra, ma solo uno scambio di
opinioni.
--
Alessandro Monti

Alessandro Monti ha scritto nel messaggio ...

Esattamente, almeno per quello che mi riguarda.
Come detto, non amo le guerre di religione. Amo invece i due riferimenti che ho
citato in quanto presentano un atteggiamento *critico* e non arbitrario a questa
come a molte altre decisioni di stile e di design. Poi, ovviamente, ognuno opta
per quello che preferisce.


Non conosco i libri che citi e mi rendo conto che un post non e'
abbastanza ampio per descriverne i principi in modo esauriente.
Superficialmente pero' mi pare un modo per giustificare in modo pseudo
formale una preferenza collettiva. D'altra parte non credo che noi
informatici siamo la categoria piu' adatta per analizzare un meccanismo
che coinvolge elementi di percezione e cognizione piu' che non aspetti
veramente tecnici-informatici.
In realta' penso che lo stile di indentazione sia un problema molto
legato al gusto ed all'esperienza personale e che sarebbe opportuno che
gli ambienti di sviluppo permettessero a ciascuno sviluppatore di
esaminare, modificare e stampare il codice indentato secondo le sue
preferenze. Non so se esistano IDE che fanno questo. Il vecchio "indent"
Unix era gia' qualcosa, ma la sua natura di filtro mal si adatta ad
ambienti integrati.
Mi domando se in settori dove gli ambienti integrati hanno maggior
tradizione che in C++ e dintorni queste cose non esistano gia' da un
pezzo: penso a Lisp e Smalltalk.
Ciao,
Nicola
P.S. Io indento come segue, con TAB impostato a quattro spazi.
if ( condizione )
{
    statement++;
}
else
{
    statement--;
}
Trovo che questo stile separa adeguatamente l'istruzione di controllo
(l'if) dai diversi blocchi che contiene e rende piu' facile verificare a
colpo d'occhio se le graffe combaciano.

 pezzo: penso a Lisp e Smalltalk.
Ad esempio, in Visual Basic è impossibile scrivere
a=1
o
a  = 1
ab = 2
in quanto l'editor ti cambia al volo gli spazi e ti ritrovi con
a = 1
o
a = 1
ab = 2
Direi che non è una buona cosa. Molto meglio la libertà del C/C++.
EMG

E direi! Io parlavo di impostazioni a scelta dell'utente, mica a scelta
di Bill Gates! Semplicemente vorrei un editor che supportasse
automaticamente il *mio* stile di indentazione, e siccome non pretendo
che tutti vi si adeguino (anche se farebbero bene! :-) trovo
indispensabile che questo tipo di meccanismo sia configurabile, nonche'
applicato dinamicamente piuttosto che salvato nel file sorgente. Non
dovrebbe essere un problema di pasticciare il codice degli altri, quanto
di esaminarlo ciascuno nella forma che preferisce.
Ciao,
Nicola

P.S. Io indento come segue, con TAB impostato a quattro spazi.
Il vantaggio del tab e` che tu puoi impostarlo a 4, ma se io lo imposto
a 2, il layout del codice non ne risente, il livello di chiarezza
permane.


Direi che non è una buona cosa. Molto meglio la libertà del C/C++.
Direi che e` meglio perche` se in altri linguaggi sei abituato a
"regole" diverse, puoi continuare a seguire le tue riadattando solo
il minimo indispensabile.


>e me ne frego di tutto quanto è stato detto. :-)))
Anche a me piace molto questo stile, lo trovo il piu' lineare possibile, 
e sopratutto, visivamente espressivo...(a volte la graffa sulla stessa 
riga viene "persa" nei meandri di istruzioni nidificate)
-- 
God@Universe#~>shutdown -r,
  . 
darX...@tin.it
      . 
star...@wappi.com
 (GSM SMS)
   . Fido 2:335/241.5     . 
http://darxstar.cjb.net
    . ICQ UIN# 11151997    . Britannia: UO-T2A,Trisinc, Gwydion the Mage
---
 " I don't want to die,
 I sometimes wish I'd never been born at all "
                                    -- the Queen

ambienti integrati.
Come già detto da altri, finché sei da solo tutto fila liscio. In un lavoro in
team le cose precipitano senza una "standardizzazione" che non si deve fermare
al solo lay-out, ovviamente.
