Vecchia discussione con proposte di realizzazione e sondaggi

[cdimauro]

x fek

if (condizione)
{
}
else if (condizione)
{
}
else
{
}

Oppure (a seconda dei casi):

if (condizione)
{
}
else
    if (condizione)
    {
    }
    else
    {
    }

Ti farebbero schifo?

[fek]

Originariamente inviato da cdimauro

x fek

if (condizione)
{
}
else if (condizione)
{
}
else
{
}

Oppure (a seconda dei casi):

if (condizione)
{
}
else
    if (condizione)
    {
    }
    else
    {
    }

Ti farebbero schifo?

Si', per due motivi

1) Se hai una catena di if/else lunga, ti ritrovi a scrivere sul monitor del vicino
2) I vari if hanno la stessa importanza logica e l'indentazione dovrebbe rifletterlo

Ma in realta', se scrivete una catena di if/else la complessita' ciclometrica sale e ci sono ottime possibilita' che ve lo faccia riscrivere.

[DanieleC88]

Originariamente inviato da fek

Io userei tab veri da 4 spazi. Vicius?

[^TiGeRShArK^]

Originariamente inviato da fek

E' un make con steroidi.

infatti ti ho visto un pò sovreccitato ieri sera mentre lo usavi!

[fek]

Originariamente inviato da ^TiGeRShArK^

infatti ti ho visto un pò sovreccitato ieri sera mentre lo usavi!

Ahaha vero.

Ok. Punto della situazione.

I due Customer (Maax e Raoul) stanno avendo dei problemi. In attesa di capire se dobbiamo trovare un nuovo customer, faccio io da Customer ad interim (uff) e Vicius fa da Coach durante la scrittura delle storie.

Se Vicius e' disponibile stasera, iniziamo a buttare giu' le storie e poi dividiamo in task. Poi seguira' il piano di sviluppo per le prime due settimane.

Si parte

[71104]

Originariamente inviato da fek

Si', per due motivi

1) Se hai una catena di if/else lunga, ti ritrovi a scrivere sul monitor del vicino

una catena if-else lunga corrisponde a uno switch...

Ma in realta', se scrivete una catena di if/else la complessita' ciclometrica sale e ci sono ottime possibilita' che ve lo faccia riscrivere.

quindi è meglio che nel codice non usiamo gli switch
tra l'altro ad ogni case corrisponde un nuovo possibile pattern del codice, dico bene?

[fek]

Originariamente inviato da 71104

una catena if-else lunga corrisponde a uno switch...

if (x > 0.0f && x < 1.0f)
{
}
else
if (x >= 1.0f && x < 2.0f)
{
}
else
if (x >= 2.0f && x < 3.0f)
{
}

[VICIUS]

Originariamente inviato da cdimauro

Ti farebbero schifo?

Endline layout. No grazie.

In ogni caso continuo a sostenere che il mio stile è piu chiaro. "Pure blocks" mostra meglio la struttura logica del programma e non sono il solo a pensarla cosi. Sono sicuro che se apro code complete riesco a trovare un qualche cosa per convincere anche fek

ciao

[fek]

Originariamente inviato da VICIUS

Endline layout. No grazie.

In ogni caso continuo a sostenere che il mio stile è piu chiaro. "Pure blocks" mostra meglio la struttura logica del programma e non sono il solo a pensarla cosi. Sono sicuro che se apro code complete riesco a trovare un qualche cosa per convincere anche fek

ciao

Per McConnel la posizioen della parentesi e' questione di gusto personale ed entrambe le versioni sono corrette

[VICIUS]

Originariamente inviato da fek

Per McConnel la posizioen della parentesi e' questione di gusto personale ed entrambe le versioni sono corrette

Devo avere una copia buggata allora:

Listing 31-24. Java example of unindented begin-end pairs.
for ( int i = 0; i < MAX_LINES; i++ )
{
    ReadLine( i );
    ProcessLine( i );
}
Although this approach looks fine, it violates the Fundamental Theorem of For-
matting; it doesn’t show the logical structure of the code. Used this way, the
begin and end aren’t part of the control construct, but they aren’t part of the
statement(s) after it either.

