Pior padrão de codificação que você já teve que seguir? [fechadas]

Você já teve que trabalhar para padrões de codificação que:

• Diminuiu bastante sua produtividade?
• Foram originalmente incluídos por boas razões, mas foram mantidos muito tempo depois que a preocupação original se tornou irrelevante?
• Estavam em uma lista há tanto tempo que era impossível lembrar de todos eles?
• Você achou que o autor estava apenas tentando deixar sua marca em vez de incentivar boas práticas de codificação?
• Você não tinha ideia de por que eles foram incluídos?

Se sim, qual é a sua regra menos favorita e por quê?

Alguns exemplos aqui

Isso pode irritar algumas penas, mas os padrões que exigem modelos de comentários em bloco na parte superior de cada método sempre me incomodam.

1) Eles estão sempre desatualizados, pois estão muito longe do código que faz o trabalho real para serem notados quando você está atualizando as coisas. Comentários ruins são piores do que nenhum comentário.

2) Frequentemente, apenas repetem as informações que já estão contidas na ferramenta de controle de origem, apenas menos precisas. Por exemplo: Última modificação por, lista de data / motivos da modificação.

Teve um professor uma vez que exigiu que tivéssemos pelo menos um comentário para cada linha de código.

//Set x to 3
var x = 3;

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

    //Print x
    Print(x);
}

Foi bastante ridículo.

