FANDOM


Layout Modifica

Livelli di indentazione Modifica

Un livello di indentazione è composto da 2 spazi (una collection vimrc che crea il nostro stile di codice si trova qui: http://hg.tangent.org/vimrc).

(qualcuno dovrebbe scrivere qui come fare lo stesso con Emacs)

I tab non devono essere usati da nessuna parte, tranne che nei file makefile.am.

Parentesi Modifica

for (...)
{
  foo()
}

Per if/else, else va in una riga a sè, separata dalle parentesi. Se stai commentando una sezione di codice, puoi anche usare il seguente stile:

/* Spiegazioni... */
{
  qualcosa()
}

In generale è meglio essere più verbosi. Il codice verboso ha più possibilità di sopravvivere alle revisioni del codice, perchè il prossimo programmatore che lo guarderà lo comprenderà.

Tipi Modifica

  • Per favore, utilizza stdint.h per ora. stdint su Wikipedia (in inglese: Wikipedia Italia non ha ancora questa voce)
  • Quando scrivi, utilizza sempre i tipi C99. GCC consiglia di farlo.
    • Usa bool, non my_bool.
    • Usa true e false, non TRUE e FALSE (quelle macro scompariranno).
    • ulong -> uint32_t
    • ulonglong uint64_t
    • long int -> int32_t

Perchè? Perchè Long non è portabile e in MySQL viene usato in molti punti se il codice è realmente pronto per i 64 bit.

Per favore utilizza true/false con i booleani, non i numeri (vorrei proprio che gcc evidenziasse queste cose). Inoltre, quando controlli i valori veri o falsi, sii descrittivo.

if (can_print == false) {...};

oppure

if (not can_print) {...}

Piuttosto che

if (!(can_print)) {..};

Inoltre, i nomi dei booleani dovrebbero iniziare con un verbo per chiarire che si tratta di una variabile booleana. Invece di "valid", usa "is_valid". Invece di "drivers", usa "has_drivers".

Puntatori Modifica

Usa NULL quando ti riferisci a un puntatore null, non 0.

Stile del codice Modifica

Nelle assegnazioni, per favore utilizza lo stile di MySQL (nessuno spazio prima del segno uguale, uno spazio dopo):

x= 4;

E' più facile da cercare.

Invece di fare cose come questa:

if (a == b && c ==j || A)
  do_something();

Fai così:

if (((a == b) && (c ==j)) || A )
   do_something();

Sii generoso nell'utilizzo delle parentesi. Se le vedo, so che sapevi quello che stavi facendo e non mi devo preoccupare di chiedermi se hai realmente capito quale operatore aveva la precedenza.

Incapsula le strutture e le classi.

Usa enum, non i define. I define fanno in un colpo solo "tutto sarà questo". Gli enum creano delle liste. Se i valori andranno dentro uno switch/case... dovrebbero essere enum.

Per favore, non usare "i" come iteratore per i cicli for. I miei occhi sono vecchi e stanchi... usa x o scrivi un nome di variabile.

Per favore, aggiusta l'indentazione nel vecchio codice. E' un lavoro noioso, ma è incredibilmente utile. Quando qualcuno guarda il codice, produrrà delle patch basandosi su ciò che vede. Facciamo in modo che il codice sembri ciò che è.

Cicli for vuoti Modifica

Quando usi un ciclo for per iterare attravero qualcosa ed effettivamente non fai nulla dentro il ciclo (ad esempio se vuoi solo scorrere un array o una lista di parametri), fai così:

for () {}; 

oppure

for () {/* Non fare nulla */};

NON fare così:

for (); 

Perchè? Perchè quando hai un corpo vuoto, ti dà l'idea che il programmatore voleva realmente scrivere un for vuoto.

Ignorare i tipi restituiti Modifica

Generalmente, i tipi restituiti da una funzione non dovrebbero essere ignorati, però se vuoi ignorarli, fai così:

(void)func();

Questo indica che stai ignorando il tipo restituito da e sai che lo stai ignorando. Questa pratica verrà scoraggiata.

Include File Headers Modifica

Se stai editando il file drizzled/plugin_authentication.h

Dovresti utilizzare il seguente codice:

  1. ifndef DRIZZLED_PLUGIN_AUTHENICATION_H
  2. define DRIZZLED_PLUGIN_AUTHENICATION_H
  1. endif /* DRIZZLED_PLUGIN_AUTHENICATION_H */

Metti sempre un commento davanti all' #endif.

Assert Modifica

Usa l'assert() standard per ora. Abbiamo un'opzione in configure.ac che le disattiva per l'uso in produzione. In generale dovresti usare assert() ogni volta che lo desideri.

Stile dei nomi Modifica

Le strutture dovrebbero avere nomi come "qualcosa_st". Tutte le strutture che si trovano nel contesto globale dovrebbero usare typedef.

I nomi delle classi vanno con le prime lettere delle parole maiuscole. Per esempio Table e TableShare.

Gli enum dovrebbero essere utilizzati e i loro membri dovrebbero sempre essere in maiuscolo. La dichiarazione del tipo dovrebbe essere fatta in minuscolo.

I booleani dovrebbero essere chiamati "is_qualcosa", "has_qualcosa".

I metodi dovrebbero iniziare con un verbo tutto in minuscolo che spiega l'azione. Per esempio "foo.setBar()" o "foo.replaceString()".

Organizzazione dei file Modifica

File delle classi e delle strutture Modifica

Tutte le nuove classi hanno i loro file .h e .cc. Dovremo sistemare la massa che esiste oggi, ma quello è un obiettivo a lungo termine.

Link Modifica

Non usare i link ../ in Makefile.am per riutilizzare un singolo oggetto da un'altra libreria. Se hai bisogno di linkare quella libreria, allora linka la libreria. Inoltre, non creare link simbolici tra le librerie.

Nomi delle Directory Modifica

In ogni parte del codice potenzialmente potremo utilizzare dei plugin. Per questo motivo manterremo uno stile pulito per i nomi.

Per il server il nome è "drizzled"

Quindi un percorso di installazione sarà: /usr/local/include/drizzled/

Libreria client: /usr/local/include/libdrizzle

  • Perchè drizzled e non drizzle?

Perchè se aggiungiamo estensioni alla libreria andranno dentro "drizzle"

  • Ramificazioni per le include?

Le include che saranno installate dovranno essere scritte così:

  1. include <drizzled/field/blob.h>

Invece:

  1. include "item.h"

Dovrebbe essere usato nei casi in cui non installeremo mai quelle librerie nel filesystem.

TO-DO: Lavorare sulla condizione di errore nelle include nel caso in cui una build del server utilizzi una "include" verso il percorso di installazione (cioè: vogliamo essere sicuri di utilizzare solo le include nella nostra directory).

Altro Modifica

Evita #ifdef se non per reali esigenze di portabilità.

Non definire mai condizionalmente una variabile membro o un metodo in una classe o in una struttura utilizzando gli #ifdef.

Dovresti utilizzare i typedef sulle strutture come nome_st.

Usa enum, non define.

Per le parentesi degli if/else utilizza il seguente stile:

if (qualcosa)
{
  qualcosa();
}
else
{
  qualcosa_altro();
}

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.

Inoltre su FANDOM

Wiki casuale