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

77

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

finnw
fonte
4
Eu tenho uma pergunta semelhante (mas não exatamente o mesmo) no SO antes a propósito: stackoverflow.com/questions/218123/...
Brian R. Bondy
@ Brian, obrigado, eu tinha visto sua pergunta, mas esqueci.
finnw 8/09/10
4
O verdadeiro problema com os padrões de codificação é o tempo e o esforço desperdiçados discutindo se eles estão corretos ou não. Nada supera uma boa guerra encaracolado-chave para a criação de internecine contenda ...
MZB

Respostas:

97

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.

JohnFx
fonte
12
Acho (pelo menos agora, mais cedo na escola, que parecia estranho) que Comentar por completo é uma prática ruim
Shady M. Najib
14
Não apenas isso, mas descobri que a sobrecarga associada à criação de um novo arquivo de classe, quando você precisa colocar uma carga de clichê no topo, na verdade dissuade os desenvolvedores de criar novas classes e incentiva enormes classes de difícil controle e, portanto, um design ruim.
a gás
13
Discordo! Não adicionamos informações inúteis e redundantes de minério, mas uma explicação textual real do que a função faz (no arquivo .h) e é tão útil! É claro que estamos comprometidos em mantê-lo sincronizado com o código.
Wizard
5
@ Shady M Najib é ruim sempre ou ruim quando é permitido ficar descontrolado / sem manutenção? Geralmente, um bom código tornará seu objetivo óbvio o suficiente para evitar a necessidade de comentários - mas esse nem sempre é o caso e eu sinto que, nesses cenários, comentar é crucial. Não consigo pensar em um motivo ruim para incluir comentários XMLDoc.
Nathan Taylor
7
Um bloco explicando o que faz é bom. Um bloco simplesmente reiterando os tipos e nomes dos argumentos e o valor retornado é ruim. Quando tive que trabalhar com um padrão exigindo o último, escrevi um script emacs para gerar automaticamente a maioria dele.
precisa saber é o seguinte
130

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.

Fishtoaster
fonte
10
Não é apenas assim que o professor sabe que você sabe exatamente o que está acontecendo?
John MacIntyre
80
Eu acho que está claro o que está acontecendo, e não é educação.
Dan Ray
18
O exemplo que você tem acima é claro, mas e se um aluno copiar alguma chamada de função de outro aplicativo ou livro ou qualquer outra coisa e realmente não a entender? Como o professor saberá? Essa regra estúpida não permite nenhuma área cinzenta (que em sua defesa, provavelmente já foi abusada antes). É assim que eu interpreto isso. ... lembre-se, se eu vi isso em um ambiente não acadêmico, isso pode me assustar um pouco. ;-)
John MacIntyre
4
Sim, exceto que você sempre pode escrever comentários que apenas repetem o código e não mostram nenhum entendimento. Ele faz você acertar "// Ending Brace" antes do final?
alternativa
6
E se você receber um comentário útil acidentalmente no seu código? Você precisa colocar // commenta linha antes disso?
configurator
103

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.

Cumbayah
fonte
11
Eu tentei votar isso uma dúzia de vezes ...
TGnat 9/09/10
22
Se você acha que precisa do #REGION, acho que precisa refatorar.
Jay Bazuzi 9/09/10
23
Geralmente organizo o código por regiões em construtores, propriedades, eventos, métodos e membros. Isso torna muito fácil gerenciar e navegar na fonte (especialmente em algumas classes de utilitários estáticos que podem crescer bastante). Eu não os usaria mais do que isso.
Evan Plaice
26
Temos um padrão de codificação simples: nunca aninhe regiões. Apenas usá-los para métodos de grupo relacionadas (inicialização, serialização, propriedades, etc)
Jason Williams
6
O único bom objetivo de #regions é ocultar o código que não precisa ser editado . Isso pode ser um código gerado, ou código com um algoritmo difícil de acertar, no qual você prefere que as pessoas não toquem, ou talvez blocos feios de código de depuração. Mas não o código no qual as pessoas estarão trabalhando. Para aqueles presos em uma loja de # região, tenho uma macro que recolhe as definições, mas expande as regiões. Veja aqui: stackoverflow.com/questions/523220/awesome-visual-studio-macros/…
Kyralessa
80

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)

