it-swarm.it

Il peggior standard di codifica che hai mai dovuto seguire?

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

76
finnw

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

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 informazioni che sono già contenute nello strumento di controllo del codice sorgente, solo meno accurate. Ad esempio: Ultima modifica di, elenco di date/motivi della modifica.

97
JohnFx

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.

129
Fishtoaster

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 singole linee, ad es. dover 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 funzionalità peggiore mai aggiunte a Visual Studio; incoraggia a strutturare la superficie piuttosto che l'attuale OO.

Oggi uccido #REGION a vista.

103
Cumbayah

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 che contiene il nome di una persona potrebbe essere chiamata: PRSNFRSTNMVC30X (Tabella Persona, colonna Nome, Varchar 30 caratteri, Not Null)

80
Damovisa

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
48
Kris Erickson
#define AND  &&
#define OR   ||
#define EQ   ==

'ha detto Nuff.

37
Niall C.
  • 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, potrebbe 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". "
37
John Siracusa

Il leader del software di una società mi ha chiesto di fare "semplice, rindundant code ". Ad esempio, era vietato aggiungere un nuovo parametro a una funzione esistente. È stato invece necessario duplicare la funzione, lasciando intatto l'originale per evitare regressioni. Nessun test formale ovviamente (spreco 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).

36
Wizard79

Tutte le interazioni con il database devono essere eseguite tramite stored procedure . 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, usa semplicemente 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.
36
Jaco Pretorius

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.

33
David B

Notazione ungherese

Esempio estratto da " 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 char * pch; 
 8 int cch; 
 9 struct SY * psy, * PsyCreate (); 
 10 int * pbsy; 
 11 int cwSz; 
 12 unshw 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 -> bsyNext) 
 19 {
 20 char * szSy; 
 21 szSy = (psy = (struct SY *) & rgwDic [* pbsy]) -> sz; 
 22 pch = sz; 
 23 while (* pch == * szSy ++) 
 24 {
 25 if (* pch ++ == 0) 
 26 return (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 return (psy) ; 
 36}
31
JD Frias

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.

28

Quasi dimenticato questo:

Citazione di un manager:

Non correggere o documentare eventuali bug di problemi riscontrati nel tuo 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.

26
David B

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 sui metodi 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".

24
Adam Lear

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 di Subversion e il tuo commento di check-in.

Quando il nuovo CTO è iniziato e qualcuno glielo ha detto, ha prontamente preso una decisione esecutiva e ha detto: "Non lo faremo più" e ha eliminato il file. Questo andava avanti da anni.

23
Jim A

Alcuni dei posti con 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 è stato commentato. Era perché alcuni sviluppatori stavano attivamente apportando modifiche e volevano tenerlo come riferimento o non era più necessario?

20
Jeremy Wiebe

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.

17
JaredPar

Forzare i commenti incorporati 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.

16
Ryan Roberts

Ho fatto delle revisioni del 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);
}
14
user1006

Avevo 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 dover scorrere avanti e indietro in orizzontale quando guardava lunghe righe di codice, equiparandolo a giocare a ping-pong con i suoi occhi.

9
Jeremy

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

9
RedFilter

Un'altra esplosione del mio passato.

Citazione del 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 trading azionario progettato per gestire alcune dozzine di titoli, che ora veniva utilizzato per elaborare migliaia. Invece di affrontare i difetti di progettazione o l'hardware scadente, l'intera società è stata costretta a converte 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 solo Assembler, C e C++ compilati.

Per un'azienda di 800 persone, in cui la maggior parte del codice era in Java e Perl, ciò significava che l'intera società 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 smistamento (era un Bubble Sort) doveva essere ricodificata in assemblatore invece di essere sostituita da Quick Sort perché - - Gli algoritmi non migliorano 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.

8
David B

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 ovviamente 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 es. 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 nuovissimo, 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 abbiamo sempre ottenuto il solito "stavano pagando questo dollaro in alto all'appaltatore che deve sapere di cosa sta parlando".

8
Tim Murphy

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!

6
Adam Harte