O padrão de codificação da nossa empresa (C #) exigia o uso extensivo de #REGIONs (para quem não sabe, marca blocos de código-fonte que serão recolhidos em uma única linha no Visual Studio). Como conseqüência, você sempre abriu o que parecia ser uma classe bem estruturada, apenas para encontrar pilhas e pilhas de lixo varridas por tapetes profundamente aninhados das construções #REGION. Você teria regiões em torno de linhas únicas, por exemplo, ter que dobrar uma região LOG para dobrar para encontrar uma única declaração do Logger. Obviamente, muitos métodos adicionados após a criação de alguma região também foram colocados no escopo da região "errado". O horror. O horror.

As regiões são um dos piores recursos já adicionados ao Visual Studio; incentiva a estruturação da superfície em vez da estrutura OO real.

Hoje em dia, eu mato #REGIONs à vista.

Em um trabalho, fomos forçados a usar alguma forma estranha de notação húngara no banco de dados.

Não me lembro dos detalhes, mas de memória, cada nome de campo precisava conter:

• Sem vogais
• Todas as letras maiúsculas
• Uma referência à tabela
• Um indicador de tipo de dados
• Um comprimento de dados
• Um indicador anulável

Por exemplo, a coluna que contém o primeiro nome de uma pessoa pode ser chamada: PRSNFRSTNMVC30X(Tabela de pessoas, coluna Nome, Varchar 30 caracteres, Não nulo)

Insistindo para que todas as chaves sejam seguidas de um comentário sobre o que a chave termina:

por exemplo:

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   ==

disse nuff.

• Os nomes de variáveis ​​locais estão todos em minúsculas sem sublinhados

Exemplos reais: paymentmethodtotalshtml, contracttypechangecontexts, customsegmentspectexts,potentialmsceventref

O New York Times avalia :

“Os espaços do Word não devem ser tomados como garantidos. O grego antigo, o primeiro alfabeto a apresentar vogais, poderia ser decifrado sem espaços de palavras, se você o tocasse, e sem eles. [...] O latim também deixou de separar as palavras no segundo século. A perda é intrigante, porque os olhos precisam trabalhar muito mais para ler textos não separados. Mas, como explicou o paleógrafo Paul Saenger, o mundo antigo não desejava 'tornar a leitura mais fácil e rápida' ”.

Fui convidado pelo líder de uma empresa de software para fazer " simples, re n código redundantes ". Foi proibido, por exemplo, adicionar um novo parâmetro a uma função existente. Você teve que duplicar a função, deixando o original intocado para evitar regressões. Sem testes formais, é claro (perda de tempo).

Também fomos proibidos de usar software de mesclagem; cada arquivo só pode ser modificado por um programador por vez. O software de controle de revisão era ficção científica, é claro.

O dia mais feliz da minha vida foi quando ele foi demitido (considere que é muito, muito difícil demitir alguém na Itália).

Toda interação com o banco de dados deve ser feita através de procedimentos armazenados . Pode fazer sentido se moramos em 1997 e não em 2010.

Acabei de perceber que isso realmente cobre todos os critérios da pergunta original:

• Diminuiu bastante sua produtividade? VERIFICA. Por favor - basta usar um ORM .
• Foram originalmente incluídos por boas razões, mas foram mantidos muito tempo depois que a preocupação original se tornou irrelevante? VERIFICA. O gerente foi desenvolvedor de um servidor de banco de dados há 1000 anos e inseriu esse padrão de codificação.
• Estavam em uma lista há tanto tempo que era impossível lembrar de todos eles? VERIFICA. Isso inclui 'o máximo possível de lógica deve ser armazenada no banco de dados'.
• Você achou que o autor estava apenas tentando deixar sua marca em vez de incentivar boas práticas de codificação? VERIFICA. Continua voltando ao gerente como um ex-desenvolvedor de servidor de banco de dados.
• Você não tinha ideia de por que eles foram incluídos? VERIFICA.

Não sendo permitido usar o STL ou outras bibliotecas C ++ padrão porque o CTO acreditava que 'nós' poderíamos fazê-lo melhor e mais rapidamente. Mesmo construções básicas, como listas e a classe de string.

Notação húngara

Amostra extraída da " explicação de Charles Simonyi da convenção de nomeação de identificador de notação húngaro " no MSDN.

1 #include "sy.h"
2 extern int * rgwDic;
3 extern int bsyMac;
4 estrutura SY * PsySz (char sz [])
6 {
7 char * pch;
8 int cch;
9 struct SY * psy, * PsyCreate ();
10 int * pbsy;
11 int cwSz;
12 wHash não assinado = 0;
13 pch = sz;
14 while (* pch! = 0
15 wHash = (wHash11 + * pch ++;
16 cch = pch-sz;
17 pbsy = & rgbsyHash [(wHash & 077777)% cwHash];
18 para (; * pbsy! = 0; pbsy = & psy-> bsyNext)
19 {
20 caracteres * szSy;
21 szSy = (psy = (estrutura SY *) & rgwDic [* pbsy]) -> sz;
22 pch = sz;
23 while (* pch == * szSy ++)
24 {
25 if (* pch ++ == 0)
26 retorno (psy);
27}
28}
29 cwSz = 0;
30 se (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 retorno (psy);
36}

Certa vez, trabalhei em um projeto no qual o líder do projeto exigia que todas as variáveis ​​- TODAS as variáveis ​​- fossem prefixadas com "v". Portanto, vCount, vFirstName, vIsWarranty etc.

Por quê? "Porque estamos trabalhando em VBScript e tudo é uma variante de qualquer maneira".

WTF.

Quase esqueci este:

Citação de um gerente:

Não corrija ou documente os erros encontrados no seu próprio código. O cliente nos pagará para identificá-los e corrigi-los nos próximos anos.

Isso não era para software de consumo, mas personalizado para uma única organização grande. Desnecessário dizer que o cliente pagou anos depois. Pode parecer trivial, mas tentar ignorar erros é mais difícil do que encontrá-los.

Comentários XML forçados em todos os métodos, constantes, enumerações e propriedades não particulares.

Isso levou a um código bastante confuso, especialmente porque o resultado final foi que as pessoas estavam apenas pressionando /// para criar um esboço de comentário vazio para tudo ou instalando o GhostDoc e adicionando comentários gerados automaticamente:

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

[Editar] A razão de eu mencionar isso como um padrão ridículo não é porque acho que os comentários dos métodos são estúpidos, mas porque a qualidade desses comentários não foi imposta de maneira alguma e resultou na criação de muita e desorganização nos arquivos de código. . Existem maneiras melhores de criar documentos de código significativos do que o requisito de compilação "deve ter um comentário" cego.

Não é realmente um padrão de codificação, mas tínhamos um arquivo no controle de origem chamado 'changelog.txt'

Toda vez que você fazia um check-in, era necessário adicionar manualmente uma entrada nesse arquivo. Esta entrada foi o número de revisão do subversion e seu comentário no check-in.

Quando o novo CTO começou e alguém lhe disse isso, ele prontamente tomou uma decisão executiva e disse: "Não vamos mais fazer isso" e excluiu o arquivo. Isso vinha acontecendo há anos.

Alguns dos lugares com os quais trabalhei insistiram em comentar o código não utilizado ou reprovado em vez de excluí-lo. Em vez de confiar no VCS para a história, etc., ele foi dolorosamente mantido nos arquivos por meio de um código comentado.

O grande problema que encontrei com isso é que muitas vezes você não fazia ideia do motivo pelo qual o código foi comentado. Foi porque algum desenvolvedor estava fazendo mudanças ativamente e queria mantê-lo por referência ou não era mais necessário?

O pior padrão de codificação em que já participei é de bases de código que não possuíam nenhuma. Prefiro seguir um padrão de codificação em que discordo completamente do que trabalhar em bases de código onde não há nenhuma. Isso torna muito mais difícil aprender novas partes da base de código.

Forçar comentários embutidos para controle de versão foi o padrão de codificação mais inútil que eu ignorei.

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

O DBA Oracle que insistiu no uso correto do espaço em branco enquanto "mantinha" um banco de dados com uma tabela altamente disputada que tinha mais de 200 campos e 40 gatilhos se aproxima.

Fiz revisões de código em um projeto liderado por um primeiro timer de C ++ que decidiu que todas as funções de membro da classe deveriam ser prefixadas com o nome e a visibilidade da classe:

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

Sendo necessário recuar todo o código por quatro espaços;)

Eu tinha um emprego anos atrás, onde todo o nosso código tinha que ser alinhado à esquerda - sem recuo. O cara que criou essa política não gostava de rolar para frente e para trás horizontalmente ao visualizar longas linhas de código, equiparando-o a jogar pingue-pongue com os olhos.

Este é mais um exemplo de como não ter padrões de codificação pode prejudicar.

Um contratado que trabalhava em um grande banco insistia que seguir os padrões era o melhor de sempre. O aplicativo foi escrito no dBase / Clipper, do qual ele foi o único desenvolvedor e, é claro, ele apresentou o padrão.

• Tudo está em maiúsculas. Quero dizer tudo, incluindo os raros comentários que ele fez.
• Sem recuo.
• A nomeação variável era algo parecido com APRGNAME. A = escopo da variável, por exemplo, P para público, PRG = três primeiros caracteres do arquivo de origem que criou a variável, NAME = nome da variável nos 6 caracteres restantes permitidos pelo dBase / Clipper.
• As primeiras 4 e 4 últimas linhas do código-fonte tinham 80 * de comprimento. Por quê? Para que ele pudesse ouvir a impressora matricial iniciando e terminando a impressão de um arquivo. A memória é que todo o programa foi impresso via mainframe semanalmente, 20.000 páginas.
• Tenho certeza de que havia muito mais que consegui despejar do meu cérebro.

Eu era um programador autodidata muito novo naquele estágio, mas sabia o suficiente para não ouvir o cientista louco e sair dali antes de pedir para assumir o projeto.

E sim, dissemos à gerência como essas práticas eram ruins, mas sempre obtivemos o habitual "estavam pagando esse dólar alto do contratante, ele deve saber do que está falando".

Mais uma explosão do meu passado.

Citação do proprietário da empresa:

Não haverá código escrito usando linguagens interpretativas, porque perdi 25 milhões nesse projeto {expletive} escrito em Java.

O projeto Java era um sistema de negociação de ações projetado para lidar com algumas dezenas de ações, que agora estava sendo usado para processar milhares. Em vez de abordar as falhas de design ou o hardware insuficiente, toda a empresa foi forçada a converter todos os aplicativos não C / C ++ em C / C ++, e todo o novo desenvolvimento teve que ser em C / C ++. Linguagens interpretativas significavam algo não compilado, e o proprietário considerava apenas o Assembler, C e C ++ compilado.

Para uma empresa de 800 pessoas, na qual a maior parte do código estava em Java e Perl, isso significava que a empresa inteira passava a maior parte do tempo nos próximos dois anos reescrevendo perfeitamente o código em C / C ++.

Engraçado, cerca de vinte anos antes desse fiasco, eu estava em outra empresa na qual o líder técnico decidiu que nossa lógica de classificação (era um Bubble Sort) precisava ser recodificada no assembler em vez de ser substituída pelo Quick Sort porque - os algoritmos não melhorar o desempenho. A única maneira de melhorar o desempenho era reescrever a mesma lógica no assembler.

Nos dois casos, saí logo depois que os ditames caíram.

Como muitos programadores (mas não o suficiente), odeio a decoração de código. Isso me enfurece quando preciso usar um prefixo de cifrão ($) para nomes de variáveis ​​ou sublinhados para variáveis ​​privadas, mesmo sem getters / setters. Se você precisar decorar seu código para entendê-lo, precisará dar o fora!

Estou trabalhando com um sistema da Web há algum tempo, em que todos os parâmetros passados ​​tinham que ser nomeados P1, P2, P3 etc. Não há chance de saber o que eles querem sem documentação extensa.

Além disso - embora não seja estritamente um padrão de codificação - no mesmo sistema, cada arquivo deve ser nomeado xyz0001.ext, xyz0002.ext, xyz0003.ext, etc - em que xyz era o código do aplicativo em si.

Isso foi há muito tempo - 1976, para ser exato. Meu chefe nunca tinha ouvido falar de Edsger Dijkstra ou lido uma edição do CACM, mas havia ouvido rumores de algum lugar que "GOTO é ruim"; portanto, não é permitido o uso de GOTO em nossos programas COBOL. Isso foi antes de a COBOL adicionar o "fim se", então, na época, havia apenas duas e meia das três estruturas de controle clássicas (sequência, se / então / outra, execução (ou seja, faça enquanto)). De má vontade, ele autorizou o GOTO em nossos programas básicos e instruções de ramificação em nossos programas em linguagem Assembler.

Lamentamos que este seja um tipo de história "você tinha que estar lá". Tanto quanto sei, toda linguagem inventada desde 1976 possui estruturas de controle adequadas para que você nunca precise usar o GOTO. Mas a questão é que o chefe nunca sabia por que o GOTO era considerado prejudicial ou qual idioma era o distúrbio infantil e qual era a doença fatal.

Eu trabalhei em um projeto onde o principal arquiteto exigia escrever (também) código explícito. Um dos piores exemplos que encontrei no código (e ele aprovou com satisfação) foi o seguinte.

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

Até o ReSharper disse que isso está errado!

No meu último emprego, "padrões" seria um termo muito forte para o que me foi dado pelo cara que me contratou. Ao programar sites no ColdFusion e SQL, recebi requisitos de codificação como:

• Não use includes. Eu gosto de uma página grande
• Sempre separe as palavras nos nomes de variáveis ​​e colunas com sublinhados (exceto isactive, firstname etc.)
• Nunca use abreviações - sempre escreva o primeiro nome (ele frequentemente escreve fname e assim por diante)
• Não use nomes confusos (como amount_charged e charge_amount, que medem coisas diferentes, mas relacionadas)
• Não use DIVs e use CSS mínimo - use tabelas aninhadas (encontrei uma profundidade de seis camadas uma vez).
• Não armazene em cache nenhuma consulta. Sempre.
• Vai usar uma variável em mais de uma página? Escopo do aplicativo.
• Cada página é seu próprio bloco try / catch. Não precisamos / queremos um manipulador de erros global.

Comecei a mudar isso assim que ele saiu.

Na minha vida como codificador C ++, duas "regras" realmente desagradáveis ​​foram aplicadas:

1. "Não podemos usar o STL, porque o VC ++ 4.1 não o suporta (e não podemos mudar para o VC ++ 6.0 no momento)."
2. "Você não usar QuickSort, porque pode ser O (n ^ 2) em casos graves; usar esta implementação do algoritmo heapsort I (nome do líder do projeto excluído) escreveu como um estudante."

Sou forçado a ter documentação XML para todas as classes e membros da classe. Incluindo privado. Estou encantado de usar os comentários padrão do ghostdoc.

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