Damovisa
fonte
14
Desculpe, mas o que acontece quando você refatorar o banco de dados ou quando você decide que o comprimento do VARCHAR precisa ser diferente. De repente, você precisa passar por todo o seu código e mudar ... oh, Deus. Isso parece horrível.
Tom Morris
71
Sem vogais ?! Você está brincando certo?
Daniel Cassidy
39
As pessoas que aplicaram esse padrão tinham arestas na testa e frequentemente discutiam honra e batalha?
Ryan Roberts
10
Haha, bem, eles foram DBAs, por isso ...;)
Damovisa
14
Você deveria ter enviado os nomes das colunas através de um URL mais curto. PersonFirstNameVarchar30NotNull = bit.ly/cULlQc
Billy Coover
48

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
Kris Erickson
fonte
21
Mais vulnerável: se você precisar de um comentário para dizer qual foi o início do bloco, o bloco será muito longo ou seu conteúdo será muito complexo => refatorar.
Richard
5
Eu quero votar, porque os blocos longos e profundamente aninhados podem ser difíceis de resolver, e esses comentários podem ajudar. Quero votar, porque esses comentários ficarão errados (e muito confusos) em breve e porque blocos longos e profundamente aninhados são um sinal de que você precisa refatorar, não adicionar mais comentários.
Jay Bazuzi 9/09/10
7
essa foi uma ótima idéia para um mundo sem um IDE poderoso.
IAdapter
9
@ Jay, em qualquer IDE decente, você pode destacar uma chave e ela destacará a outra chave correspondente. Eu pessoalmente detesto quando as pessoas fazem isso.
Evan Plaice
3
Embora o seu exemplo seja um pouco louco (como eles não são longos o suficiente para importá-lo e atrasá-lo ao alterar a lógica), isso nem sempre é uma coisa ruim. Comentários como esse são realmente úteis para fechar espaços para nome / declarações endif que abrangem um arquivo inteiro.
Jsternberg #
38
#define AND  &&
#define OR   ||
#define EQ   ==

disse nuff.

Niall C.
fonte
9
#Include <iso646.h> não seria uma escolha muito melhor?
AndrejaKo
3
@AndrejaKo: anterior a <iso646.h>; essa foi uma tentativa de fazer C parecer FORTRAN.
Niall C.
2
Isso realmente era um padrão de codificação? ou seja, havia uma política da empresa contra escrever diretamente os operadores?
finnw
21
Também tinha #define BEGIN {e #DEFINE END }?
precisa saber é o seguinte
3
Isso me lembra um artigo do Daily WTF que vi que alguns programadores de C ++ tinham uma tonelada de definições para parecer Visual Basic (ou talvez apenas Basic, algum dialeto). #define void Sub, #define} End, coisas assim.
Wayne Molina
37
  • 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' ”.
John Siracusa
fonte
3
+1. Os pequenos aborrecimentos se somam. Eles também são difíceis de argumentar, porque o editor de padrões de codificação ou o gerente de projetos pode dizer "Não é um grande fardo, então não vale a pena mudar isso".
finnw
1
Exatamente. (Embora, neste caso, lendo muitos variablenameslike thiscanreally adduptoquitea greatburden.)
John Siracusa
57
Divirta-se inventando nomes do que ser analisado de duas maneiras. pageshits, penisup, etc.
Jay Bazuzi
4
@Jay * sexchange
configurator
2
@ configurador: quando a equipe do depurador do Visual Studio estava trabalhando em um recurso para permitir que você visse a exceção em andamento na janela de inspeção, eles adicionavam uma pseudo-variável chamada "$ ex". Nós não percebemos por um longo tempo. Em seguida, renomeamos para "$ exception", mas continuo lendo como tendo um 's'.
Jay Bazuzi
36

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

Lorenzo
fonte
ele pode nunca ter ouvido a palavra 'refatoração'
nanda
3
Ele nunca ouviu também um monte de outras palavras ...
Wizard79
Bem, você não precisa de teste formal porque você nunca mudou métodos ...
configurador
36

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.
Jaco Pretorius
fonte
2
Temos algumas pessoas neste campo no meu local de trabalho. É engraçado quando eles tentam jogar a carta desempenho e demonstrar o quão desatualizado seu conhecimento é
Reintegrar Monica
3
espere .. com toda a seriedade, pensei que o SP era melhor, em termos de desempenho, do que chamadas SQL diretas de, digamos, C #?
Sk93
3
Parece que você sabe exatamente por que eles foram incluídos. : P
Mason Wheeler
4
Quando cresci, finalmente entendi por que tudo deveria passar pelo DB :) Com toda a seriedade, isso simplifica muitas coisas, não tente reinventar a roda.
Jé Queue
3
Ouvi o adorável raciocínio "Não podemos usar um OR / M porque toda interação deve usar SPs". Um desperdício de mão-de-obra.
configurator
33

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.

