Qualunque cosa esista guida è fuori di data e non dovrebbe più esistere. Non credo che ci sia una sorta di guida in stile D ritenuta valida, e non credo che Walter Bright, Andrei Alexandrescu, ecc. Vogliano esserci. Inoltre, come ricordo, nel C++ Coding Standards: 101 Rules, Guidelines, and Best Practices, Herb Sutter e Andrei dissero che le guide di stile erano una cattiva idea (o almeno quelle realmente specifiche), ma dovevo tirare fuori il libro per essere sicuro di quello che dicevano esattamente . Quindi dubito piuttosto che Phobos (di cui Andrei è responsabile) abbia qualche tipo di guida di stile; Di certo non ne sono a conoscenza. Potrebbero esserci delle linee guida per la formattazione del codice che va in Phobos (come rendere il tuo codice simile al resto del modulo o del somesuch), ma qualcuno come Andrei o uno degli altri sviluppatori di Phobos dovrebbe rispondere. Certamente, con circa 15 diversi sviluppatori che lavorano su Phobos, sei destinato a ottenere diversi stili nel codice se non c'è una guida di stile applicata.
Quindi, non credo che ci sia davvero alcun tipo di stile di codifica raccomandato per D o Phobos. A quanto ho capito, le persone principali di D non sono particolarmente a favore delle guide di stile, e certamente non ne hanno spinto uno. Quindi, non ce n'è uno in questo momento, e non mi aspetto che ce ne sarà uno in futuro.
MODIFICA: OK, sono andato a cercare esattamente cosa Herb Sutter e Anderi Alexandrescu hanno detto nel C++ Coding Standards: 101 Rules, Guidelines, and Best Practices. Non è esattamente così contrario agli standard di codifica, quanto piuttosto contrari a quelli particolarmente restrittivi che rafforzano i gusti personali o le pratiche obsolete. Non ho intenzione di citare il tutto qui (è un buon libro, e probabilmente dovresti prenderlo comunque), ma qui ci sono alcuni punti chiave.
- Non specificare la quantità di rientro, ma eseguire il rientro per mostrare la struttura.
- Non applicare una lunghezza di linea specifica, ma mantenere leggibili le lunghezze delle righe.
- Non etichettare troppo i nomi, ma facciamo una convenzione di denominazione coerente.
- Non specificare gli stili di commento (tranne quando gli strumenti estrapolano determinati stili nella documentazione), ma scrivono commenti utili.
Alcuni esempi che hanno dato erano che
- posizionamento Brace non dovrebbe importa ma dovrebbe essere coerente e leggibile.
- Su spazi vs schede, non sembrano preoccuparsi se lo standard di codifica dice qualcosa a riguardo.
- Sono contro la notazione ungherese in C++, ma pensano che potrebbe essere utile in meno lingue sicure per tipo.
- Sono completamente contro l'imposizione di un'unica dichiarazione di ritorno in una funzione.
Indipendentemente da ciò, pensano che la formattazione debba essere coerente all'interno di un file sorgente. Ovviamente Phobos non si attiene necessariamente a questo punto, ma Andrei ha fatto solo apparire sul newsgroup alcune delle convenzioni che in genere hanno tenuto e stava cercando di forzarne alcune (il vero post è archiviato here).
Tuttavia, mentre Phobos è open source e chiunque è libero di inviare patch, ricorda che è l'API destinata al consumo pubblico. Solo gli sviluppatori di Phobos hanno bisogno di per guardare il codice (almeno se i documenti sono completati in modo appropriato) - sicuramente sono gli unici che ci lavoreranno direttamente - quindi non c'è bisogno di uno standard di codifica pubblicamente elencato , anche se ne usano uno. Sembra che potrebbero usare più coerenza e che potrebbero essere al lavoro su questo, ma tutto ciò che accadrà per terze parti è renderlo più leggibile. Nessun altro ha davvero bisogno di sapere cosa sia effettivamente lo standard (sebbene se si osservasse abbastanza codice seguendo uno standard, si potrebbe capire almeno più o meno ciò che lo standard ha detto).
Per quanto riguarda D in generale, ci sono alcune convenzioni che sono considerati buone pratiche (ad esempio utilizzando in genere auto invece di specificare un tipo, a meno che in realtà si deve specificare il tipo), ma proprio come con C++, è può codificare con qualsiasi stile di codifica tu voglia e gli sviluppatori D non sono abbastanza dittatoriali da provare a imporre uno stile all'intera comunità D.
Peccato. Trovo più facile leggere il codice quando è coerente. D fa esattamente l'opposto di Vai qui: | – simendsjo
Sono d'accordo. Phobos è in * disperato * bisogno di una guida di stile. Ogni volta che guardi una parte diversa della libreria, lo stile cambia, anche le convenzioni di denominazione. Rende Phobos molto difficile da usare. –
@Peter: Credo che alla fine accadrà per un bisogno disperato. È anche peggio per i moduli scritti da più persone - non cercano nemmeno di seguire lo stile precedentemente utilizzato. – simendsjo