Qual foi a regra mais estranha de padrão de codificação que você foi forçado a seguir? [fechadas]

Quando fiz essa pergunta , quase sempre tive um sim definitivo, você deveria ter padrões de codificação.

Qual foi a regra mais estranha de padrão de codificação que você foi forçado a seguir?

E, por mais estranho, quero dizer mais engraçado, ou pior, ou simplesmente estranho.

Em cada resposta, mencione qual idioma, qual era o tamanho da sua equipe e quais os efeitos negativos que isso causou a você e à sua equipe.

Eu odeio quando o uso de vários retornos é proibido.

recuo reverso. Por exemplo:

    for(int i = 0; i < 10; i++)
        {
myFunc();
        }

e:

    if(something)
        {
// do A
        }
    else
        {
// do B
    }

Talvez não seja o mais bizarro que você conseguirá, mas eu realmente odeio quando tenho que preceder nomes de tabelas de banco de dados com 'tbl'

Quase qualquer tipo de notação húngara.

O problema da notação húngara é que ela é muitas vezes incompreendida. A idéia original era prefixar a variável para que o significado fosse claro. Por exemplo:

int appCount = 0; // Number of apples.
int pearCount = 0; // Number of pears.

Mas a maioria das pessoas o usa para determinar o tipo.

int iAppleCount = 0; // Number of apples.
int iPearCount = 0;  // Number of pears.

Isso é confuso, porque, embora ambos os números sejam inteiros, todo mundo sabe, você não pode comparar maçãs com peras.

Nenhum operador ternário permitido onde atualmente trabalho:

int value = (a < b) ? a : b;

... porque nem todo mundo "entende". Se você me dissesse: "Não use porque tivemos que reescrevê-las quando as estruturas ficarem muito complicadas" (operadores ternários aninhados, alguém?), Então eu entenderia. Mas quando você me diz que alguns desenvolvedores não os entendem ... hum ... Claro.

NUNCA remova qualquer código ao fazer alterações. Disseram-nos para comentar todas as alterações. Tenha em mente que usamos o controle de origem. Essa política não durou muito, porque os desenvolvedores estavam em polvorosa e como isso tornaria o código ilegível.

Certa vez, trabalhei sob a tirania do Mighty VB King .

O VB King era o mestre puro do MS Excel e VBA, além de bancos de dados ( daí seu sobrenome: ele brincava com o Excel enquanto os desenvolvedores trabalhavam com compiladores, e desafiá-lo nos bancos de dados poderia ter efeitos negativos sobre sua carreira ... ).

Obviamente, suas imensas habilidades lhe deram uma visão única dos problemas de desenvolvimento e das soluções de gerenciamento de projetos: embora não exatamente os padrões de codificação no sentido mais estrito, o VB King regularmente tinha novas idéias sobre "padrões de codificação" e "melhores práticas" que ele tentava (e muitas vezes conseguiu) nos impor. Por exemplo:

• Todas as matrizes C / C ++ devem começar no índice 1, em vez de 0. De fato, o uso de 0 como primeiro índice de uma matriz é obsoleto e foi substituído pelo gerenciamento perspicaz de índices de matriz do Visual Basic 6.

• Todas as funções retornarão um código de erro: Não há exceções no VB6, então por que precisaríamos delas? ( ou seja, em C ++ )

• Como "Todas as funções retornam um código de erro" não é prático para as funções que retornam tipos significativos, todas as funções devem ter um código de erro como o primeiro parâmetro [in / out].

• Todo o nosso código verificará os códigos de erro ( isso levou ao pior caso de indentação de VBScript que eu já vi na minha carreira ... É claro, como as cláusulas "else" nunca foram tratadas, nenhum erro foi encontrado até tarde demais )

• Como estamos trabalhando com C ++ / COM, a partir deste dia, codificaremos todas as nossas funções do utilitário DOM no Visual Basic.

• Erros ASP 115 são maus. Por esse motivo, usaremos On Error Resume Next em nosso código VBScript / ASP para evitá-los.

• XSL-T é uma linguagem orientada a objetos. Use a herança para resolver seus problemas (a surpresa idiota quase quebrou minha mandíbula neste dia ).