David B
fonte
5
A única vez que ouvi alguém não usar o STL porque não era rápido o suficiente e estava certo foi para jogos. A EA fez sua própria implementação do STL para seus jogos. Duvido muito que isso importe mais (os jogos modernos são limitados por GPU) e duvido que eles o usem. Mas mesmo assim, foi uma implementação do STL, não uma biblioteca totalmente nova. Você ainda estava usando o STL ao usar o EASTL.
Matt Olenik 13/09/10
1
@ Matt: para adicionar a isso, a reclamação da EA estava centrada no uso e inicialização de memória. Sua própria implementação consumiu menos memória, liberou-a mais cedo e evitou inicializar objetos que seriam inicializados posteriormente.
Matthieu M.
Eu diria a ele para codificar ele mesmo.
rightfold 12/08
31

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}
J8D
fonte
5
Ow ow ow ow ow ow!
Restabeleça Monica
22
O maior problema com esta amostra são os nomes de variáveis ​​sem sentido. Retire os prefixos húngaros e alguns deles têm 1 ou até 0 caracteres.
finnw
8
Este é o sistema húngaro, que é útil em idiomas de tipo fraco (como codifica as informações de tipo que são críticas para trabalhar nesses idiomas nos nomes) - é inútil em idiomas de tipo forte. A melhor alternativa para idiomas fortemente tipados é o Apps Hungarian, que codifica informações importantes sobre o uso de uma variável (membro, ponteiro, volátil, indexador) - algo que o próprio idioma não oferece suporte.
Jason Williams
5
Oh, por favor. Eu nunca jamais confundiu um local com um membro, e eu não uso essa bobagem Húngaro para membros / habitantes / campos / whatever. Eu acho que eles podem ser úteis para diferenciar tipos diferentes de strings, como 'safe' e 'inseguros', como o exemplo de Joel em Making Wrong Code Wrong
configurator
3
@ configurador: o exemplo de Joel é horrível, seria melhor ter tipos diferentes, então o compilador aplicaria o uso.
Matthieu M.
28

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.

Christopher Hawkins
fonte
93
Certa vez, trabalhei em uma linguagem que exigia que todas as variáveis ​​- TODAS as variáveis ​​- fossem prefixadas com "$".
nohat 10/09/10
6
@nohat: E você percebeu que era incrível, não é?
Josh K
Certa vez, trabalhei em um idioma em que todas as minhas variáveis ​​começavam com pontuação como '$' ou '%' ou '@'. Eu ainda faço, de vez em quando.
David Thornley
3
Isso só se torna realmente um problema quando você precisa colocar ffunções antes, então seu código é realmente fUcked (vUp).
Joe D
1
Soa como várias versões do Perl ...
26

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.

David B
fonte
2
Esta é uma política horrível. Espero que este gerente tenha sido enlatado.
Bernard
@ Bernard-Na maioria das organizações, a criação de um fluxo de receita a longo prazo é motivo para promoção rápida. Felizmente, alguém viu a loucura nisso e acidentalmente a atropelou no estacionamento.
217 Jim Jim
24

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.

Anna Lear
fonte
13
' Validations the handler' - uh-oh
Eric
8
+1 Ugh, eu odeio isso. Eu acho que se você está usando um software para gerar comentários, então você não precisa deles.
bleevo 8/09/10
9
Eu não acho que isso seja uma regra ruim. Ao ler um método que tenho que manter pela primeira vez, ajuda muito se tiver especificações para todos os argumentos. Geralmente existem sutilezas (por exemplo, o que acontece se o argumento for nulo, e se for uma coleção vazia, o nome de um arquivo inexistente etc.) Outra regra boa (IMHO) é que os nomes dos métodos devem ser verbos, mas no seu exemplo é um substantivo.
finnw
3
@finnw Eu acho que é uma boa prática, mas um padrão ruim. Se os desenvolvedores estão a bordo e escrevem comentários significativos sobre métodos quando são garantidos (detalhes de exceção, etc.), isso é ótimo. Caso contrário, você acaba com uma grande bagunça. E no primeiro caso, você não precisa da imposição no nível da compilação.
Adam Lear
7
Caso clássico de falta de documentação. Comentários que não diferem do óbvio devem ser eliminados à vista.
Cumbayah 9/09/10
23

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.

