A formatação inconsistente é um sinal de um programador desleixado?

Você tem razão em apontar que os usuários são a coisa mais importante, no final. Mas aqui está o ponto que acho que você perdeu: outros desenvolvedores são usuários do seu código. É tão importante o que eles veem quanto os usuários do aplicativo veem.

Agora, se foi uma troca - se melhorar o código tornou a experiência do usuário pior -, então, devo dizer que preste atenção ao grupo maior (espero que seus usuários).

Mas não é uma troca. Você pode alcançar os dois objetivos simultaneamente. Então faça isso.

Como uma nota secundária, se você for o único desenvolvedor que trabalhará neste projeto (aplicativos descartáveis), não terá um problema imediato. Mas não seria melhor adotar o hábito de ser consistente agora do que quando você trabalha em equipe?

Há momentos em que uma equipe pode tomar a decisão de permitir que o código seja escrito 2 (ou até mais) maneiras diferentes, mas isso geralmente é feito com base em "vamos alterar nossa abordagem para todo o novo código, alterar código quando estamos nessa área, mas não alteramos o código que nunca é tocado até que sobra tão pouco que vale a pena fazer um projeto dele. " Esses casos precisam ser gerenciados com muito cuidado.

EDITAR : Para responder às suas edições: isso só torna isso pior, na minha opinião. Não é um caso de escrita desajeitada porque o IDE teria corrigido isso. Parece que havia outro bloco de código dentro do inner-if, que foi excluído junto com o outer-brace. Isso é tão fácil de corrigir que não há desculpa para não fazê-lo.

Depois que o recuo fica fora de controle, o código fica muito difícil de ler e ainda mais difícil de depurar. Eu não acho que você seja tão exigente.

Se houver alguma consistência, tento ignorar e seguir em frente. Não há necessidade de ser um perfeccionista. Mas se o desenvolvedor que escreveu o código foi descuidado, então ele ou ela pode não entender que outros desenvolvedores precisarão ler seu código, e se o desenvolvedor não entender os conceitos de legibilidade, isso me diz algo sobre esse desenvolvedor que fala volumes:

Esta pessoa não sabe ler o código em si!

Em muitas de nossas carreiras, não necessariamente escrevemos código do zero. Em vez de repetição, reutilizamos blocos de código ou consumimos APIs gravadas por outros desenvolvedores, e eles formam os blocos de construção de nossos aplicativos. Muitas vezes, aprender a usar essas ferramentas envolve ler a documentação da API e ler exemplos de código. Além disso, entender os módulos em um projeto desenvolvido internamente, onde pode não haver exemplos de código ou API, envolve a capacidade de ler minuciosamente e entender blocos desconhecidos de código legado, a maioria dos quais provavelmente contém problemas de formatação e estilo em si.

Ao testemunhar um novo desenvolvedor escrevendo seu próprio serializador JSON e perguntando por que ele não está usando Jackson ou GSON, ele diz "Ele gera erros e não funciona. Não faz sentido!"

Por que ele estava fazendo isso?

Como um desenvolvedor escreve seu código, ele nos diz muito sobre suas habilidades. Considerando que na maioria dos campos, um profissional recém-cunhado aprende a trabalhar junto com outros profissionais mais experientes, ver código malfeio indicaria para mim que a pessoa que o escreveu não teve a oportunidade de aprender com os outros, principalmente porque ele ou ela não tentei.

Quando orientamos novos desenvolvedores, trabalhamos nesses pontos. O desenvolvedor escrevendo seu próprio substituto de Jackson ganhou um novo respeito pela legibilidade do código quando passamos por alguns exemplos bem escritos disso em ação.

Uma vez que um desenvolvedor experimente isso em primeira mão e entenda que o trabalho envolve não apenas escrever código, mas também lê-lo, sua abordagem muda.

Joel Spolsky tem algumas dicas de Seth Gordon sobre como se pode abordar o código de leitura. .