• Exceções não são usadas e, portanto, devem ser removidas. Por esse motivo, desmarcaremos a caixa de seleção solicitando a chamada de destruidor em caso de exceção, que levou um dia para que um especialista descobrisse a causa de todos esses vazamentos de memória, e ele quase enlouqueceu ao descobrir que havia ignorado voluntariamente (e oculto) sua nota técnica sobre a verificação da opção novamente, enviada várias semanas antes ).

• capturar todas as exceções na interface COM de nossos módulos COM e descartá-las silenciosamente ( dessa maneira, em vez de travar, um módulo pareceria ser mais rápido ... Brilhante! ... Como usamos o über tratamento de erros descrito acima, até demoramos algum tempo para entender o que realmente estava acontecendo ... Você não pode ter tanto velocidade quanto resultados corretos, pode? ).

• A partir de hoje, nossa base de código será dividida em quatro ramos. Gerenciaremos sua sincronização e integraremos todas as correções / evoluções de erros manualmente.

Todos, exceto os arrays C / C ++ , as funções do utilitário VB DOM e o XSL-T como linguagem OOP foram implementados apesar de nossos protestos. Claro que, ao longo do tempo, alguns foram descobertos, ahem , quebrado, e abandonado por completo.

Obviamente, a credibilidade do VB King nunca foi prejudicada por isso: entre os altos escalões, ele permaneceu um especialista técnico "top gun" ...

Isso produziu alguns efeitos colaterais divertidos, como você pode ver seguindo o link Qual é o melhor comentário no código-fonte que você já encontrou?

Nos anos 80/90, trabalhei em uma empresa de simulador de aeronaves que usava o FORTRAN. Nosso compilador FORTRAN tinha um limite de 8 caracteres para nomes de variáveis. Os padrões de codificação da empresa reservaram os três primeiros para informações sobre o estilo de notação húngara. Então tivemos que tentar criar nomes de variáveis ​​significativos com apenas 5 caracteres!

Eu trabalhei em um lugar que tinha uma fusão entre duas empresas. O servidor 'dominante' tinha um servidor principal escrito em K&R C (ou seja, pré-ANSI). Eles forçaram as equipes de Java (de ambos os escritórios - provavelmente 20 desenvolvedores no total) a usar esse formato, que ignorou alegremente os 2 pilares do "debate de chaves" e ficou louco:

if ( x == y ) 
    {
    System.out.println("this is painful");
    x = 0;
    y++;
    }

Proibido:

