2009-11-23 14 views
8

Quale convenzione di denominazione è più preferibile in C++? Il metodo sottolineatura o il metodo camelCase? Ho programmato in Java per un po 'e sono abituato alle convenzioni di denominazione di CamelCase. Quale è più prevalente?Denominazione C++: read_input() vs. readInput()

Inoltre, durante la definizione di una classe, esiste un ordinamento preferito di variabili/metodi privati ​​/ pubblici/protetti?
Gli amici di solito si mettono alla fine?
E i typedef, vengono in cima alla definizione della classe?

+2

Volevo solo aggiungere, lo segnerei come wiki della comunità e soggettivo. –

+0

Un duplicato di: http://stackoverflow.com/questions/1776291/function-names-in-c-capitalize-or-not anche se il titolo è un po 'diverso. –

+0

Molto probabilmente un duplicato di: http://stackoverflow.com/search?q=c%2B%2B+convention Ci sono tonnellate di questi fili. –

risposta

7

Questo è tutto molto soggettivo, ma in generale per C++ che faccio:

camelCase per le funzioni e le variabili.

PascalCase per le classi.

public: 
protected: 
private: 

Nelle classi.

Edit: Hai dimenticato questi 2:

Sì, friend alla fine, typedef sia all'inizio se sono utilizzati nella classe, o dopo se usano la classe (per ovvie ragioni).

+0

Direi lo stesso. Tendo a non usare molto gli amici - in C++ cioè;) –

+2

@Steven - Spero che tu non usi i tuoi amici nella vita reale. 8v) –

+3

Beh, evito solo gli amici in generale :) –

3

I caratteri di sottolineatura sono spesso più prevalenti su codice unix o multipiattaforma.

codice di Windows tende ad essere cammello carter

generalmente pubblico, protetto, privato è quello che mi aspetterei - ma forse è più dal mio C# tempo.

0

Uso i caratteri di sottolineatura per le variabili locali; ALL_UPPERCASE per macro e costanti; CamelCase per niente e CamelCase per tutto il resto.

Uso sempre le strutture e mai le classi, quindi inizio con il pubblico: (senza specificarlo) e quindi messo privato: alla fine.

Questo è tutto molto soggettivo e non esiste una risposta giusta o sbagliata.

21

Preferisco prendere la route boost e abbinare la libreria standard. Questo significa lower_case_names. Mi piace il fatto che il mio codice sia coerente con lo STL.

+1

Anche io lo facevo, ma un progetto su cui ho lavorato diceva che a seguito di ciò rende difficile individuare immediatamente quale codice si scrive e quale è da std :: se si usa namespace std; Questo aveva senso per me, ma invertire per voi signore come mi piace anche questo stile. –

+4

@Adam: quindi perché sarebbe opportuno differenziare otticamente tra codice STL e proprio codice? Non ha mai avuto senso per me, eppure le persone lo usano in tutti i tipi di ambienti (non solo in C++). Ecco a cosa servono * gli spazi dei nomi * e funzionano incredibilmente bene. –

+0

@Konrad: Sì, lo capisco, ma a volte non vuoi usare std :: o myown :: davanti a tutto, quindi usi lo spazio dei nomi ... Poi, mentre vai avanti, vedi 'qualcosa .push_back (item) 'then' something.sort() 'è questo std :: list :: sort() o myown :: objectwithalist :: sort()? Ancora una volta, sono stato costretto a seguirlo in una volta, e ha lentamente sostituito i miei metodi standard. –

0