Questo è stato molto 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 (la sequenza, if/then/else, si esibiva (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.

6
Mark Lutton

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!

6
Jax

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é.

6
CB Du Rietz

Nel mio ultimo lavoro, "standard" sarebbe un termine molto forte per quello che mi è stato dato dal ragazzo che mi ha assunto. Programmando i 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 misuravano cose diverse ma correlate)
  • Non usare DIVs e usa il minimo CSS - usa invece tabelle nidificate (ho trovato circa sei layer 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.

6
Ben Doom

Quasi qualsiasi tipo di convenzione di denominazione delle variabili che ribadisca il tipo di variabile, la mutabilità, la portata/classe di archiviazione e/o il loro riferimento. Fondamentalmente, qualsiasi costrutto intrinseco alla lingua. Questo non è più necessario nel 21 ° secolo con gli IDE moderni (e, a mio avviso, all'inizio ho risolto solo le pratiche/layout di codice mediocre). Ciò include la notazione ungherese e le sue varianti:

  • bigBlobStr - Una stringa.
  • bigBlobStrCurLocPtr - Un puntatore alla "posizione corrente" in detta stringa.
  • someIntArray - Matrice di numeri interi

o cose come:

  • e_globalHeading - Variabile esterna
  • sg_prefPoolSz - Variabile globale statica

e, naturalmente, uno dei peli dell'occhio più distanti in OOP, m_ per tutti i membri. Se non puoi essere sicuro/tenere traccia di quali variabili sono locali, membri, globali, statiche o final/const, potresti potresti scrivere in modo poco chiaro , scarsamente considerato, codice spaghetti.

Questo è completamente diverso dalla specifica di una convenzione prefisso/suffisso per cose come min, max, avg, size, count, index, eccetera, che va bene.

4
charstar

Sono costretto ad avere la documentazione XML per tutte le classi e i membri della classe. Compreso privato. Sono incoraggiato a utilizzare i commenti ghostdoc predefiniti.

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

Peggior standard che abbia mai dovuto affrontare:

StyleCop per C #

Prendi ogni standard inutile di sempre e inseriscilo in uno strumento che viene eseguito in fase di compilazione anziché in IDE in fase di progettazione.

//this is not a legal comment.
//  nor is this

// deve essere seguito da un singolo spazio, se si esegue il debug, utilizzare //// per commentare il codice. Le proprietà devono anche avere commenti "triple slash" e devono leggere "Ottiene o imposta xxxxx" completo di un punto alla fine e correttamente capitalizzato.

Ugh. Forse c'è un punto con le API ampiamente pubblicate, ma il mio principale obiettivo è che avrebbero sicuramente potuto costruirlo come plugin alla R #.

4
MIA

Ho lavorato per un breve periodo in Giappone. Stavo facendo complesse codifiche matematiche. Lo standard di codifica della società era di non avere assolutamente commenti. È stato difficile perché mi sarebbe piaciuto aggiungere alcuni commenti per spiegare i calcoli complessi e non dimenticarmi dopo poche settimane. Peccato al prossimo che viene dopo di me per capire cosa stesse facendo il codice.

Era la prima volta che vedevo che i commenti in codice erano proibiti.

4
softveda

In un precedente lavoro, lo standard C # doveva avere almeno due spazi tra il nome del tipo e il nome della variabile nelle dichiarazioni, il nome del metodo deve iniziare sulla riga successiva dai modificatori di accesso e dal tipo di ritorno, deve essere presente uno spazio prima di ogni punteggiatura aperta (parentesi o parentesi), tutte le dichiarazioni variabili all'inizio del metodo, le dichiarazioni separate dall'assegnazione e il rientro erano 3 spazi. Esempio:

private static int
ThisIsTheMethod (int  code, string  message)
{
   int  i;
   int  j;
   int  k;

   for (i = 0; i < message.Length; i++)
   {
      if (message [i] == '!') return -1;
   }

   j = SomeMethod (code);
   k = OtherMethod (j);

   return k;
}

Mentre brutto, era fattibile con l'eccezione che Visual Studio non voleva davvero le cose in quel modo ed era più un passo in più dopo aver codificato "normalmente" per riformattarlo in questo modo.

3
Jesse C. Slicer

nel mio lavoro precedente, che ho lasciato volentieri 3 mesi fa:

banca dati:

  • I nomi delle tabelle dovevano essere maiuscoli.
  • I nomi delle tabelle dovevano essere preceduti da TBL_
  • I campi dovevano essere preceduti: DS_ (per varchar, che non aveva senso) NU_ per i numeri CD_ per ("campi di bit") DT_ per le date
  • anche i campi del database dovevano essere maiuscoli [CD_ENABLED]
  • lo stesso con i nomi sp [SP_INFINITY_USER_GROUPS_QRY] e i nomi di database [INFINITY]
  • ho detto che i nomi sp erano in realtà così? SP_ prefisso, quindi nome del database SP_INFINITY_, quindi nome della tabella, SP_INFINITY_USER_GROUPS, quindi cosa si aspettava effettivamente che lo sp (Gesù, QRY, UPD, DEL, INS) facesse, non farmi nemmeno iniziare con query che non erano solo query CRUD.
  • tutti i campi di testo dovevano essere varchar (MAX), inequivocabilmente.
  • i numeri erano int o double, anche quando avresti potuto usare un altro tipo.
  • i campi "booleani" (bit) erano int, nessun motivo.
  • le procedure memorizzate dovevano essere precedute da sp_productname_

asp.net/c #/javascript

  • OGNI singola funzione ha dovuto essere racchiusa in try {} catch {}, quindi le applicazioni non "esploderebbero" (almeno questo era il motivo ufficiale), anche quando questo ha prodotto cose che non funzionavano e non avevano idea del perché.
  • i parametri devono essere preceduti da p, ad esempio pCount, pPage
  • le variabili dell'ambito dovevano essere precedute da w (come in "working", cosa diavolo significa?)
  • statica con g, ecc.
  • tutto post framework 1.1 era offlimits, come se avessi comunque un reale utilizzo per linq e generics. (Ho fatto in modo di obbligarli a lasciarmi usare jquery, almeno ci sono riuscito).
3
bevacqua

Inclusione obbligatoria, espansione delle informazioni $ Log $ quando il nostro SCC era una versione antiquata di PVCS. Avevamo alcuni file in cui le informazioni $ Log $ erano molto, molto più lunghe del codice effettivo nel file.

3
Ian C.

Tutto l'output in a PHP deve essere ripetuto riga per riga.

<?php
echo "<div id=\"foo\">";
echo "<h1>" . $title . "</h1>";
echo paragraphs($body); // just an example
echo "</div>";
?>

(Dichiarazione di non responsabilità: non ho dovuto seguirlo, ma una squadra con cui ho lavorato lo ha fatto.)

3
sholsinger

worst era un progetto (C++) in cui le classi erano precedute da abbreviazioni di moduli.

Ad esempio, se qualcosa fosse nel modulo MessagePassing e parte del meccanismo di risposta, potrebbe essere chiamato MESPAS_RESSomeobject.

Lavorare su quel codice mi ha fatto venire voglia di sgranare gli occhi.


Non il peggiore, ma il mio lavoro attuale richiede un c_ prefissi sulle classi e e_ prefissi per enum. Niente per le strutture. ma _t postfix su typedefs. È anche abbastanza brutto.

Oh, e commenti di intestazione della funzione in ENTRAMBI .h e .cpp (dichiarazione e definizione) che ovviamente non corrispondono quasi mai.

3
µBio

La mia preferita è la regola "Nessun numero magico" applicata in modo clueless. Ad esempio, una volta ho visto un commento in una recensione di codice che affermava che la regola "Nessun numero magico" era stata violata da questa riga di codice:

if (fscanf(file, "%s %hd",name, nbrObject ) != 2 )

Immagino che il recensore volesse una costante anziché 2, come #define TWO 2

3
Chalie Wax

I nomi dei nostri metodi dovevano essere nel formato "Ottieni/Imposta/Aggiungi/Elimina" + nome dell'oggetto target + nomi di tutti i parametri.

GetUserById(userId);
InsertUser(user);
DeleteUser(user);

Abbastanza giusto - ma la regola è molto severa. I tipi di oggetti complessi non potevano essere abbreviati e le operazioni dovevano sempre elencare tutti i parametri di richiesta, non importa quanto ridicoli:

GetCustomerOrderDeliveryDetailsByCustomerIdAndDeliveryDateAndOrderStatus(...

Dopo aver aggiunto i nomi delle variabili complete (che non è stato possibile accorciare), puoi immaginare quanto fossero lunghe alcune semplici chiamate di metodo. Parola lunga e avvolgente.

3
Kirk Broadhurst

Dove sto lavorando ora il processo di denominazione delle variabili per tutto ciò che riguarda il database è:

  • $ sql per le dichiarazioni
  • $ risultato per i risultati della query

Il che ha senso, tuttavia, quando ho sollevato la questione che la convenzione era troppo generica e che ciò si sarebbe concluso con una sovrapposizione variabile, la risposta era "usa result_alt o sql_alt". I miei sentimenti nel commentare, se hai usato nomi di variabili appropriati che significano scopo non avresti bisogno di commenti o di molti di essi.

2
chrisw

Il peggior standard di codifica che abbia mai dovuto seguire era "Tutti i nomi delle variabili oggetto devono essere preceduti da 'obj'". Questo era su un grande Java, quindi quasi tutto era un oggetto. La parte peggiore era, quasi tutti hanno adottato una politica di denominazione delle variabili semplicemente anteponendo "obj" al nome della classe. Abbiamo finito con cose come Person objPerson1 in tutto il codice. Ho obiettato una volta e ho fatto interpellare uno degli altri sviluppatori che le piaceva la convenzione "perché non devo pensare ai miei nomi di variabili". Quel posto è stato un vero orrore.

2
TMN

Forse lo standard di codifica della Huawei Software Company. Vogliono che tu dichiari tutti i membri pubblici :))

2
LostMohican

Scrivere qualcosa in Fortran ( WATFOR , FORTRAN 77 ) in cui un carattere non bianco nella colonna 1 era un commento e il compilatore non ti avvertiva se avessi superato la colonna 72, l'avrebbe semplicemente ignorato.

Almeno ho passato solo sette anni a farlo.

2
Mark Thalman

Avendo ciò che equivaleva a file di intestazione C, in un Java.

Le interfacce esistono per alcuni buoni motivi, ma questo standard imponeva un'interfaccia (foo.Java) per ogni singola classe (fooImpl.Java) se avesse un senso o meno. Un sacco di cose da tenere in sincronia, completa interruzione del metodo click-in-metodo di Eclipse, inutile lavoro occupato.

Il sistema di build lo ha imposto, ma non riesco a immaginare quale fosse lo scopo originale. Fortunatamente l'abbiamo abbandonato per un nuovo codice quando siamo passati a un nuovo sistema di controllo versione e build, ma ce n'è ancora molto.

Allo stesso tempo, abbiamo anche abbandonato l'abitudine stupida di controllo della versione-informazioni-in-file-commenti che era stata obbligatoria.

2
user763

Attualmente lavoro in un'azienda in cui le query SQL vengono eseguite tramite qualcosa chiamato "Classe richiesta". Quanto è ridicolo:

In "include/request.class.php"

class RequestClass
{
    // ... some code.

    public function getUser($where)
    {
        global $initrequest

        $sql = $initrequest['users']
        $sql.= $where;

        return execute($sql);
    }
}

In initrequest.php:

$initrequest['users'] = 'SELECT * FROM users WHERE ';

Ed è stato chiamato dall'applicazione in questo modo:

$request = new request();
$tmpquery = "username = $username AND password = $password";
$request->getUsers($tmpquery);

E hanno un sistema di template simile basato su "blocchi", ma dopo aver capito cosa mostro qui, ho continuato a premere per eliminare l'intero software e riscriverlo in Symfony.

2
Arie Deckelmann

Non è consentita più di una riga di codice in Main ()

Un professore della mia università che ho avuto la fortuna di non aver insistito sul fatto che ai suoi studenti C # junior non fosse permesso inserire più di una riga di codice nel punto di ingresso delle loro applicazioni console.

Questo ha un ragionevole senso quando si sviluppa un'applicazione professionale, ma quando l'unico intento del programma è quello di prendere pochi input di base e produrre un singolo output (cioè MultiplyTwoNumbers.exe), tale requisito è più doloroso che buono.

Oltre all '"una riga di codice in main" il professore ha anche insistito sul fatto che ogni riga di codice ha un commento descrittivo e ogni membro della classe ha un nome descrittivo verbosely. Punti persi se il professore non riteneva che tali requisiti fossero stati "adeguatamente" soddisfatti.

Gli studenti costretti a rispettare queste regole erano (quasi) tutti i neofiti della programmazione e quindi posso vedere il valore di far rispettare comportamenti come il buon nome e la separazione delle preoccupazioni. Nonostante ciò, come .NET Tutor presso la mia università aiutavo costantemente i suoi studenti a soddisfare questi requisiti banali e odiosi molto tempo dopo aver ottenuto il loro codice funzionante.

Secondo me, quando educare qualcuno che è nuovo di zecca in un linguaggio di programmazione, la prima preoccupazione dovrebbe essere come creare codice, non come creare basato su standard codice.

1
Nathan Taylor

"Non utilizzare lo stile di commento C++ per il codice C".

Anche se questo può avere ancora un piccolo valore se c'è il rischio di dover trasferire il tuo programma su un compilatore obsoleto, è principalmente solo una seccatura. La mia più grande obiezione è che rende davvero difficile usare /* per bloccare il commento di una vasta area durante lo sviluppo o il test dell'unità. */

1
AShelly

Il mio docente ADA presso uni ha insistito sul fatto che ogni metodo avesse un commento che delineava precondizioni, postcondizioni e grande O. Il problema più grande era che non si è mai preso la briga di spiegare cosa significasse realmente O grande e non ha mai verificato se fossero corretti, quindi mi sono trovato a copiare e incollare questo blocco di commenti centinaia di volte.

-- Method_Name
-- PRECONDITIONS: none
-- POSTCONDITIONS: none
-- O(n) = n
1
Christopher

(C++)

Tutti i valori di ritorno dovevano essere HRESULTS (quelli standard - non i hresults definiti dall'utente)

Questo è stato solo pochi anni fa. Le persone anziane erano ancora così infatuate di COM e non hanno mai letto o appreso di altre migliori pratiche. Era un ambiente incredibilmente chiuso.

Lo stesso posto non ha permesso l'utilizzo di STL.

Sono partito poco dopo aver scoperto quella notizia.

1
Tim

In Visual Basic 6. , abbiamo dovuto aggiungere errori nella gestione dei blocchi a ogni singolo metodo. Nessuna eccezione. Così abbiamo fatto.

Quindi abbiamo dovuto spiegare perché alcune parti dell'applicazione erano lente.

1
Chris Brandsma

Lo spazio limitato per i nomi di variabili/oggetti è probabilmente la mia più grande irritazione. Ho lavorato in un linguaggio proprietario relativamente moderno che consente solo 10 caratteri. Questo è un holdover dalle sue versioni originali.

Il risultato netto è che ti ritrovi con convenzioni di denominazione divertenti che definiscono cosa deve rappresentare ogni personaggio del tuo 10 autorizzato. Qualcosa di simile a:

  • 1-3: prefisso dell'applicazione
  • 4-6: prefisso del modulo
  • 7-9: sezione definita dall'utente
  • 10: un numero nel caso in cui due ... o 9 abbiano lo stesso nome.
1
Brad Gardner

Il mio preferito dovrebbe essere le linee guida per la denominazione del database che attualmente stiamo cercando di rispettare. Tutte le tabelle utilizzate per molte relazioni devono essere denominate utilizzando i nomi delle tabelle collegate e devono essere suffissate con "Collegamento". E, naturalmente, nessuna pluralizzazione dei nomi delle tabelle.

  • OrderLines? No. Dovrebbe essere chiamato OrderProductLink
  • Amici? No. Dovrebbe essere PersonPersonLink
1
CodingInsomnia

Essere costretti ad aggiungere una descrizione del file in ogni file (è un progetto C # ).

// --------------------------------------------------------------------------------------------------------------------
// <copyright file="User.cs" company="Company">
//   Copyright (C) 2009 Company. All rights reserved.
// </copyright>
// <summary>
//   The user.
// </summary>
// --------------------------------------------------------------------------------------------------------------------
0
Carl Bergquist

In un'azienda dovevamo scrivere documentazione tecnica che spiegasse come scriveremo una funzionalità. È diventato rapidamente obsoleto poiché non penserai a tutto quando stai programmando in UML.

0
IAdapter