while (true) {

Permitido:

for (;;) {

um amigo meu - vamos chamá-lo de CodeMonkey - conseguiu seu primeiro emprego na faculdade [ há muitos anos], desenvolvendo internamente a COBOL. Seu primeiro programa foi rejeitado por 'não estar em conformidade com nossos padrões' porque usava ... [estremece!] Declarações IF aninhadas

os padrões de codificação proibiram o uso de instruções IF aninhadas

agora, CodeMonkey não era tímido e tinha certas habilidades, então ele insistiu em perguntar a todos pela cadeia e pelo corredor por que essa regra existia. A maioria alegou que não sabia, alguns inventaram coisas sobre 'legibilidade' e, finalmente, uma pessoa lembrou-se do motivo original: a primeira versão do compilador COBOL que eles usavam tinha um bug e não lidava com instruções IF aninhadas corretamente.

É claro que esse bug do compilador havia sido corrigido por pelo menos uma década, mas ninguém havia desafiado os padrões . [baaa!]

O CodeMonkey foi bem-sucedido em mudar os padrões - eventualmente!

Uma vez trabalhou em um projeto onde os sublinhados foram proibidos. E eu quero dizer totalmente banido. Portanto, no aplicativo ac # winforms, sempre que adicionamos um novo manipulador de eventos (por exemplo, para um botão), é necessário renomear o nome do método padrão de buttonName_Click () para outra coisa, apenas para satisfazer o ego do cara que escreveu a codificação padrões. Até hoje eu não sei o que ele tinha contra o humilde sublinhado

Convenções de nomenclatura de banco de dados totalmente inúteis. Todo nome de tabela deve começar com um número. Os números mostram que tipo de dados está na tabela.

• 0: dados usados ​​em qualquer lugar
• 1: dados usados ​​apenas por um determinado módulo
• 2: tabela de pesquisa
• 3: calendário, bate-papo e correio
• 4: registro

Isso torna difícil encontrar uma tabela se você souber apenas a primeira letra do nome. Além disso - como este é um banco de dados mssql -, precisamos cercar os nomes de tabelas entre colchetes em todos os lugares.

-- doesn't work
select * from 0examples;

-- does work
select * from [0examples];

Estávamos fazendo um projeto em C ++, e o líder da equipe era o Pascal.

Portanto, tínhamos um arquivo de inclusão padrão de codificação para redefinir toda a sintaxe irritante de C e C ++:

#define BEGIN {
#define END }

mas espere, tem mais!

#define ENDIF }
#define CASE switch

É difícil lembrar depois de todo esse tempo.

Isso pegou o que seria um código C ++ perfeitamente legível e o tornou ilegível para qualquer pessoa, exceto o líder da equipe.

Também tivemos que usar a notação húngara reversa, ou seja,

MyClass *class_pt  // pt = pointer to type

UINT32 maxHops_u   // u = uint32

embora, estranhamente, eu tenha gostado disso.

Em um emprego anterior:

• As tabelas "normais" começam com T_
• As tabelas "Sistema" (geralmente pesquisas) começam com TS_ (exceto quando não acontecem porque alguém não sentiu vontade naquele dia)
• As tabelas de referência cruzada começam com TSX_
• Todos os nomes de campos começam com F_

Sim está certo. Todos os campos, em todas as tabelas. Para que possamos dizer que é um campo.

Um amigo meu encontrou essa regra enquanto trabalhava em um emprego no governo. O uso de ++ (pré ou pós) foi completamente banido. O motivo: compiladores diferentes podem interpretá-lo de maneira diferente.

Metade da equipe era a favor da indentação em quatro espaços; a outra metade era a favor da indentação de dois espaços.

Como você pode imaginar, o padrão de codificação exigia três, de modo a "ofender a todos igualmente" (uma citação direta).

Não poder usar o Reflection, pois o gerente alegou que isso envolvia muita 'mágica'.

O mais estranho que eu já tive, e que me levou algum tempo para ser derrubado, foi quando o proprietário de nossa empresa exigiu que nosso novo produto fosse apenas o IE. Se pudesse funcionar no FireFox, tudo bem, mas tinha que ser apenas o IE.

Isso pode não parecer muito estranho, exceto por uma pequena falha. Todo o software era para um pacote de software de servidor sob medida, em execução no Linux, e todas as caixas de clientes que nosso cliente estava comprando eram Linux. Antes de tentar descobrir como colocar o Wine (naqueles dias, muito pouco confiável) em funcionamento em todas essas caixas e ver se poderíamos colocar o IE em execução e treinar seus administradores como depurar problemas do Wine, simplesmente não era possível para atender à solicitação do proprietário. O problema era que ele estava fazendo o design da Web e simplesmente não sabia como tornar os sites compatíveis com o FireFox.

Provavelmente não ficará chocado ao saber que nossa empresa faliu.

Usando nomes genéricos de identificador numerado

No meu trabalho atual, temos duas regras que são realmente más:

Regra 1: Toda vez que criamos um novo campo em uma tabela de banco de dados, precisamos adicionar campos de reserva adicionais para uso futuro. Esses campos de reserva são numerados (porque ninguém sabe quais dados eles manterão algum dia). Da próxima vez que precisarmos de um novo campo, primeiro procuraremos um campo de reserva não utilizado.

Então, acabamos customer.reserve_field_14contendo o endereço de email do cliente.

Um dia, nosso chefe pensou em introduzir tabelas de reserva , mas felizmente poderíamos convencê-lo a não fazê-lo.

Regra 2: Um de nossos produtos é escrito em VB6 e o ​​VB6 tem um limite da contagem total de nomes de identificadores diferentes e, como o código é muito grande, constantemente encontramos esse limite. Como uma "solução", todos os nomes de variáveis ​​locais são numerados:

• Lvarlong1
• Lvarlong2
• Lvarstr1
• ...

Embora isso contorne efetivamente o limite do identificador, essas duas regras combinadas levam a um código bonito como este:

...

If Lvarbool1 Then
  Lvarbool2 = True
End If

If Lvarbool2 Or Lvarstr1 <> Lvarstr5 Then
  db.Execute("DELETE FROM customer WHERE " _ 
      & "reserve_field_12 = '" & Lvarstr1 & "'")
End If

...

Você pode imaginar como é difícil corrigir o código antigo ou de outra pessoa ...

Última atualização: Agora também estamos usando "procedimentos de reserva" para membros privados:

Private Sub LSub1(Lvarlong1 As Long, Lvarstr1 As String)
  If Lvarlong1 >= 0 Then 
    Lvarbool1 = LFunc1(Lvarstr1)
  Else
    Lvarbool1 = LFunc6()
  End If
  If Lvarbool1 Then
    LSub4 Lvarstr1
  End If
End Sub

EDIT: Parece que esse padrão de código está se tornando cada vez mais popular. Veja este post do The Daily WTF para saber mais: Astigmatismo :)

Nos meus dias em C ++, não tínhamos permissão para usar ==,> =, <=, &&, etc. havia macros para isso ...

if (bob EQ 7 AND alice LEQ 10)
{
   // blah
}

obviamente era para lidar com a "antiga atribuição acidental no bug condicional", no entanto, também tínhamos a regra "colocar constantes antes das variáveis", então

if (NULL EQ ptr); //ok
if (ptr EQ NULL); //not ok

Recorde-me que o padrão de codificação mais simples que já ouvi foi "Escreva código como se o próximo mantenedor fosse um psicopata cruel que sabe onde você mora".

Notação húngara em geral.

Eu tive muitas regras estúpidas , mas não muitas que eu considerei completamente estranhas.

O mais bobo foi em um trabalho da NASA em que trabalhei no início dos anos 90. Foi um trabalho enorme, com mais de 100 desenvolvedores. Os desenvolvedores experientes que escreveram os padrões de codificação decidiram que todo arquivo de origem deveria começar com um acrônimo de quatro letras, e a primeira letra representava o grupo responsável pelo arquivo. Provavelmente, essa foi uma ótima idéia para os antigos projetos do FORTRAN 77 aos quais estavam acostumados.

No entanto, este era um projeto Ada , com uma boa estrutura hierárquica de bibliotecas, por isso não fazia sentido algum. Cada diretório estava cheio de arquivos começando com a mesma letra, seguidos por mais 3 letras sem sentido, um sublinhado e parte do nome do arquivo que importava. Todos os pacotes Ada tiveram que começar com a mesma verruga de cinco caracteres. As cláusulas ada "use" também não eram permitidas (sem dúvida uma coisa boa em circunstâncias normais), de modo que qualquer referência a qualquer identificador que não fosse local para esse arquivo de origem também precisava incluir essa verruga inútil. Provavelmente deveria ter havido uma insurreição sobre isso, mas todo o projeto foi composto por programadores juniores e recém-contratados pela faculdade (sendo eu o último).

Uma declaração de atribuição típica (já detalhada em Ada) acabaria parecida com esta:

NABC_The_Package_Name.X := NABC_The_Package_Name.X + 
  CXYZ_Some_Other_Package_Name.Delta_X;

Felizmente, eles foram pelo menos esclarecidos o suficiente para nos permitir mais de 80 colunas! Ainda assim, a verruga da instalação foi odiada o suficiente para se tornar um código padrão no topo dos arquivos de origem de todos, para usar Ada "renomeia" para se livrar da verruga. Haveria uma renomeação para cada pacote importado ("withed"). Como isso:

package Package_Name renames NABC_Package_Name;
package Some_Other_Package_Name renames CXYZ_Some_Other_Package_Name;
--// Repeated in this vein for an average of 10 lines or so

O que mais criativo entre nós levou a fazer foi tentar usar a verruga para criar um nome de pacote extremamente sensato (ou bobo). (Eu sei o que você está pensando, mas não foram permitidas explorações e vergonha! Isso é nojento). Por exemplo, eu estava no grupo de código C ommon e precisava criar um pacote para fazer interface com o grupo W orkstation. Após uma sessão de brainstorming com o cara da estação de trabalho, decidimos nomear nossos pacotes para que alguém que precisasse de ambos tivesse que escrever:

with CANT_Interface_Package;
with WONT_Interface_Package;

Quando comecei a trabalhar em um local e comecei a inserir meu código no controle de origem, meu chefe subitamente me procurou e me pediu para parar de cometer tanto. Ele me disse que é desencorajado fazer mais de um commit por dia para um desenvolvedor, porque isso diminui o controle da fonte. Eu simplesmente fiquei boquiaberto com ele ...

Mais tarde, entendi que o motivo pelo qual ele me procurou foi porque o servidor SVN enviava a ele (e mais 10 altos executivos) um e-mail para cada confirmação feita por alguém. E, ao desarrumar o controle de origem, imaginei que ele mentisse sua caixa de correio.

Fazendo todas as consultas ao banco de dados por meio de procedimentos armazenados no Sql Server 2000. De consultas complexas de várias tabelas a simples, como:

select id, name from people

Os argumentos a favor dos procedimentos foram:

• atuação
• Segurança
• Manutenção

Sei que o tópico do procedimento é bastante controverso, portanto, fique à vontade para marcar minha resposta negativamente;)