Listing 31-25 is an abstract view of this approach:
Listing 31-25. Abstract example of misleading indentation.
A XXXXXXXXXXXXXXXXXX
B XXXX
C   XXXXXX
D   XXXXXXXXX
E XXXX
In this example, is statement B subordinate to statement A? It doesn’t look like
part of statement A, and it doesn’t look as if it’s subordinate to it either. 
If you have used this approach, change to one of the two layout styles 
described earlier, and your formatting will be more consistent.

Specialmente le utlime righe sono piuttosto chiare.

ciao

[fek]

Originariamente inviato da VICIUS

Devo avere una copia buggata allora:

No, ho capito male io quello che dicevi.

Listing 31-24. Java example of unindented begin-end pairs.
for ( int i = 0; i < MAX_LINES; i++ )
{
    ReadLine( i );
    ProcessLine( i );
}

Se ricordo bene suggerisce questa versione:

for ( int i = 0; i < MAX_LINES; i++ )
  {
      ReadLine( i );
      ProcessLine( i );
  }

Che personalmente odio a morte
Perche' contravviene l'altro principio secondo il quale la formattazione dev'essere comoda. Trovo piu' scomodo indentare due volte.

[VICIUS]

Originariamente inviato da fek

Che personalmente odio a morte
Perche' contravviene l'altro principio secondo il quale la formattazione dev'essere comoda. Trovo piu' scomodo indentare due volte.

Sulla mia vicino a questa c'è un bel coding horror.

ciao

[fek]

Originariamente inviato da VICIUS

Sulla mia vicino a questa c'è un bel coding horror.

ciao

Il Coding Horror e' nel mio cervello. Me lo sono giocato negl'ultimi mesi.

[VICIUS]

Originariamente inviato da fek

Il Coding Horror e' nel mio cervello. Me lo sono giocato negl'ultimi mesi.

Il sistema sanitario da voi non copre lo stress da troppo debug ?

ciao

[DanieleC88]

Originariamente inviato da fek

Che personalmente odio a morte

Ci vuole di nuovo: .

[71104]

Originariamente inviato da fek

Il Coding Horror e' nel mio cervello.

siamo in due
il mio avatar è esplicativo

[^TiGeRShArK^]

io comunque voto per questa:

for (int i = 0; i < 5; i++){
    if (umanity.isCorrupted() == true)
        reInitializeWorld();
    else
        doNothingForAThousandYear();
}

perchè la parentesi messa a fianco del for la noti subito e capisci che quello che c'è dopo fa parte dello stesso ciclo.
Invece in questo modo:

for (int i = 0; i < 5; i++)
{
    if (umanity.isCorrupted() == true)
        reInitializeWorld();
    else
        doNothingForAThousandYear();
}

c'è una "discontinuità" tra il for e il suo contenuto.
Se mi dite che non si nota subito l'inizio del ciclo nella prima versione non è assolutamente vero....basta farci un attimino l'occhio e poi risaltano molto di piu' le parentesi a fine riga.

Cmq alla fine decidete voi, ma tenete conto anche del mio voto!

[cionci]

Personalmente non metto lo spazio dopo if, for, while etc...per il resto faccio come fek...

[Gica78R]

Originariamente inviato da fek

No, ho capito male io quello che dicevi.



Se ricordo bene suggerisce questa versione:

for ( int i = 0; i < MAX_LINES; i++ )
  {
      ReadLine( i );
      ProcessLine( i );
  }

Che personalmente odio a morte
Perche' contravviene l'altro principio secondo il quale la formattazione dev'essere comoda. Trovo piu' scomodo indentare due volte.

Questa cosa qui, Jed la fa da solo; se sei su una riga, e inserisci una {, va automaticamente a capo indentando del giusto numero di spazi, e poi porta il cursore alla riga successiva, indentando nuovamente. Se provi a chiudere la graffa dopo un' istruzione, cioe' se provi a fare questo:

i++; }

ti sposta la } a capo, in coincidenza con quella aperta precedentemente e porta il cursore alla riga successiva. Non puoi sbagliare, e non devi ricordarti nulla. Se indenti malamente (di proposito o no), poi ti basta ripercorrere il codice, premendo TAB ad ogni riga: Jed la sposta automaticamente al posto giusto, dopodiche' successive pressioni del TAB non hanno nessun effetto!

[cionci]

Ma Eclipse la fa l'indentazione automatica, il completamento automatico e il class browser quando si preme si fa il . ?