Por fim, se os desenvolvedores com os quais você está trabalhando não são novos e, na verdade, são chamados de engenheiros seniores, é recomendável considerar a possibilidade de encontrar trabalho em outro lugar. Esses engenheiros não respeitam você, seu tempo ou a organização em que trabalham, e eles não se importam se você ou qualquer outra pessoa precisa limpar sua bagunça. Código mal formatado, e não quero dizer apenas alguns sublinhados ausentes, é um sinal de patologia na organização. Ou diz que eles são inexperientes, ou simplesmente não se importam.

Sim.

Utilizando um conjunto de exemplo de mais de 50 desenvolvedores com os quais já trabalhei, ainda não encontrei um desenvolvedor que seja consistentemente desleixado em sua formatação e tenha uma saída excelente em termos de correção de código e atenda a todos os requisitos funcionais e não funcionais requisitos de forma consistente e eficaz.

A formatação descuidada é um sinal de falta de atenção aos detalhes. Essa falta consistente de detalhes, em todos os casos em minha experiência pessoal, invariavelmente se traduziu na mesma falta de detalhes na correção do código também.

Em outras palavras, eu nunca encontrei um grande desenvolvedor (alta correção e capacidade de manutenção) que é constantemente desleixado na formatação.

Com base nessa experiência, uso a negligência de formatação consistente, sistêmica e repetitiva como um indicador negativo do calibre do desenvolvedor.

Eu acho que, de certa forma, você está parcialmente se fazendo a pergunta errada. O código é legível? Você consegue entender o que é suposto fazer de relance?

A formatação de código é algo que permite que as pessoas que não estão familiarizadas com o seu código se sintam à vontade. De certa forma isso é uma coisa boa, que você pode olhar para o código de outra pessoa e sentir-se semelhante ... confortável. Algumas linguagens (Python, por exemplo) exigem um certo grau de formatação para funcionar corretamente. De outras formas, a formatação de código é uma distração em que a própria linguagem não é verdadeiramente dependente dela. Você realmente se importa se seus métodos são apropriadamente camel-cased, ou se suas variáveis privadas começam com um sublinhado, ou mesmo se seus métodos públicos e privados estão em algum tipo de ordem específica?

Isso me traz de volta à questão da legibilidade. Sua tarefa é codificar requisitos e comunicar o que você fez ao próximo desenvolvedor que modificará o código depois de você. Manter o código com uma aparência elegante, com um belo revestimento de camelo e uma nomenclatura consistente pode ajudar até certo ponto, mas eu diria que a atenção está nos detalhes do que você faz no próprio código. Manter seus métodos curtos, nomeando todos os seus elementos de código de forma descritiva, e removendo a duplicação pode fazer uma diferença maior do que se você está preocupado em colocar ou não a chave na próxima linha, ou se você tem recuado consistentemente. Esses problemas de formatação se tornam mais importantes quando o código é longo e difícil para o leitor analisar rapidamente.

Meu ponto é que seu código provavelmente já está em apuros se você está no estágio de se preocupar com o quão cuidadosamente formatado ele é. Com isso dito, se a formatação incomodar você, custa muito pouco arrumar as coisas conforme você trabalha, desde que esteja dentro do escopo do trabalho que você deveria estar fazendo no momento.

Então, é tudo isso nit picking ou um sinal de um codificador desleixado? Isso depende muito do seu ponto de vista. Pessoalmente não penso assim. Talvez possa ser visto como um sinal de preguiça ou pouca atenção aos detalhes, mas se o código funcionar e passar em todos os testes, você pode se perguntar como a codificação é realmente "desleixada". Por outro lado, se alguém achar difícil ler seu código, isso pode ser um sinal de que seu código pode ser difícil de manter, e isso por si só seria motivo de preocupação.