Deve haver 165 testes de unidade (não necessariamente automatizados) por 1000 linhas de código. Isso funciona em um teste para aproximadamente 8 linhas.

Desnecessário dizer que algumas das linhas de código são bastante longas e as funções retornam esses ponteiros para permitir o encadeamento.

Tivemos que classificar todas as funções das classes em ordem alfabética, para torná-las "mais fáceis de encontrar". Não importa que o ide tenha caído. Foram muitos cliques.

(o mesmo líder técnico criou um aplicativo para remover todos os comentários do nosso código-fonte).

Em 1987, mais ou menos, consegui um emprego em uma empresa que me contratou porque eu era uma das poucas pessoas que sabia usar o Apocalipse. O Apocalipse, se você nunca ouviu falar, foi essencialmente uma implementação baseada no PC do sistema operacional Pick - que, se você nunca ouviu falar, recebeu o nome de seu inventor, o fabuloso Dick Pick. Muito pode ser dito sobre o Pick OS, a maioria boa. Vários fornecedores supermini (Prime e MIPS, pelo menos) usaram Pick, ou suas próprias implementações personalizadas.

Esta empresa era uma loja Prime e, por seus sistemas internos, eles usavam Informações. (Não, esse era realmente o nome: era a implementação de Pick pela Prime.) Eles tinham um contrato com o estado para construir um sistema baseado em PC e haviam colocado cerca de um ano em seu projeto do Revelation antes que o cara fizesse todo o trabalho, que também era diretor do MIS, decidiu que não poderia mais fazer os dois trabalhos e me contratou.

