Esiste una convenzione di capitalizzazione comune in C ++? [chiuso]

Is there any most common convention for capitalization that I should know about?

C ++ è basato su C, che è abbastanza vecchio da aver sviluppato un sacco di convenzioni di denominazione nel momento in cui il C ++ è stato inventato. Poi il C ++ ne ha aggiunti alcuni, e C non è stato inattivo pensando a nuovi. Aggiungete a ciò i molti linguaggi derivati da C, che svilupparono ulteriormente le convenzioni di denominazione C del loro inventore, fino al punto in cui fecondarono indietro su C e C ++ ... In altre parole: C ++ non ne ha uno, ma molti di tali convenzioni.

Tuttavia, se stai cercando la convenzione di denominazione quella , potresti anche esaminare la convenzione di denominazione della libreria standard , perché è il singolo che tutti gli sviluppatori C ++ dovranno conoscere e utilizzare.

Tuttavia, qualunque cosa tu usi, la regola più importante è: Sii coerente!

È interessante notare che, mentre ho iniziato con un mix di PascalCase e camelCase, e sono stato coinvolto in numerosi progetti con convenzioni di denominazione ancora più numerose, nel corso degli anni ho scoperto di rimanere sempre più legato a standard_library_convention. Non chiedermi il perché.

Prima ammettiamo che TUTTA MAIUSCOLA è un pugno nell'occhio e che dovrebbe essere ridotto al minimo.

In C e C ++ è quindi usato come convenzione per macro e solo macro, perché le macro sono ugualmente brutte, per non dire malvagie.

La prima C non aveva const, quindi le costanti dovevano essere espresse come macro. Inoltre, in quei primi tempi i programmi erano molto più brevi, così che le pratiche oggi non buone potevano essere utilizzate (ad esempio IIRC Brian Kernighan ha scritto il codice con molte macro non maiuscole). Inoltre, a quei tempi esistevano tastiere che non avevano lettere minuscole; Ne ho usato uno di questi, sul computer norvegese Tandberg EC-10, circa il 1980 o il 1979, penso che fosse.

Quindi, Java raccolse la convenzione maiuscola per le costanti dalla prima C. Nel frattempo, e forse anche prima (non sono sicuro della cronologia qui), C ottenne delle costanti. Tuttavia, benché alcuni / molti programmatori C siano rimasti bloccati nella convenzione precedente per necessità delle costanti come macro in lettere maiuscole, i programmatori C ++ erano più sensibili.

Il grosso problema al giorno d'oggi è quando alle persone viene insegnato prima Java, o C (con le convenzioni del medioevo) prima, e poi vieni in C ++, prendendo con loro quella convenzione volgare e sporca.

    int const answer = 42;    // Nice, good, OK.
    const int ANSWER = 0x2A;  // Ouch!
    #define COMPANYNAME_ANSWER 052  // Oh kill me, please.

Potresti aver pensato di menzionare le tastiere maiuscole per scherzo. Oh no Perché questa è solo la più antica, la più arcaica limitazione della tecnologia che ha guidato le convenzioni di denominazione, o almeno ha influito sul modo in cui è sembrato sbagliato / giusto. Successivamente, c'era il problema della trasmissione seriale a 7 bit, che causava problemi corrispondenti con i codici carattere (codifiche carattere newspeak), il che significava che dovevi limitarti alle lettere dell'alfabeto inglese dalla A alla Z.

In realtà mi raccomando ancora di farlo. Ecco dove siamo! Non abbiamo ottenuto ulteriore.

Al momento, dal 2011, lo standard C ++ supporta l'Unicode generale nei nomi (e lo ha fatto dal 1998), mentre le effettive implementazioni in C ++ no. In particolare il compilatore g ++ è sfidato a carattere nazionale. Deriva da quel limite tecnologico dell'era oscura.

    double blueberryJamViscosity  = 0.0;    // OK
    double blåbærsyltetøyViskositet = 0.0;  // Ouch!

Infine, sul tema dei caratteri di sottolineatura rispetto alle lettere maiuscole intercalate,

• Prenota un modulo facilmente riconoscibile per i nomi dei tipi.
• Prenota TUTTO MAIUSCOLE per le macro.
• Sii coerente.