Quale convenzione di denominazione è più preferibile in C++? Il metodo `sottolineatura ' o il metodo camelCase? Ho codificato in Java per un po 'e io sono usato per le convenzioni di denominazione di camelCase . Quale è più prevalente ?

Direi "basta attenersi a ciò che sai su questo se stai iniziando a scrivere le tue librerie", sono entrambi utilizzati regolarmente.

Inoltre, durante la definizione di una classe, esiste un ordinamento preferito di variabili/metodi privati ​​/ pubblici/protetti?

Varia a seconda del programmatore/team. Ordino per categoria. Io uso una categoria per "metodi interni/privati", e quella categoria è generalmente seconda alla fine (l'ultima è l'implementazione vietata).

Gli amici di solito si mettono alla fine?

Li uso raramente; Li inserisco sopra la dipendenza (metodo), altrimenti, dopo la categoria costruttore/distruttore.

E i typedef, vengono in cima alla definizione della classe?

Ecco dove li ho messi.

Se si desidera entrare nei dettagli, esistono convenzioni di codifica disponibili pubblicamente. Dal momento che hai già uno sfondo Java, sarai facilmente in grado di tagliare il "gusto" in loro.

6

Di solito rispetto le tradizioni della piattaforma/ambiente in cui sto programmando, eccetto che in progetti C/C++ multipiattaforma in cui sono neutrale. Quando programmo C + raw Win32, tendo ad usare la notazione ungherese per variabili (tipo o prefissi semantici). Quando si programmano le variabili membro MFC m_, ecc. L'unica cosa che non riesco a ottenere facilmente nei miei occhi è la convenzione Unix/POSIX open_device_driver rispetto allo stile Camelcase OpenDeviceDriver.

+0

+1. Quando a Roma, ecc ecc ... – Macke

+1

+1. ... fai come fanno i Rumeni – Joe

3

La cosa più importante qui è rimanere coerenti. Se stai incorporando il codice di altre persone nel tuo progetto, segui il metodo che stavi utilizzando. Se stai pensando di contribuire con questo codice, per esempio, a un progetto software open source in futuro, cerca di rispettare le loro convenzioni di codifica. Se stai scrivendo tutto il tuo codice da zero, direi di attenermi alle convenzioni che sei abituato ad usare. Ciò sarà particolarmente utile quando torni al tuo codice in un secondo momento e provi a capire cosa hai scritto.

Per quanto riguarda le specifiche di accesso di struttura/classe, in genere vengono visualizzati i membri pubblici elencati per primi, seguiti da protetti e privati ​​(in ordine di controllo dell'accesso crescente). Questo è fatto principalmente per ragioni di leggibilità. Quando altre persone usano il tuo codice, saranno questi membri pubblici con cui si interfacciano, quindi posizionarli in cima alla dichiarazione li rende più facili da trovare. Ordinare i membri in questo modo mantiene le informazioni più probabili da utilizzare più vicino alla cima. Non vedo il friend usato troppo spesso, quindi non riesco a ricordare alcun motivo sul suo utilizzo. typedef di solito viene visualizzato nella parte superiore in modo che quando si esamina il resto della classe, il lettore abbia già una comprensione dei tipi personalizzati (anche per ragioni di leggibilità, i gruppi typedef sono in genere raggruppati insieme e non intervallati dalle dichiarazioni dei membri).

Ci sono un certo numero di convenzioni di codifica esistenti là fuori in uso comune, e l'unica cosa che hanno in comune è uno standard. Qualunque sia il sistema che utilizzi, anche se lo definisci tu stesso, è utile se hai un documento (o una pagina di codice di esempio) che delinea la convenzione di codifica. La coerenza migliora la leggibilità, specialmente quando in futuro si rivisita il codice precedente.

Qui ci sono un paio di codifica convenzioni forse darvi alcune idee:

0

Decenni di codifica come lavoro hanno dato alle mie dita qualche malattia. Ogni volta che uso il mio mignolo per premere il tasto [SHIFT] per la lettera maiuscola, provo un leggero dolore.

Quindi sono arrivato a preferire snake_notation. Usando l'utilità AutoHotKey, ho assegnato la combinazione [alt] + [spazio] a 'carattere di sottolineatura' di serpente. È un po 'scomodo per il mio pollice premere [alt], ma è meglio che usare il mignolo. (In realtà [ctrl] + [spazio] è molto meglio, ma VisualStudio utilizza questa combinazione come intellisense.) Inoltre, ritengo che sia più veloce di camelCase.

Desidero che i-rocks avvii una nuova tastiera con "tasto di sottolineatura" per i programmatori che preferiscono snake_notation.

Problemi correlati