Jim A
fonte
6
E ninguém estava ciente svn log?
Htbaa
1
Os que iniciaram a política já se foram há muito e os que a seguiram continuaram. Comecei na mesma semana que o novo CTO (amigo meu) e nós dois olhamos para isso e dissemos WTF?
Jim A
20

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?

Jeremy Wiebe
fonte
3
Eu tenho excluído muitos códigos antigos comentados recentemente.
precisa saber é o seguinte
2
Normalmente, excluo o código comentado, a menos que seja acompanhado por uma boa explicação do motivo pelo qual ele foi comentado e por que ele deve ser mantido no lugar.
Jeremy Wiebe
Eu concordo totalmente. Comentar o código desde que você trabalhe com ele é bom, mas tudo o que entra em uma versão de lançamento / ramificação principal deve ser nulo do código comentado. Alguém me disse que "gostava de saber como isso poderia ser feito de maneira diferente". Só acho isso irritante pelas razões mencionadas: isso é obsoleto, uma solução alternativa, outra maneira de fazer isso? WTF
Anne Schuessler
Com o VS2013 "Peeks", tudo fica fora da janela. Mas colocamos um comentário que diz "Equação alterada - iniciais" ou algo assim, para que alguém se perguntasse qual seria o código antigo, seria exibido no TFS / VCS, se necessário. Portanto, é uma linha em vez de 10 linhas comentadas. Mas o VS2013 é incrível, mostra o histórico do TFS exatamente para você.
Suamere 16/09/13
17

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.

JaredPar
fonte
16

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.

Ryan Roberts
fonte
Isso é hediondo #
Evan Plaice
5
Mmm. Dim Sum ...
configurador
Eu fiz isso, antes de termos o controle da fonte, é claro. Uma vez que tínhamos controle de origem, era um hábito, praticamente precisávamos de uma intervenção para a equipe parar de fazê-lo. Eventualmente, paramos e excluímos todos os existentes quando os encontramos.
Scott Whitlock
Nosso desenvolvedor sênior ainda tenta nos forçar a fazer isso. Eu ignoro a política sempre que penso que posso me safar dela (e às vezes quando sei que não posso).
Joshua Smith
Temos um cara em nossa equipe que ainda faz isso em todos os lugares (ele também inclui coisas importantes sobre o "Log de alterações" em nossos scripts SQL, que também estão sob controle de versão). O argumento, como me foi explicado, é que, após algumas alterações / confirmações, você não se lembra da data em que algo foi alterado; portanto, o log de alterações é bom para perceber imediatamente quem mudou o quê e por que quando você abre um arquivo.
Wayne Molina
14

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);
}
user1006
fonte
1
Você perguntou por que ? Eu só gostaria de saber a sua motivação ..
JBRWilkinson
1
Uau, por que esse cara está usando aulas ?
Mateen Ulhaq
9

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

RedFilter
fonte
2
Como isso foi ruim?
Jay Bazuzi 9/09/10
1
Porque então toda linha tem 4 espaços desnecessários no começo?
nohat 10/09/10
Oh, entendi agora.
alternativa
21
Sim, o StackOverflow tem um padrão de codificação muito ruim. :-)
P Enviado
Grandes recuos forçam você a manter o nível de aninhamento de código baixo. Vi recuos de 8 e funcionou bem.
Toon Krijthe
9

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.

Jeremy
fonte
Esse é um padrão de codificação horrível e horrível a ser seguido. E uma razão estúpida para isso também!
gablin 23/09/10
4
Se você precisar rolar horizontalmente (por exemplo, mais de meia página), provavelmente também há algo errado. Nenhum recuo também não é bom, pois torna o código completamente ilegível. Eu tento manter um limite de 78 col, mas se for necessário exceder esse valor, não me importo, mas tento evitá-lo.
Htbaa 16/03/11
8

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