Penso che sia davvero, tranne che per regole come "in genere evita il nome di una sola lettera ad eccezione di (loop, template param, blah blah)", e "evita di usare l, facilmente confuso con 1" e "evita maiuscolo maiuscolo" , facilmente confuso con 0 ". Inoltre, evita di usare nomi riservati come l'inizio con il carattere di sottolineatura seguito da lettere maiuscole, contenente due caratteri di sottolineatura successivi o che iniziano con il carattere di sottolineatura e che si trovano nello spazio dei nomi globale.

Saluti e saluti hth

Di solito tendo ad attenermi alla convenzione che vedo di più nelle codebase esistenti per la lingua. Nel caso del C ++, di solito vedo camelCase. Nel caso di Ruby o PHP di solito vedo stuff_like_questo.

Realisticamente parlando, però, la cosa più importante è scegliere una convenzione di stile che non sia totalmente folle (dOnT_dO_tHiS) ed essere coerente con essa. Fallo in modo che lo stile non cambi nel codice per un particolare progetto. Se stai lavorando su un progetto esistente, ti consigliamo di utilizzare lo stile già presente.

Bene, c'è Sistemi ungherese che è molto comune anche adesso, ma preferisco tagliarmi proprio gola di raccomandarlo. Le app ungheresi sono migliori in quanto i suoi marchi annotativi sono davvero indicativi della semantica, sebbene ritenga che sia un po 'troppo acuto sulle abbreviazioni quando una parola breve potrebbe fare. (Per usare l'esempio da quella pagina di Wikipedia, perché usare rw per riga quando row è solo un carattere più lungo? Non è come se ci fosse una carenza di vocali globali.)

Realisticamente però, la cosa più importante è seguire le convenzioni di le persone con le quali lavori . Veramente. La maggior parte delle convenzioni funziona abbastanza bene, specialmente se usata in modo coerente. L'incoerenza è la peggiore (anche più di quella dei sistemi ungheresi, che odio). E se sei da solo, usa quello che vuoi.

Da quello che ho visto, varia tra i progetti.

I caratteri di sottolineatura incorporati sono probabilmente più tradizionali / più comunemente usati in C su Unix. Anche la libreria standard lo segue, quindi dovrebbe quasi certamente essere considerato come predefinito, da utilizzare a meno che non ci sia abbastanza codice esistente che usa un'altra convenzione per forzare assolutamente l'uso di quell'altra convenzione.

Windows (per un esempio) utilizza la custodia cammello per la maggior parte delle sue funzioni, quindi molte persone che sviluppano per Windows fanno lo stesso. Questo è anche abbastanza comune tra le persone che sono veramente più abituate ad altre lingue e cercano di trattare il C ++ come se fosse solo una strana variante di qualcos'altro.

Questo riferimento descrive una convenzione di denominazione molto simile a quella che ho visto usata con successo in almeno tre società per le quali ho lavorato in passato.

Contrariamente a una risposta precedente, vorrei evitare seguendo la convenzione di denominazione della libreria standard C ++ nel mio codice, se non altro per evitare conflitti di nome con la libreria standard.

Questa precedente risposta SO su un argomento correlato potrebbe anche essere di interesse: link

Ho usato entrambe le librerie standard e boost come riferimenti per le convenzioni di denominazione. Tuttavia, c'è un problema con questa soluzione.

La libreria standard utilizza una convenzione di denominazione progettata per tentare di ridurre le collisioni con il codice. Parte della soluzione è usare tutte le lettere minuscole. Da qui l'uso di caratteri di sottolineatura anziché di camelCase.

Trovo che CamelCase sia leggibile. PascalCase viene spesso utilizzato per i nomi delle classi in quanto rappresenta l'equivalente di un nome proprio. Tuttavia, infrangerò quella regola per i funtori che sono più rappresentativi di un verbo.

Cerco di non usare le macro. Tuttavia, quando lo faccio, i macro sono fatti per assomigliare a funzioni quando possono. Io uso anche i valori const o enum invece delle costanti manifest, evitando ulteriormente tutte le maiuscole. Di solito prefisso questi simboli con una "k" per indicare che sono costanti.

// instead of a manifest constant
#define HOURS 24

// use const
const int kHours = 24; 

// or enum
enum {
    kHours   = 24,
    kMinutes = 60
};