Se você estiver trabalhando em uma equipe ou se estiver disposto a deixar seu código para ser mantido por outra pessoa, acredito que seja melhor manter seu código limpo, organizado, legível e fácil de entender. Regras e estilo de formatação podem precisar ser discutidos como um grupo e algumas diretrizes definidas ou codificadas em uma ferramenta de verificação de código (como StyleCop for C #, por exemplo). Se for seu próprio projeto pessoal e nunca será tratado por outros, então o ponto é discutível, embora eu argumente que é melhor praticar boas técnicas de codificação limpas como um hábito, em vez de algo que você faz ocasionalmente.

Não consigo deixar de pensar que codificar é tudo sobre detalhes. Cada detalhe do nosso código é importante - para correção, legibilidade, extensibilidade, manutenção.

Embora os exemplos dados não sejam desastrosos em si mesmos, para mim eles falam de uma falta de atenção aos detalhes que eu consideraria preocupante - particularmente em uma ferramenta como o Visual Studio que oferece tanta ajuda - eu uso Ctrl + K , Ctrl + D quase tão habitualmente quanto Ctrl + S

Eu trabalho com um programador que é similarmente desleixado (e também descaradamente ignora nossos padrões de codificação com coisas como nenhum espaço em branco entre métodos e nomes de métodos privados em minúsculas) e com o passar do tempo percebemos que temos que manter um Olho de perto em seu trabalho como este desleixo se estende ao seu design e testes, e nós tivemos que gastar um esforço considerável "arrumar" atrás dele.

Eu acho que é um sinal de que o desenvolvedor não estava usando as ferramentas disponíveis para eles. Se você estiver usando uma ferramenta como o IntelliJ Idea for Java ou qualquer outro IDE com todos os recursos disponíveis no momento, eles tornam tão fácil escrever código puro que é tão fácil ou mais fácil de fazer isso.

O problema em ser negligente em sua formatação é como foi comentado, na postagem original, outras pessoas que lêem seu código provavelmente não acreditam na qualidade do resto do código. Mais importante, torna o código mais difícil de manter quando se torna código herdado.

Se eu estivesse fazendo uma revisão de código, eu seria capaz de conviver com o espaçamento inconsistente entre os operadores, mas provavelmente falharia na revisão por causa do recuo inconsistente e da nomeação de variáveis. Especialmente quando um atalho de teclado irá formatá-lo para o seu, se você estiver usando um IDE. Eu acho que quando se trabalha como parte de uma equipe É importante que todos usem as mesmas ferramentas e convenções para evitar o mapeamento mental tanto quanto possível.

Sugiro que, como teste, coloque um pouco desse código como parte de uma pergunta sobre o estouro de pilha ou como uma revisão da versão beta do Code Review e veja quais outros comentários você recebe.

Algumas consistências são mais importantes que outras.

As inconsistências de recuo podem ser o resultado do uso de diferentes ferramentas / plataformas. Você está recuando com espaços ou guias. Quantos espaços? Onde estão as paradas de tabulação.

No início dos anos 90, as pessoas usavam guias para substituir 8 espaços e recuavam 2 ou 4 espaços. (Na verdade, eu preferia 3). Assim, algumas equipes concordaram em usar apenas guias e, em seguida, definiram suas paradas de tabulação onde quisessem. Claro, isso mais tarde causou problemas, pois outras ferramentas substituíram automaticamente as guias por espaços ou vice-versa. Agora, praticamente todo mundo usa espaços para que, pelo menos, todos sempre vejam a mesma coisa.

Se você quiser ficar rígido com a formatação, você pode usar Checkstyle para impor as regras que quiser.

Pessoalmente, sou consistente com algumas coisas em Java, como se todos os nomes de pacotes fossem minúsculos, os nomes de classes começassem com letras maiúsculas (e nada mais existisse) e outras práticas comuns de estilo Java. Por outro lado, não sou tão consistente quanto a usar ou não chaves em uma instrução if quando não preciso. Eu geralmente coloco espaço em torno de operadores aritméticos, mas não irei em alguns casos, particularmente se for a diferença entre tornar a linha muito longa ou não.

As diferenças que vejo:

• As inconsistências tornam o código mais difícil de ler.
• As inconsistências tornam mais difícil lembrar ou entender os pontos importantes.
• A construção leva a erros mais facilmente negligenciados.

Ser consistente com a capitalização torna muito fácil perceber rapidamente a diferença entre um nome de classe e uma variável. Ser inconsistente quebra isso sem uma boa razão, e por isso é muito ruim.

Ser inconsistente sobre o espaçamento em torno de operadores aritméticos provavelmente não é um problema.

Não usar chaves com uma instrução if pode ser perigoso, como se você incluísse uma segunda instrução na cláusula then sem adicionar chaves, então a segunda instrução pode parecer parte da cláusula then, mas na verdade não é. Eu não usando chaves pode, de fato, ser considerado desleixado. Eu não tenho uma defesa a não ser salvar uma linha, tornando o código mais compacto, o que é fraco, especialmente porque eu sempre coloco else em uma nova linha em vez de colocá-la na mesma linha que a chave de fechamento da cláusula "then".

Os programadores variam em seus estilos. Alguns dos programadores mais engenhosos e criativos usam uma rígida rigidez de estilo como forma de liberar recursos mentais. (Uma vez eu derrotei um grande mestre no xadrez em uma exposição de 60 pessoas fazendo com que ele renunciasse simplesmente orientando meus cavaleiros para que eles estivessem de frente para ele. Ele queria vê-los de perfil.) Outros, como eu, sentem que a rigidez inibe qualquer nível criatividade e atrito e regras que não são comprovadamente importantes.

Como é frequentemente o caso, geralmente é melhor encontrar algum tipo de mídia feliz.

Meu sentimento é que a maioria das pessoas é bastante consistente no uso de espaços em branco, sublinhados, etc. pela mesma razão que soletram palavras corretamente, usam pontuação de forma consistente, usam cinto de segurança, escovam os dentes sempre começando do mesmo lado , e assim por diante. Quando você faz algo regularmente, você se acostuma a fazer isso de uma certa maneira e faz isso sem pensar muito.

Neste momento, sem olhar para o código que escrevi recentemente, não posso dizer se geralmente escrevo foo = bar; ou foo=bar; , mas tenho certeza de que escrevo da mesma maneira todas as vezes . (Na verdade, posso dizer agora que faço o primeiro: digitar o primeiro exemplo foi rápido, mas tive que pensar em evitar digitar espaços em torno do = no segundo exemplo).

Se eu vi alguém escrevendo um código que era muito inconsistente na forma como foi formatado, eu não necessariamente assumi que eles eram tão desleixados quanto um dos seguintes:

• eles eram inexperientes e ainda não haviam desenvolvido um estilo automático;

• eles não escreveram muito código recentemente

• eles estavam tendo problemas com algum outro aspecto do código que levou a muitas edições de tentativa e erro

• o código em questão foi escrito há algum tempo e foi editado por várias pessoas durante sua vida útil

Não está claro se você está falando sobre seu próprio código ou sobre o de outra pessoa. Se é seu e você está preocupado sobre como isso reflete em você, então é algo para trabalhar nas próximas semanas. Gaste um pouco de tempo para descobrir como você deseja que seu código seja exibido (de acordo com os padrões de codificação da empresa) e, em seguida, preste mais atenção ao escrever o código nas próximas semanas. Se você está realmente reclamando de um dos seus colegas de trabalho, então é melhor não deixar que isso o incomode e deixar que seu gerente o resolva se for um problema para a equipe. Se você for amigável com a pessoa em questão, sugira gentilmente usar uma ferramenta para formatação de código. Muitos IDE fornecem ajuda de formatação e há muitas impressoras e formatadores de código (por exemplo, Uncrustify) que podem ajudar.

Você definitivamente deveria falar com ele sobre isso.

Para mim, o código formatado corretamente é muito importante. Isso me permite ver rapidamente a estrutura de um programa, encontrar possíveis falhas, qualquer que seja. Quando há código que é apenas uma tela cheia de texto com muito pouco espaçamento, é muito mais difícil de ler do que quando é dividido em blocos lógicos e alguns espaços entre os operadores, etc.

Sublinhados em variáveis privadas são um pouco importantes: é bom ter uma maneira de identificar rapidamente uma variável global; portanto, ao procurar um problema, você sabe imediatamente que ele provavelmente não está contido nesse método específico.

Como outros já disseram, se um desenvolvedor não está preocupado com a legibilidade do código, há um problema. Ele provavelmente terá que ler mais tarde, e há uma boa chance de que ele não se lembre do que esse código faz de cor. Talvez ele não tenha trabalhado em um grande projeto ainda, onde este é um problema maior do que em pequenos projetos.

Eu lembro de pessoas em aulas de programação me pedindo ajuda, e de vez em quando eu tinha que dizer a elas para formatar o código antes que eu pudesse começar a ver o que está errado. É incrível ver quantas pessoas pensam que a indentação e a nomeação correta de variáveis não são importantes.

Imagine um carpinteiro construindo uma grande peça de madeira, deixando todas as ferramentas espalhadas por toda a bancada, de uma maneira bagunçada, enquanto constrói esta grande obra de arte em madeira. Agora imagine que o carpinteiro adoece e outro carpinteiro vem para terminar a peça de madeira. Quando ele vê toda a bagunça em torno dele, ele perde tempo e paciência para organizar tudo ao seu redor para que ele possa começar a terminar a peça da maneira que ele melhor conhece. No final, a peça de madeira é ótima, bonita, brilhante e o cliente a compra.

Agora, troque o carpinteiro por um desenvolvedor de software.

Acredito que a lição importante aqui é a satisfação do cliente com o produto de software, mas também é importante, é como os desenvolvedores trabalham juntos e usam corretamente as ferramentas disponíveis e organizam para que todos possam trabalhar rápido e produtivo com uns aos outros trabalham.

Acho que todo desenvolvedor deve ser perfeccionista, amar o que ele / ela está fazendo para que ele / ela possa se divertir resolvendo os problemas dos clientes e deixar um ambiente de trabalho limpo (recuo adequado, uso correto de nomes de variáveis, excelente documentação etc. .) para outros usarem e melhorarem o seu trabalho.

Eu não acho que a consistência seja realmente a questão: é se o código lido por outro programador transmite com precisão a função do código. Isso depende do contexto.

A idéia de que as chaves correspondentes devem se alinhar, ou que o nome de uma variável deve ser indicativa de sua finalidade, é bastante universal. Então alguém que digita chaves que não se alinham ou que dão nomes de variáveis que são contrários ao seu propósito está transmitindo informações falsas. Isso é ruim: mesmo que o código funcione, pode ser o resultado de erros balanceados. É frágil e instável.

Por outro lado, como as variáveis são capitalizadas e o que isso significa é muito mais variado. Depende das convenções da linguagem, da plataforma, do ambiente de desenvolvimento e, acima de tudo, das convenções da equipe de programação. Se não houver convenções consistentes, se nada foi escrito para dizer "é assim que deve ser feito", não há razão para esperar um código consistente. Em outras palavras, se uma determinada prática estilística não tem significado em um determinado contexto, a inconsistência também não tem significado.

Dos quatro exemplos originais, eu diria que as variações em 1, 2 e 4 só são significativas se esses elementos tiverem significados bem estabelecidos em primeiro lugar. Apenas o # 3 tem um significado bastante universal e, mesmo assim, eu só seria crítico se o alinhamento estivesse longe o suficiente para ser verdadeiramente enganador.

Estou atrasado para a questão, mas merece isso: o código de computador é a expressão da intenção do desenvolvedor. Se o desenvolvedor não está expressando ou não pode expressar sua intenção tanto ao compilador quanto ao próximo humano para manter seu código, então ele não está fazendo o seu trabalho.

Se o código 'desleixo' torna a intenção do desenvolvedor menos clara ou até mesmo dá a impressão de intenção diferente, então é um problema. Em alguns casos, será um problema para o compilador, em outros casos, será um problema para o mantenedor. Mas ainda é um problema, já que não precisamos que o mantenedor "conserte" a intenção e, em seguida, introduza bugs porque a "correção" estava errada.

Nas palavras do leigo:

Software realmente excelente só pode ser construído em bases sólidas. Código limpo e consistente é uma dessas fundações.

A abstração contínua da complexidade é o que permite aos programadores fazer coisas ainda maiores.

Como você pode fazer coisas ainda maiores se tiver que lidar o tempo todo para codificar inconsistências?

A inconsistência de código adiciona sua própria complexidade aos problemas de domínio.

Além disso, ser consistente requer menos esforço geral que o contrário.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (M. Fowler)

Existem muitas razões pelas quais as coisas que você está reclamando podem acontecer com um desenvolvedor perfeitamente bom.

Some example of inconsistencies might be:

Sometimes naming private variables with _ and sometimes not

Esse é meio chato. Eu fiz isso antes. Talvez eles estejam em um estado intermediário de ver se o postfix _ é algo que eles querem usar.

Sometimes having varying indentations within code blocks

Not aligning braces up i.e. same column if using start using new line style

Qualquer um deles pode ser atribuído ao codificador usando um editor que faz coisas para eles. Às vezes esses editores fazem algo estranho e você nunca sabe.

Ele também pode ter sido editado em vários editores e / ou por várias pessoas. Além disso, talvez seja o seu editor que está exibindo o código errado.

Spacing not always consistent around operators i.e. p=>p+1, p+=1 vs other times p =>p+1 or p => p + 1 etc

Typo, diferentes requisitos de formatação para diferentes condições, etc ...

Não se preocupe com as pequenas coisas. Traga essas coisas em revista, mas elas não são um grande sinal de um desenvolvedor ruim, não.

Um amigo programador meu tem dislexia. Ele não tem dificuldade com o raciocínio lógico ou com a escrita de código funcional, elegante e bem testado - tudo o que você poderia esperar de um desenvolvedor decente. Mas ele dificilmente pode escrever para salvar sua vida, e ele simplesmente não percebe inconsistências na ortografia e formatação tanto quanto outras pessoas, porque sua mente é melhor em prestar atenção a outros tipos de detalhes.

Esse é o extremo do espectro, mas você deve entender que, embora os desenvolvedores devam ser orientados a detalhes, nem todo desenvolvedor é orientado para detalhes da mesma forma , especialmente quando se trata de aspectos de o código que não afeta seu funcionamento real.

Linha de fundo: se você quiser código padrão, execute a formatação automática e passe para coisas mais importantes.

Acho que depende dos padrões da organização. Se você não tem algumas diretrizes de formatação, eu tentaria colocá-lo na agenda se eu fosse você.  Quando um padrão for aceito, você poderá usar a função de formatação do editor preferido para garantir que todos usem o mesmo padrão. (ele pode até mesmo usar o que ele gosta antes de enviá-lo para o autor se ele aplicar a ferramenta de formatação antes de enviar o código para o servidor de controle de origem)

Em relação às suas preocupações sobre os padrões dele, se o código dele não estiver formatado corretamente: acho que pode ser um indicador da atenção que ele dedica aos detalhes. Se você acha que este é o caso, pode ser algo para discutir, mas isso também pode ser pego em revisões de código e ele pode obter feedback significativo que ele pode aprender. fussing sobre o estilo de código só é como colocar forma sobre função para mim. Se ele escrever código desleixado, ele provavelmente também aparecerá em suas métricas de qualidade, portanto, apenas o estilo de código não vale a pena se preocupar, existem ferramentas para isso.