De qualquer forma, ele estabeleceu vários padrões de codificação para o software baseado em Prime, muitos dos quais derivavam de duas condições básicas: 1) o uso de terminais burros de 80 colunas e 2) o fato de que, desde que o Prime não ' não tem um editor visual, ele próprio escreveu. Por causa da portabilidade mágica do código Pick, ele trouxe seu editor para o Revelation e construiu todo o projeto no PC usando-o.

O Apocalipse, é claro, sendo baseado em PC, tinha um editor de tela inteira perfeitamente bom e não se opôs quando você passou pela coluna 80. No entanto, nos primeiros meses em que estive lá, ele insistiu que eu usasse seu editor e seus padrões.

Portanto, o primeiro padrão era que toda linha de código tivesse que ser comentada. Cada linha. Sem exceções. A justificativa dele para isso era que, mesmo que o seu comentário dissesse exatamente o que você havia acabado de escrever no código, ter que comentar significava que você pelo menos pensou na linha duas vezes. Além disso, como ele alegremente apontou, ele adicionou um comando ao editor que formatou cada linha de código para que você pudesse colocar um comentário no final da linha.

Ai sim. Quando você comentou todas as linhas de código, foi com comentários de fim de linha . Em resumo, os primeiros 64 caracteres de cada linha eram para código, havia um ponto e vírgula e você tinha 15 caracteres para descrever o que seus 64 caracteres fizeram. Em resumo, estávamos usando uma convenção em linguagem assembly para formatar nosso código Pick / Basic. Isso levou a coisas parecidas com esta:

