ElectroYou

Un saluto a tutti i partecipanti.

Prima di programmare in C ho imparato e lavorato molto con il pascal dove i blocchi vengono definiti ed allineati in un certo modo e questo motivo in C scrivo i blocchi così, che mi sembra un modo logico di scriverli.

Codice: Seleziona tutto

if (a==1)
{
  // esegue se a è uguale a 1
}
else
{
  // esegue se a è diverso da 1
}

Come da oggetto sono curioso di sapere per quale motivo (perché ci deve essere per forza un motivo pratico) oggi le parentesi graffe nel C vengono usate in questo modo:

Codice: Seleziona tutto

if (a==1) {
   // esegue se a è uguale a 1
   }
else {
   // esegue se a è diverso da 1
   }

Mi piacerebbe sapere anche chi ha introdotto questo modo di scrivere i programmi.

personalmente è una preferenza di raggruppamento (visivo) di codice.

preferisco avere linee di codice non separate... e separare con una linea vuota parti di codice che fanno cose differenti. Lasciare una linea vuota (perché è così che la vedo io) con solo una graffa dentro disperde il codice...che oltretutto mi costringe a scorrere la pagina molto di più...

È una questione di gusto. La indentazione da te scelta è quella che preferisco, l'altra mi incasina la vita, e la odio, ossia la seconda...

L' ho domandato perché circa 15 anni fa (se non vado errato) la GNU (o la FSF?) suggerì, anzi lo impose come regola, un sistema d' indentazione per la stesura dei sorgenti in C di questo tipo (i punti li ho messi altrimenti mi elimina gli spazi iniziali):

Codice: Seleziona tutto

. if (a==1)
.   {
.     // esegue se a è uguale a 1
.     b = 2;
.   }
. else
.   {
.     // esegue se a è diverso da 1
.     b = 3;
.   }

che è ancora più bizzarro. Due spazi dalla "if" e poi la parentesi graffa ed all' interno del blocco altri due spazi.
Quindi mi chiedevo se nuova la posizione delle graffe che ho illustrato nel primo esempio fosse stata suggerita o imposta da qualcuno.

Mah!

Le parentesi graffe vengono usate anche in altri linguaggi tra cui varie shell di unix.
Sono d'accordo con crestus e [user]gohan[/user] che sia una questione di gusti, io addirittura la preferisco così

Codice: Seleziona tutto

if (a==1)
      {
       // esegue se a è uguale a 1
       }
    else
      {
       // esegue se a è diverso da 1
       }
endif


per la ragione che, avendo vari livelli annidati di parentesi, è più facile vedere se sono aperte/chiuse correttamente.

Sono d' accordo, io uso tabulazioni a 2 spazi ma proprio non riesco a capire il senso della graffa di inizio blocco sulla stessa linea della "if" e la graffa di chiusura isolata. Di sicuro è un mio limite ma mi crea confusione.

Per quanto mi riguarda utilizzo questo sistema di indentazione:

Codice: Seleziona tutto

if (a == 1) {
    b = 2;
} else {
    b = 0;
}

lo trovo più compatto e riesco a vedere bene gli annidamenti e c'è coerenza tra i "blocchi" di codice.
Altro esempio:

Codice: Seleziona tutto

if (a == 1) {
    b = 2;
    if (c == 0) {
        if (d == 10) {
            if (e == 9) {
                ey = 42;
            }
        }
    }
} else {
    b = 0;
}

Programmando molto più in Python (dove l'indentazione è OBBLIGATORIA) che in C, il mio editor segue le raccomandazioni del PEP-8, quindi, per esempio, 4 spazi per ogni livello di indentazione e righe lunghe al massimo 79 caratteri e uno spazio "intorno" agli operatori logici o artimetici.

Su Linux and company c'è la tool indent per la identazione automatica. Ma io uso sempre una tabulazione di 3 e la graffa sempre a capo e tutte in linea tra loro..
Ossia la prima usata da TardoFreak nel primo messaggio

Prima utilizzavo questo modo:

Codice: Seleziona tutto

    if (a == 1) {
        b = 2;
        if (c == 0) {
            if (d == 10) {
                if (e == 9) {
                    ey = 42;
                }
            }
        }
    } else {
        b = 0;
    }

Poi, circa cinque anni fa, a seguito di una necessità di uniformare la stesura del codice nel mio gruppo di programmatori, sono passato a questo modo:

Codice: Seleziona tutto

   if (a == 1)
   {
      b = 2;
      if (c == 0)
      {
         if (d == 10)
         {
            if (e == 9)
            {
               ey = 42;
            }
         }
      }
   } else {
      b = 0;
   }


Personalmente, preferisco il secondo metodo: l'allineamento tra le parentesi {} mi aiuta a vedere immediatamente i blocchi.

Ciao.

Paolo.

angus ha scritto:Per quanto mi riguarda utilizzo questo sistema di indentazione:

Utilizzo, in C, C++ e Java, esattamente lo stesso modo di indentare descritto da angus. L'unica eccezione è che quando inizio una funzione metto la graffa subito a capo.
Ecco un pezzo del codice di FidoCadJ:

Codice: Seleziona tutto

    /** Draw the handles of all selected primitives
        @param G the graphic context to be used.
    */
    public void drawSelectedHandles(Graphics2D G, MapCoordinates cs)
    {
        int i;
        for (i=0; i<primitiveVector.size(); ++i){
            if(((GraphicPrimitive)primitiveVector.get(i)).getSelected())
                ((GraphicPrimitive)primitiveVector.get(i)).drawHandles(G,
                   cs);
        }     
    }


Semmai la cosa dovesse invogliare qualcuno, ecco un pezzo del README associato ai sorgenti di FidoCadJ, in cui ho specificato lo stile da adottare:

Codice: Seleziona tutto

3.4 Coding conventions
----------------------

The following coding conventions have been applied for the FidoCadJ source
code:

- tab set to 4 spaces
- blocks delimited by curly braces are indented as follows:

    for(i=0; i<10; ++i) {   // starting brace here
        // indented code (4 spaces)
        System.out.println("I counted up to "+i);
    }   // close brace here at the same level of the 'if'
   
- methods are indented as follows:

    void dummy (int i, int j)
    {   // put the starting brace here
        System.out.println("Indent code");
    }   // put the closing brace here

- the class names always start with a capital letter, and so does methods
- variables never start with a capital letter
- an instance of the class does have its first letter in lower case
- each public class and method should be documented with Javadoc syntax
- no lines longer than 80 characters
- commits should not break the build