Tim Murphy
fonte
7
Não zombe de dinossauros mais velhos, por favor. Eles nos tornaram possíveis.
usar o seguinte comando
4
Parece segurança no emprego.
MIA
7
Ter um marcador de áudio para saber quando cada arquivo está sendo impresso é engenhoso. Vou adicionar \07ao início de cada arquivo agora.
configurator
2
Usar um esquema de nomenclatura como este (não em maiúsculas) fazia algum sentido, pois as regras de "escopo" variáveis ​​do dBase eram inexistentes. Tudo foi efetivamente global. Um iusado para indexar uma matriz em um procedimento pode interferir com um iprocedimento de chamada. Você precisa usar PRIVATE ALL LIKE m*e PRIVATE ievitar essa "sombra"
Gerry
8

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.

David B
fonte
A empresa ainda está funcionando hoje?
finnw
O que "moveu" o Java é o outro, já faz muito tempo. Eles nunca sobreviveram à mudança do TRS-80 para um PC.
David B
6

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!

Adam Harte
fonte
Bem, como "Will" diz, "eu prefixo com o sublinhado para que minhas variáveis ​​privadas sejam agrupadas no meu intellisense. No entanto, só faço isso para variáveis ​​com escopo definido para um tipo. Variáveis ​​declaradas em um método ou escopo mais restrito deixo o sublinhado Torna mais fácil mantê-los separados e manter as variáveis ​​menos usadas juntas ". e eu tenho que concordar com ele.
7wp 9/09/10
1
Não acho que agrupar suas variáveis ​​em seu IDE proprietário favorito seja um motivo suficientemente bom para desfigurar todo o seu código.
Adam Harte
Se for o seu código, torná-lo utilizável no seu IDE parece completamente razoável. Além disso, colocar sublinhados é comum em muitos idiomas; portanto, sempre que as pessoas veem, elas sabem o que isso significa.
rjmunro 9/09/10
1
+1 Usar um bom IDE (aquele que pode usar a pesquisa regex ) faz mais sentido para mim. Scratch IDE, aprenda a usar um editor de texto e um terminal e você será um programador muito melhor. Como uma observação lateral, não gosto particularmente dos sigilos perl, mas pelo menos eles têm um uso, diferentemente dos PHP.
alternativa
6
Suspiro ... outro daqueles "IDE's é para bichanos".
quer
6

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.

CB Du Rietz
fonte
6

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.

Mark Lutton
fonte
6

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!

Jax
fonte
9
Você teria dificuldade em retornar algo de uma função declarada como nula.
Mircea Chirea 09/09/10
7
@MAttB Considere em que condições o elseramo final ( ) seria usado.
Richard
6
else {return string.Empty; } será executado quando as duas linhas acima tiverem sido editadas por um desenvolvedor de manutenção daqui a cinco anos. No entanto, retornar string.Empty ocultará o fato de que ela é uma condição impossível . Em vez disso, ele deve lançar InvalidOperationException ("Este código não foi projetado para suportar lógica de três valores");
MatthewMartin
1
Isso é horrível. O que há de errado return verbose ? someString : someOtherString;?
precisa saber é o seguinte
1
@callum O operador ternário pode ser banido :) esteve lá antes ...
hplbsh
6

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.

Ben Doom
fonte
"Não use nomes confusos" parece justo o suficiente para mim ...
8128
1
É absolutamente uma orientação justa. Meu argumento era que ele não seguiu nada. Eu acho que a ideia dele de "não confundir" e a minha eram diferentes.
Ben Doom
4

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

fonte
6
O que havia de errado com o HeapSort do líder do projeto?
7wp 9/09/10
4
Na verdade, se o código de entrada do usuário externo aceito pelo QuickSort pode estar errado, pois é aberto aos O(n^2)ataques do DOS (alimentando a entrada do pior caso). Também por que não foi possível mudar - ele próprio era uma desculpa válida para não usar o STL.
Maciej Piechotka
4

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;
}
Carl Bergquist
fonte
Muito semelhante a esta resposta anterior .
finnw
Sim. Tudo o que sou obrigado a comentar também os membros privados. O que faz ainda menos sentido.
Carl Bergquist
Incentivado a usar o ghostdoc ?! Gah
configurator