Il peggior standard di codifica che hai mai dovuto seguire? [chiuso]

Hai mai dovuto lavorare a standard di codifica che:

• Diminuito notevolmente la tua produttività?
• Originariamente sono stati inclusi per buoni motivi, ma sono stati mantenuti molto tempo dopo che la preoccupazione originale è diventata irrilevante?
• Erano in una lista così a lungo che era impossibile ricordarli tutti?
• Ti ha fatto pensare che l'autore stesse solo cercando di lasciare il segno piuttosto che incoraggiare le buone pratiche di programmazione?
• Non avevi idea del perché fossero inclusi?

In tal caso, qual è la tua regola preferita e perché?

Alcuni esempi qui

Questo può increspare alcune piume, ma gli standard che impongono i commenti a blocchi modellati nella parte superiore di ogni metodo mi danno sempre fastidio.

1) Sono sempre obsoleti poiché sono troppo lontani dal codice che fa il lavoro effettivo per notare quando si aggiornano le cose. I commenti negativi sono peggio di nessun commento.

2) Spesso ripetono solo le informazioni che sono già contenute nello strumento di controllo del codice sorgente, solo meno precise. Ad esempio: Ultima modifica di, elenco di date / motivi della modifica.

Una volta aveva un professore che ci chiedeva di avere almeno un commento per ogni riga di codice.

//Set x to 3
var x = 3;

//if x is greater than 2
if(x>2){

    //Print x
    Print(x);
}

È stato piuttosto ridicolo.

