2011-01-09 11 views
10

Esempio: Thread::Thread:Come dovrei fare indentazione senza costruttori di elenchi di inizializzazione?

class Thread 
{ 
    Process * parent_; 
    unsigned __int32 id_; 
    void * entryPoint_; 
public: 
    Thread(Process * parent, unsigned __int32 id, void * entryPoint) : 
     parent_(parent), 
     id_(id), 
     entryPoint_(entryPoint) 
    { 
    } 
    unsigned __int32 GetId() const 
    { 
     return id_; 
    } 
    void * GetEntryPointAddress() const 
    { 
     return entryPoint_; 
    } 
}; 

io non riesco a venire con un modo di rientro cose in modo che non sembra strano ... eppure si tratta di un modello comune. Quali sono i modi più comuni per indentare questo?

+0

Come ho già risposto a domande come questa: Fintanto che sei coerente, non importa. :) (Detto questo, sono curioso del motivo per cui pensi che sia strano. Mi sembra perfetto per me :): – greyfade

+0

metti tutto in una riga e non pensarci! : D – ybungalobill

+1

@greyfade: parte dell'essere coerenti è fare ciò che fanno gli altri. Non ho mai visto nessuno esprimere un'opinione su questo, quindi ho chiesto. Non so esattamente perché - mi fa solo rabbrividire per qualche motivo. @ybungalobill: ciò rende difficile la fusione di elementi nel controllo del codice sorgente. –

risposta

17

Ho sempre inserito blocchi vuoti su un'unica riga, ad esempio { } (notare lo spazio!).

Inoltre, di solito inserisco i due punti e le virgole davanti a anziché i nomi degli elenchi di inizializzazione dopo - questo rende più facile l'aggiunta dei membri in seguito.

Thread(Process * parent, unsigned __int32 id, void * entryPoint) 
    : parent_(parent) 
    , id_(id) 
    , entryPoint_(entryPoint) 
{ } 
+0

BTW (anche se non uso questo stile) questo stile potrebbe essere buono perché è l'unico MS Visual Studio a non rovinarsi con la sua formattazione automatica. – anatolyg

+2

A volte, quando sembra che debba esserci il codice, aggiungo un commento/* Deliberatamente vuoto */(ma solo se è necessario spiegarlo). –

+0

@ Martin: Ne aggiungeresti uno qui? –

3

Questo è come lo faccio:

Thread(Process * parent, unsigned __int32 id, void * entryPoint) 
    :parent_(parent), 
    id_(id), 
    entryPoint_(entryPoint) 
{} 

Ma la tua strada non sembra strano per me.

2

Ecco come lo faccio

public: 
    Thread(Process * parent, unsigned __int32 id, void * entryPoint) : 
    parent_(parent), 
    id_(id), 
    entryPoint_(entryPoint) 
    { } 

stile Google (almeno protobuf), potrebbe essere:

public: 
Thread(Process * parent, 
     unsigned __int32 id, 
     void * entryPoint) 
    : parent_(parent), 
    id_(id), 
    entryPoint_(entryPoint) { } 
2

Ecco come lo faccio, e perché io non vedo nulla sbagliato con il tuo campione:

Thread(Process * parent, unsigned __int32 id, void * entryPoint) : 
     parent_(parent), 
     id_(id), 
     entryPoint_(entryPoint) { } 

Come Per quanto mi riguarda, fai come preferisci tu: finché sei coerente e coerente con il progetto a cui stai lavorando, non è lo numero che tipo di indentazione è.

0

Si consiglia di inserire un commento nel corpo del costruttore vuoto, solo così chiunque leggendo il codice sa che si intende che sia vuoto. In questo modo possono essere certi che non è il caso di aver dimenticato di inserire il codice lì.

Thread(Process * parent, unsigned __int32 id, void * entryPoint) : 
    parent_(parent), 
    id_(id), 
    entryPoint_(entryPoint) 
{ 
    // empty 
} 
+1

sai cosa, in realtà non mi piace perché spaventerà qualcuno a mettere il codice qui più tardi. Ma se è necessario, il manutentore non dovrebbe essere forzato a pensare di non farlo con un commento spaventoso. –

+0

"vuoto" è un commento spaventoso, davvero? Immagino che uno potrebbe essere più esplicito per es. "// Non ho intenzionalmente messo alcun codice qui, ma vai avanti se pensi che sia la cosa giusta da fare" ma penso che potrebbe essere un po 'eccessivo. Qualsiasi commento sarà meno spaventoso per un manutentore che costringerlo a cercare di indovinare quale fosse l'intento dell'autore originale, a causa dell'assenza di indizi sul perché il corpo del metodo sia vuoto. –

Problemi correlati