EVENT.LIST[DATE.INDEX][-1] = _         ;ADD THE MOST RECENT EVENT
   EVENTS[LEN(EVENTS)]                 ;TO THE END OF EVENT LIST

(Na verdade, depois de 20 anos, finalmente esqueci a sintaxe de continuação de linha do R / Basic, por isso pode ter parecido diferente. Mas você entendeu.)

Além disso, sempre que você precisava inserir comentários com várias linhas, a regra era usar uma caixa de flores:

************************************************************************
**  IN CASE YOU NEVER HEARD OF ONE, OR COULDN'T GUESS FROM ITS NAME,  **
**  THIS IS A FLOWER BOX.                                             **
************************************************************************

Sim, eram necessários os asteriscos de fechamento em cada linha. Afinal, se você usou o editor dele, era apenas um simples comando do editor para inserir uma caixa de flores.

Fazer com que ele cedesse e me deixasse usar o editor interno do Revelation foi uma batalha e tanto. A princípio, ele insistiu, simplesmente porque essas eram as regras. Quando opus que: a) eu já conhecia o editor do Revelation; b) era substancialmente mais funcional que o editor dele; c) outros desenvolvedores do Revelation teriam a mesma perspectiva; ele respondeu que, se eu não treinasse o editor dele, não poder trabalhar na base de código Prime, que, como sabíamos, não aconteceria enquanto o inferno continuasse congelado. Finalmente ele cedeu.

Mas os padrões de codificação foram os últimos a ir. Os comentários das caixas de flores em particular foram uma perda estúpida de tempo, e ele lutou contra mim com unhas e dentes, dizendo que se eu usasse o editor certo, mantê-los seria perfeitamente fácil. (A coisa toda ficou agressiva e passiva.) Finalmente, cedi silenciosamente e, a partir de então, todo o código que trouxe para as revisões de código teve seus preciosos comentários em caixas de flores.

Um dia, vários meses de trabalho, quando eu já tinha me provado mais do que competente (especialmente em comparação com o notável desfile de outros codificadores que passaram pelo escritório enquanto eu trabalhava lá), ele estava olhando por cima do meu ombro enquanto eu funcionou, e ele percebeu que eu não estava usando comentários de caixas de flores. Ah, eu disse, escrevi um formatador de código-fonte que converte meus comentários em seu estilo quando os imprimo. É mais fácil do que mantê-los no editor. Ele abriu a boca, pensou por um momento, fechou-a, foi embora e nunca mais conversamos sobre padrões de codificação. Ambos os nossos trabalhos ficaram mais fáceis depois disso.

No meu primeiro emprego, todos os programas em C, não importa quão simples ou complexos, tinham apenas quatro funções. Você tinha o principal, que chamou as outras três funções por vez. Não me lembro dos nomes deles, mas eles eram algo parecido com begin (), middle () e end (). begin () abriu arquivos e conexões com o banco de dados, end () fechou-os e middle () fez todo o resto . Escusado será dizer que middle () foi uma função muito longa.

E apenas para tornar as coisas ainda melhores, todas as variáveis ​​tinham que ser globais.

Uma das minhas mais orgulhosas lembranças desse trabalho foi fazer parte da revolta geral que levou à destruição desses padrões.

Um padrão de codificação C escrito externamente que tinha a regra 'não confie na precedência do operador, use sempre colchetes'

Justo, a intenção óbvia era proibir:

a = 3 + 6 * 2;

em favor de:

a = 3 + (6 * 2);

O fato foi que isso foi imposto por uma ferramenta que seguia as regras de sintaxe C que '=', '==', '.' e acesso à matriz são operadores. Então, codifique como:

a[i].x += b[i].y + d - 7;

teve que ser escrito como:

((a[i]).x) += (((b[i]).y + d) - 7);