Lo standard di codifica della nostra azienda (C #) prevedeva un ampio uso di #REGIONs (per chi non lo sapesse, segna blocchi di codice sorgente che verranno compressi su una singola riga in Visual Studio). Di conseguenza, hai sempre aperto quella che sembrava essere una classe ben strutturata, solo per trovare pile e pile di immondizia spazzate sotto tappeti profondamente annidati di costrutti #REGION. Avresti persino delle regioni attorno a linee singole, ad esempio dovendo piegare una regione di LOG per trovare una singola dichiarazione del Logger. Ovviamente, molti metodi aggiunti dopo la creazione di alcune regioni sono stati inseriti anche nell'ambito "sbagliato" della regione. L'orrore. L'orrore.

Le regioni sono una delle peggiori funzionalità mai aggiunte a Visual Studio; incoraggia a strutturare la superficie piuttosto che l'attuale struttura OO.

Oggi uccido #REGION a vista.

In un lavoro siamo stati costretti a usare una strana forma di notazione ungherese nel database.

Non ricordo i dettagli, ma dalla memoria, ogni nome di campo doveva contenere:

• Nessuna vocale
• Tutte le lettere maiuscole
• Un riferimento alla tabella
• Un indicatore del tipo di dati
• Una lunghezza di dati
• Un indicatore nullable

Ad esempio, la colonna contenente il nome di una persona potrebbe essere chiamata: PRSNFRSTNMVC30X(tabella Persona, colonna Nome, Varchar 30 caratteri, Not Null)

Insistere affinché tutte le parentesi graffe siano seguite da un commento per ciò che termina la parentesi graffa:

per esempio:

for (int i = 0; i < 10; i++)
{
    if (foo > bar)
    {
        printf("Foo greater than bar");
    } // End If (foo > bar)

    while (baz)
    {
       farb();
    } // End while (baz)
} // End For

#define AND  &&
#define OR   ||
#define EQ   ==

'ha detto Nuff.

• I nomi delle variabili locali sono tutti minuscoli senza caratteri di sottolineatura

Esempi reali: paymentmethodtotalshtml, contracttypechangecontexts, customsegmentspectexts,potentialmsceventref

Il New York Times pesa :

“Gli spazi delle parole non dovrebbero essere dati per scontati. Il greco antico, il primo alfabeto con le vocali, poteva essere decifrato senza spazi di parole se lo suonavi e facevi senza di loro. […] Anche il latino ha cessato di separare le parole dal secondo secolo. La perdita è sconcertante, perché l'occhio deve lavorare molto di più per leggere un testo non separato. Ma come ha spiegato il paleografo Paul Saenger, il mondo antico non desiderava "rendere la lettura più facile e rapida".

Mi è stato chiesto da parte del leader di software di una società per fare " semplice, ri n codice flui ". Era vietato, ad esempio, aggiungere un nuovo parametro a una funzione esistente. Invece hai dovuto duplicare la funzione, lasciando l'originale intatto per evitare regressioni. Ovviamente nessun test formale (perdita di tempo).

Ci è stato anche vietato l'uso del software di unione; ogni file può essere modificato da un solo programmatore alla volta. Il software di controllo delle revisioni era fantascienza, ovviamente.

Il giorno più felice della mia vita è stato quando è stato licenziato (considera che è molto, molto difficile licenziare qualcuno in Italia).

Tutte le interazioni con il database devono essere eseguite tramite procedure memorizzate . Potrebbe avere senso se viviamo nel 1997 e non nel 2010.

Ho appena capito che questo in realtà copre tutti i criteri della domanda originale:

• Diminuito notevolmente la tua produttività? DAI UN'OCCHIATA. Per favore, basta usare un ORM .
• Originariamente sono stati inclusi per buoni motivi, ma sono stati mantenuti molto tempo dopo che la preoccupazione originale è diventata irrilevante? DAI UN'OCCHIATA. Il gestore era uno sviluppatore per un server di database 1000 anni fa e ha inserito questo standard di codifica.
• Erano in una lista così a lungo che era impossibile ricordarli tutti? DAI UN'OCCHIATA. Ciò includeva "la maggior quantità possibile di logica deve essere archiviata nel database".
• Ti ha fatto pensare che l'autore stesse solo cercando di lasciare il segno piuttosto che incoraggiare le buone pratiche di programmazione? DAI UN'OCCHIATA. Continua a tornare dal gestore come ex sviluppatore di server di database.
• Non avevi idea del perché fossero inclusi? DAI UN'OCCHIATA.

Non poter utilizzare STL o altre librerie C ++ standard perché il CTO riteneva che "noi" potessimo farlo meglio e più velocemente. Anche costrutti di base come liste e la classe di stringhe.

Notazione ungherese

Esempio estratto dalla " spiegazione di Charles Simonyi della convenzione di denominazione dell'identificatore di notazione ungherese " su MSDN.

1 #include "sy.h"
2 extern int * rgwDic;
3 extern int bsyMac;
4 struct SY * PsySz (char sz [])
6 {
7 caratteri * pch;
8 int cch;
9 struct SY * psy, * PsyCreate ();
10 int * pbsy;
11 int cwSz;
12 unshaw wHash = 0;
13 pch = sz;
14 while (* pch! = 0
15 wHash = (wHash11 + * pch ++;
16 cch = pch-sz;
17 pbsy = & rgbsyHash [(wHash & 077777)% cwHash];
18 per (; * pbsy! = 0; pbsy = & psy-> bsySuccessivo)
19 {
20 caratteri * szSy;
21 szSy = (psy = (struct SY *) & rgwDic [* pbsy]) -> sz;
22 pch = sz;
23 while (* pch == * szSy ++)
24 {
25 if (* pch ++ == 0)
26 ritorno (psy);
27}
28}
29 cwSz = 0;
30 if (cch> = 2)
31 cwSz = (cch-2 / sizeof (int) +1;
32 * pbsy = (int *) (psy = PsyCreate (cwSY + cwSz)) - rgwDic;
33 Zero ((int *) psy, cwSY);
34 bltbyte (sz, psy-> sz, cch + 1);
35 ritorno (psy);
36}

Una volta ho lavorato a un progetto in cui il responsabile del progetto aveva imposto che ogni variabile - OGNI variabile - fosse preceduta da "v". Quindi, vCount, vFirstName, vIsWarranty, ecc.

Perché? "Perché stiamo lavorando in VBScript e ogni cosa è comunque una variante".

WTF.

Quasi dimenticato questo:

Citazione di un manager:

Non correggere o documentare eventuali bug di problemi riscontrati nel proprio codice. Il cliente ci pagherà per identificarlo e risolverlo nei prossimi anni.

Questo non era per il software consumer, ma personalizzato per una singola grande organizzazione. Inutile dire che il cliente ha pagato per anni dopo. Può sembrare banale, ma cercare di ignorare i bug è più difficile che trovarli.

Commenti XML forzati su tutti i metodi, costanti, enumerazioni e proprietà non privati.

Ha portato a un po 'di codice piuttosto ingombrante, soprattutto perché il risultato finale è stato che le persone o semplicemente colpivano /// per creare uno stub di commento vuoto per tutto o installare GhostDoc e farlo aggiungere commenti generati automaticamente:

/// <summary>
/// Validations the handler.
/// </summary>
/// <param name="propertyName">The property name.</param>
public void ValidationHandler(string propertyName) 
{
   // whatever
}

[Modifica] Il motivo per cui lo menziono come uno standard ridicolo non è perché penso che i commenti sul metodo siano stupidi, ma perché la qualità di questi commenti non è stata applicata in alcun modo e ha provocato solo la creazione di un sacco di disordine nei file di codice . Esistono modi migliori per creare documenti di codice significativi rispetto ai requisiti di build ciechi "devono avere un commento".

Non proprio uno standard di codifica, ma avevamo un file nel controllo del codice sorgente chiamato 'changelog.txt'

Ogni volta che hai effettuato un check-in, hai dovuto aggiungere manualmente una voce a questo file. Questa voce era il numero di revisione della sovversione e il commento del check-in.

Quando iniziò il nuovo CTO e qualcuno glielo disse, prese prontamente una decisione esecutiva e disse: "Non lo faremo più" e cancellò il file. Questo andava avanti da anni.

Alcuni dei posti in cui ho lavorato hanno insistito per commentare il codice inutilizzato o deprecato invece di eliminarlo. Invece di fidarsi del VCS per la storia, ecc. È stato dolorosamente mantenuto nei file attraverso il codice commentato.

Il grosso problema che ho riscontrato è che spesso non hai idea del perché il codice sia stato commentato. Era perché alcuni sviluppatori stavano attivamente apportando modifiche e volevano tenerlo come riferimento o non era più necessario?

Il peggior standard di codifica a cui abbia mai partecipato sono le basi di codice che non ne avevano affatto. Preferirei seguire uno standard di codifica con cui non sono completamente d'accordo piuttosto che lavorare su basi di codice dove non ce ne sono affatto. Rende molto più difficile apprendere nuove parti della base di codice.

Forzare i commenti in linea per il controllo della versione riguardava lo standard di codifica più inutile che ho ignorato.

//Changed on 2/2/2004 By Ryan Roberts for work item #2323332
Dim Some Horrendous VB
//End Changed

Il DBA Oracle che ha insistito sull'uso corretto degli spazi bianchi, pur "mantenendo" un database con una tabella altamente contesa che aveva oltre 200 campi e 40 trigger si avvicina.

Ho fatto recensioni di codice su un progetto guidato da un primo timer C ++ che ha deciso che tutte le funzioni dei membri della classe dovevano essere precedute dal nome e dalla visibilità della classe:

class MyClass
{
   public:
      void MyClass_Public_setValue(int value);
}

Viene richiesto di indentare tutto il codice di quattro spazi;)

Ho avuto un lavoro anni fa in cui tutto il nostro codice doveva essere allineato a sinistra, senza rientrare. Al ragazzo che ha escogitato questa politica non piaceva scorrere avanti e indietro in orizzontale quando guardava lunghe righe di codice, equiparandolo a giocare a ping-pong con i suoi occhi.

Questo più un esempio di come non avere standard di codifica può danneggiare.

Un appaltatore che lavora in una grande banca ha insistito sul fatto che seguire gli standard era il migliore in assoluto. L'applicazione è stata scritta in dBase / Clipper di cui è stato l'unico sviluppatore e, naturalmente, ha elaborato lo standard.

• Tutto è in maiuscolo. Intendo tutto, compresi i rari commenti che ha fatto.
• Nessun rientro.
• La denominazione delle variabili era qualcosa sulla falsariga di APRGNAME. A = ambito della variabile, ad esempio P per pubblico, PRG = primi tre caratteri del file sorgente che ha creato la variabile, NAME = nome della variabile nei restanti 6 caratteri consentiti da dBase / Clipper.
• Le prime 4 e le ultime 4 righe del codice sorgente erano lunghe 80 *. Perché? Così ha potuto sentire la stampante ad aghi avviare e terminare la stampa di un file. La memoria è che l'intero programma è stato stampato tramite il mainframe ogni settimana, 20.000 pagine.
• Sono sicuro che ce ne fossero molti altri che sono riuscito a scaricare dal mio cervello.

A quel punto ero un programmatore autodidatta molto nuovo, ma sapevo abbastanza da non ascoltare lo scienziato pazzo e andarmene da lì prima di chiedere di prendere il controllo del progetto.

E sì, abbiamo detto al management quanto fossero brutte queste pratiche, ma sempre ottenute le solite "stavano pagando questo dollaro in testa all'appaltatore che deve sapere di cosa sta parlando".

Un'altra esplosione del mio passato.

Citazione dal proprietario dell'azienda:

Non ci sarà alcun codice scritto usando linguaggi interpretativi perché ho perso 25 milioni su quel progetto {expletive} scritto in Java.

Il progetto Java era un sistema di compravendita di azioni progettato per gestire alcune dozzine di azioni, che ora veniva utilizzato per elaborare migliaia. Invece di affrontare i difetti di progettazione o l'hardware scadente, l'intera azienda è stata costretta a convertire tutte le applicazioni non C / C ++ in C / C ++ e tutti i nuovi sviluppi dovevano essere in C / C ++. I linguaggi interpretativi significavano qualsiasi cosa non compilata e il proprietario considerava compilato solo Assembler, C e C ++.

Per un'azienda di 800 persone, in cui la maggior parte del codice era in Java e Perl, ciò significava che l'intera azienda ha trascorso la maggior parte del tempo nei successivi due anni riscrivendo il codice perfettamente corretto in C / C ++.

Abbastanza divertente, una ventina di anni prima di questo fiasco, ero in un'altra società in cui il capo della tecnologia aveva deciso che la nostra logica di ordinamento (era un Bubble Sort) doveva essere ricodificata in assemblatore invece di essere sostituita da Quick Sort perché - Gli algoritmi lo fanno non migliorare le prestazioni. L'unico modo per migliorare le prestazioni era riscrivere la stessa logica in assemblatore.

In entrambi i casi, sono partito poco dopo la caduta dei dettami.

Come molti programmatori (ma non abbastanza), odio la decorazione del codice. Mi fa infuriare quando devo usare un prefisso con il simbolo del dollaro ($) per i nomi delle variabili o il trattino basso per le variabili private, anche senza getter / setter. Se hai bisogno di decorare il tuo codice per capirlo, allora devi andartene!

Ho lavorato con un sistema web per un po 'in cui tutti i parametri passati dovevano essere chiamati P1, P2, P3 ecc. Nessuna possibilità all'inferno di sapere a cosa servivano senza una vasta documentazione.

Inoltre - sebbene non sia strettamente uno standard di codifica - nello stesso sistema, ogni singolo file doveva essere chiamato xyz0001.ext, xyz0002.ext, xyz0003.ext, ecc. - dove xyz era il codice dell'applicazione in sé.

Questo è stato TANTO tempo fa - 1976 per essere esatti. Il mio capo non aveva mai sentito parlare di Edsger Dijkstra o letto un numero di CACM, ma da qualche parte aveva sentito dire che "GOTO è cattivo", quindi non ci era permesso di usare GOTO nei nostri programmi COBOL. Questo è stato prima che COBOL aggiungesse "end if", quindi al momento aveva solo due e mezzo delle tre strutture di controllo classiche (sequenza, if / then / else, performano (cioè do while)). Consentì a malincuore GOTO nei nostri programmi di base e istruzioni di diramazione nei nostri programmi di linguaggio Assembler.

Mi dispiace che questa sia una specie di storia "dovevi essere lì". Per quanto ne so, ogni lingua inventata dal 1976 ha strutture di controllo adeguate in modo da non dover mai usare GOTO. Ma il punto è che il capo non ha mai saputo PERCHÉ GOTO era considerato dannoso o quale lingua era il disturbo infantile e quale era la malattia fatale.

Ho lavorato in un progetto in cui la richiesta principale dell'architetto era quella di scrivere (in modo troppo) codice esplicito. Uno dei peggiori esempi che ho trovato nel codice (e ha felicemente approvato) è stato il seguente.

private string DoSomething( bool verbose )
{
    if ( verbose ) { return someString; }
    else if ( !verbose ) { return otherString; }
    else { return string.Empty; }
}

Anche ReSharper ti ha detto che è sbagliato!

Nel mio ultimo lavoro, "standard" sarebbe un termine molto forte per quello che mi è stato dato dal ragazzo che mi ha assunto. Programmando siti Web in ColdFusion e SQL, mi sono stati dati requisiti di codifica come:

• Non utilizzare include. Mi piace una grande pagina
• Separare sempre le parole nei nomi delle variabili e delle colonne con caratteri di sottolineatura (tranne isattivo, nome, ecc.)
• Non usare mai le abbreviazioni: scrivi sempre il nome (ha spesso scritto fname e così via)
• Non usare nomi confusi (come amount_charged e charge_amount, che misurano cose diverse ma correlate)
• Non usare DIV e usare un minimo CSS - usa invece tabelle nidificate (ho trovato circa sei livelli in profondità, una volta).
• Non memorizzare nella cache alcuna query. Mai.
• Stai per usare una variabile su più di una pagina? Ambito di applicazione
• Ogni pagina è il proprio blocco try / catch. Non abbiamo bisogno / vogliamo un gestore di errori globale.

Ho iniziato a cambiarli non appena ha smesso.

Nella mia vita di programmatore C ++, sono state applicate due "regole" davvero brutte:

1. "Non possiamo usare STL, perché VC ++ 4.1 non lo supporta (e al momento non possiamo passare a VC ++ 6.0)."
2. "Do Non utilizzare QuickSort, perché può essere O (n ^ 2) nei casi gravi, utilizzare questa implementazione dell'algoritmo heapsort I (nome del responsabile del progetto cancellato) scritto come uno studente."

Sono costretto ad avere la documentazione XML per tutte le classi e i membri della classe. Compreso il privato. Sono entusiasta di usare i commenti ghostdoc predefiniti.

public class User 
{
    /// <summary>
    /// the _userID
    /// </summary>
    private int _userID;
}