Você realmente escreve 'código limpo'? [fechadas]

Eu vi alguns programadores ajustando seu código repetidamente, não apenas para fazê-lo 'funcionar bem', mas também para 'parecer bom'.

Na IMO, 'código limpo' é na verdade um elogio, indicando que seu código é elegante, perfeitamente compreensível e sustentável. E a diferença surge quando você precisa escolher entre um código esteticamente atraente e um código estressante de se olhar.

Então, quantos de vocês realmente escrevem 'código limpo'? É uma boa prática? Quais são os outros benefícios ou desvantagens disso?

Eu diria que muitos de nós não escrevemos código limpo . E, geralmente, esse não é o nosso trabalho . Nosso trabalho como desenvolvedores de software é entregar um produto que funcione pontualmente.

Lembro-me da publicação no blog de Joel Spolsky: The Duct Tape Programmer .

Ele cita Coders at Work :

No final do dia, envie a coisa de merda! É ótimo reescrever seu código e torná-lo mais limpo e, pela terceira vez, ele será realmente bonito. Mas esse não é o ponto - você não está aqui para escrever código; você está aqui para enviar produtos. - Jamie Zawinsky

Também me lembro da resposta do blog de Robert Martin :

Assim. Seja esperto. Seja claro. Seja simples. Navio! E mantenha um pequeno rolo de fita adesiva pronto e não tenha medo de usá-lo. - Tio Bob

Se o código, um desenvolvedor escreve, passa a ser limpo E funciona (pode ser entregue), que seja bom para todos. Mas se um desenvolvedor está tentando criar código limpo e legível às custas de poder entregá-lo em tempo hábil, isso é ruim. Faça com que funcione, use fita adesiva e envie-a. Você pode refatorá-lo mais tarde e torná-lo super lindo e eficiente.

Sim, é uma boa prática escrever código limpo, mas nunca à custa de poder entregar. O benefício de entregar um produto com fita adesiva no prazo excede em muito os benefícios do código limpo que nunca foi finalizado e entregue.

Um bom pedaço de código que encontrei não está limpo. Alguns são absolutamente feios. Mas todos foram lançados e usados ​​na produção. Alguns podem dizer que não é profissional escrever código bagunçado. Discordo. O profissional é entregar um código que funcione, seja ele limpo ou confuso. O desenvolvedor deve fazer o melhor que puder, considerando o tempo alocado antes da entrega. Então, volte para limpar - isso é profissional. Felizmente, o código entregue não é fita adesiva pura e é 'suficientemente limpo'.

Você deve garantir que seu código seja muito legível, limpo e de manutenção. É o que todos os programadores devem fazer.

Mas você está falando over styling(como esse termo, melhor do código feminino ), que serve apenas o ego de seu autor.

Eu já vi muitos desenvolvedores no passado tão orgulhosos de sua criação (você sabe, como nos banheiros;)), que passaram horas limpando e polindo seu código. Alguns deles eram tão meticulosos que garantiram que os espaços em branco corretos entre os membros fossem respeitados.

É muito.

Acho esse tipo de comportamento contraproducente. Em um contexto profissional , você deve ser profissional . Você pode obter sua satisfação escrevendo códigos limpos, muito legíveis e de fácil manutenção e conversando com usuários ou colegas felizes.

Eu discordo da resposta aceita sobre esta questão.

Sua responsabilidade é obviamente enviada, mas geralmente você também tem a responsabilidade de enviar algo que possa ser mantido com o menor custo possível por você e por futuros desenvolvedores.

Passei períodos como um programador ou consultor de manutenção deficiente no local, que precisa entender e depurar um enorme sistema não documentado, e posso lhe dizer que projetos ruins e códigos confusos e confusos podem levar a horas ou até dias de esforço desperdiçado. Eu posso pensar em muitas situações em que N horas extras de esforço pelo desenvolvedor inicial poderiam levar a uma economia de 5N em termos de tempo.

Eu sei que há uma estatística flutuando sobre isso, mas na minha experiência em vários projetos, cada linha de código escrita é lida 5 a 20 vezes durante a extensão e manutenção.

Então, eu diria para limpar o código dentro de uma polegada de sua vida . Leva tempo, mas provavelmente é uma economia líquida de custos ao longo da vida do projeto.

Algum de nós compraria um carro se soubéssemos que, sob o capô, tudo é confuso e difícil de solucionar, manter ou consertar e são necessários mais recursos para rodar do que deveria?

Por que deveria ser diferente para um software?

Só porque os usuários finais não podem olhar sob o capô não significa que eles nunca saberão disso. Mais cedo ou mais tarde, ele aparecerá.

Respondendo à pergunta "Você realmente escreve 'código limpo'?" -- Oh sim.!

Se, por 'código limpo', você quer dizer que eu faço o possível para garantir que o código seja o mais claro possível?

Claro que sim.

Quanto mais limpo, claro o código, mais fácil é a manutenção e, assim, economiza tempo a longo prazo. Não olhe o código limpo como vaidade; veja isso como um investimento para economizar tempo e esforço futuros.

Honestamente, isso depende. Gosto de como todo mundo fala sobre como "qualquer coisa menos que um código bem documentado é uma pura farsa!", Mas trabalho em uma empresa com ciclos de implantação ridículos e supervisão zero: faço o melhor que posso, mas escrevo assim quanto código é extremamente difícil escrever o código perfeito e limpo que todos os outros afirmam escrever.

Tento escrever um código que possa ser facilmente mantido por alguém que possua aproximadamente minha capacidade. Comento as partes complicadas, nomeio os nomes amigáveis ​​dos programas, variáveis ​​e classes, implanto e continuo. Não tenho tempo para fazer mais nada.

Às vezes me sinto um pouco culpado por isso, mas não muito. Você deve ver alguns dos horrores com os quais lido diariamente. Décadas de código personalizado em idiomas obscuros com zero documentação. Um dos meus colegas de trabalho se desenvolve exclusivamente no Visual Basic 6.0 e implanta binários com nomes criptografados em todo o lugar. A mulher que substituí programava exclusivamente em RPG .

É extremamente difícil para mim acreditar, na mesma porcaria horrível que vi nos meus anos como programador, que todo mundo gera apenas código limpo.

Acho que não gosto do termo "código de garota", mas código limpo = código de manutenção. Qualquer coisa menos não é profissional.

Como regra geral, considero o próximo desenvolvedor que deve examinar minha bagunça.

Muitas vezes sou eu ... vários meses depois ... quando não me lembro como isso funciona ... e tenho ainda menos tempo para fazer uma mudança.

Eu tento escrever "código limpo" no sentido de Bob Martin (por exemplo, design OO). Há um grande valor na escrita de código limpo. É muito mais sustentável.

Então deixei o ReSharper torná-lo um "código bonito" para mim (por exemplo, alinhamento, quebras de linha etc.). Há um bom valor ao escrever um código bonito. Mas há retornos decrescentes. Alguma pré-certificação torna um pouco mais sustentável devido à facilidade de leitura.

Se você acha que é necessário alinhar grandes blocos de código para torná-lo legível, então o problema é seu enorme bloco de código! É muito grande. Eu vejo muitos exemplos de pessoas que se esforçam ao máximo para fingir algum código mal projetado.

Se eu não tivesse o ReSharper, ainda assim teria um código limpo, mas não seria tão bonito.

Eu não acho que deveria gastar mais do que ~ 5% do meu tempo de codificação na prettificação. O que significa que, quanto mais poderoso meu editor e mais proficiente sou com ele, mais prettificação posso fazer.

Parece que ninguém levanta a questão do que é do melhor interesse da sua empresa?

Freqüentemente, se não sempre, os programadores são apenas funcionários e, embora as decisões de gerenciamento possam nos frustrar, geralmente não temos todos os dados que eles possuem.

Por exemplo, digamos que a empresa tenha uma cláusula de que, se o software não estiver pronto a tempo, você não será pago (aconteceu apenas conosco, embora eu ache que recebemos o pagamento, afinal). Sim, o código limpo é importante, mas o mais importante é ter o código funcionando até o dia do pagamento!

Outro exemplo - a empresa está em uma situação financeira ruim e precisa arrecadar dinheiro. Adivinha quem se importa com a qualidade? Você pode corrigi-lo mais tarde, se for necessário, basta enviá-lo!

Um argumento pode ser "Por que devo vender e escrever códigos ruins?". Bem, por que sua empresa deveria pagar um cheque mensalmente? Escolhas, meu amigo. Se você está atrás do idealismo, tente a Free Software Foundation ; Ouvi dizer que eles estão fazendo coisas bem legais (quero dizer, este, e eu respeito a FSF e OSS).

Por outro lado, se você trabalha em um projeto em que é esperado um crescimento explosivo no uso (embora essas projeções quase nunca sejam precisas), é melhor estabelecer uma base sólida com a melhor qualidade de código necessária, pois é quase certo que a manutenção será necessária. ser o maior custo para o projeto.

Os programadores adoram código 'limpo', o que quer que isso signifique. Não podemos nem concordar com o que é limpo, mas adoramos. No entanto, às vezes isso não importa tanto quanto a usabilidade e a correção. Isso pode parecer sinônimo, mas não é - se você vê código escrito por um verdadeiro hacker Perl em 4 horas com a intenção de ser usado duas vezes e jogado fora, você reconheceria que não está limpo, mas funciona.

Então, às vezes, deixando de lado o ego, devemos fazê-lo funcionar. Observe que eu não recomendo escrever código ruim como hábito; Estou apenas apontando que pode ser necessário. A perfeição leva tempo que sua empresa pode não ter. Portanto, se o seu empregador não se importa, crie software, mas se precisar, basta escrever o código de trabalho, não se preocupe com a 'limpeza'. Não é apenas uma resposta 'tamanho único' - você deve priorizar.

Não tenho certeza de que "ter uma boa aparência" e ser "elegante, perfeitamente compreensível e sustentável" seja equivalente.

Eu tento escrever um código que seja "elegante, perfeitamente compreensível e sustentável". Refatoro meu próprio código para melhor atender a esses critérios.

Não vejo desvantagens, exceto o custo resultante no tempo.

Para que o código "pareça bom", existem muitas ferramentas automatizadas que recuam e espaçam adequadamente tudo o que você deseja.

Muita coisa nunca é boa.

No entanto, uma coisa importante a ter em mente com o código "impuro" é que ele pode facilmente levar a " janelas quebradas ". Se o código estiver muito mal formatado, acho que muitas pessoas novas na base de código podem se sentir menos inclinadas a fazer um bom trabalho com manutenção e evolução, causando uma espiral descendente que pode afetar a condição de trabalho do software.

Portanto, manter um certo nível de limpeza no código é benéfico para mais do que apenas seus colegas desenvolvedores. Não gaste muito tempo com isso (~ 5% foi mencionado). Aprenda a usar as ferramentas do seu ofício para automatizar tarefas manuais (neste caso, formatação de código). Assuma a responsabilidade pelo que faz e sempre faça o que achar mais benéfico para sua empresa / clientes / usuários.

Esta é uma citação de Clean Code, de Bob Martin:

Para levar esse ponto adiante, e se você fosse médico e tivesse um paciente que exigisse que você parasse toda a lavagem boba das mãos em preparação para a cirurgia, porque estava demorando muito? Claramente, o paciente é o chefe; e, no entanto, o médico deve se recusar absolutamente a cumprir. Por quê? Porque o médico sabe mais do que o paciente sobre os riscos de doenças e infecções. Seria pouco profissional (não importa como criminoso) o médico cumprir com o paciente.

Da mesma forma, não é profissional que os programadores se curvem à vontade dos gerentes que não entendem os riscos de fazer bagunça.

Eu acho que "código limpo" deve ser tão limpo ou mais limpo do que como você costumava escrever nos seus exames de física / engenharia / matemática. Se estiver muito bagunçado, o aluno não entenderá o seu trabalho e provavelmente o marcará errado, mesmo que esteja certo.

Eu gosto que o código seja legível, mas o mais importante é a consistência. Para mim, isso significa consistência com convenções de nomenclatura e espaçamento entre funções, parênteses na mesma linha ou na próxima linha da instrução if, etc.

Claro, há momentos em que alguém programa algo com um estilo de código consistente e isso ainda me deixa louco. Especialmente código que não "respira". Por exemplo:

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

Bem ... Parece pior com os métodos Objective-C, e com muitas instruções if aninhadas e linhas com muito mais de 80 caracteres. Mas ainda me irrita :)

Eu me esforço muito para limpar o código. Eu acho que ajuda muito os bugs que se destacam.

Não concordo com o conceito de "enviar a merda agora", porque o código limpo é um investimento para o futuro. Também muitos softwares são enviados com muitos bugs. Resolver um bug na minha opinião é melhor do que implementar um novo recurso.

Além disso, se você olhar para as estimativas de produtividade do programador , não acho que tenha uma pontuação muito ruim. Escrever código limpo é um hábito, e quanto mais experiência como programador, mais eficiente ele se torna. Se alguém nunca tentar, obviamente, nunca obterá experiência com isso.

Outro ponto a ser levado em consideração é que a maior parte do tempo do desenvolvedor é dedicada à leitura do código; portanto, o código legível reduz bastante o tempo gasto na leitura. Entender algoritmos não documentados, por exemplo, pode ser caro e convidar novos erros.

Uma coisa que eu definitivamente sinto falta e gostaria de ter um dia é um formatador de código automático que eu possa adaptar ao meu estilo, que realmente me pouparia algum tempo, especialmente ao ler o código de outras pessoas.

A codificação limpa tem um link para o perfeccionismo, que corre o risco de nunca se materializar, mas acho que isso é principalmente um problema quando você começa, porque investe mais tarde e reutiliza seus próprios pedaços de código elegantes, combinados com sua experiência , envelhecendo, você será muito produtivo e muito menos assombrado por bugs do que os codificadores confusos.

Este é um pedaço de código que demonstra meu estilo de codificação.

Apenas evite "código de vaidade". Existem muitos desenvolvedores por aí que fazem coisas puramente por vaidade (ou devido a um TOC) e nada mais. Minha calcinha realmente se torce com essas pessoas.

Escrevo código que tenta resolver o problema em questão da maneira mais eficiente e teoricamente 'elegante'. Nesse sentido, apenas ele é limpo. Se isso for "bonito" quando eu terminar, que assim seja.

O que descobri em minhas experiências limitadas é que, quando as pessoas reclamam de 'código limpo', a feiúra geralmente é resultado de uma solução terrível, e não de uma convenção de codificação.

Eu diria que faço um esforço para escrever um código mais limpo, mas isso pode mudar devido a restrições de tempo ou se estou trabalhando em algo difícil. Ele tende a ficar confuso ao se concentrar em fazê-lo funcionar. Então eu voltarei e limpei enquanto reviso. Se você retornar ao código e precisar gastar muito tempo atualizando sua memória, não comentou o suficiente.

O código limpo é bom, mas como todo o resto, ele precisa estar limpo o suficiente. Recuar 5 linhas de código 4 espaços e uma linha 5 espaços não aumenta a dificuldade de leitura.

Eu acho que depende do que você está fazendo. Se estou escrevendo um aplicativo de prova de conceito, basicamente estou codificando como cowboy e não olhando para trás. Se estou trabalhando em um aplicativo em que realmente vou trabalhar por um tempo, certifique-se de codificá-lo suficientemente bem e torná-lo compreensível daqui a um mês.

Eu acho que estilizar seu código é um pouco duvidoso. Como já foi dito acima, seu trabalho é fabricar um produto, não um código formatado, mas eu diria que pelo menos um deve seguir um estilo definido de comentar e codificar. Eu odiaria ver metade das variáveis ​​camel cased e a outra metade húngara.

Mas também depende do que você quer dizer com 'código limpo'.

Eu admito fazer isso; e o benefício não fica aborrecido toda vez que o vejo. Eu acho que também é mais fácil de ler e, portanto, os erros se tornam mais óbvios; mas a verdadeira razão é que não suporto código feio.

A refatoração do código para torná-lo elegante facilita a leitura e a manutenção. Mesmo pequenas coisas, como alinhar suas atribuições de variáveis:

int foo    = 1;
int bar    = 2;
int foobar = 3;

é mais fácil de ler do que

int foo = 1;
int bar = 2;
int foobar = 3;

o que significa que é mais fácil deslizar quando você está depurando mais tarde.

Além disso, no PHP você tem permissão para qualquer número de blocos de código aleatórios. Eu os uso para agrupar tarefas lógicas:

// do x
{
    // ...
}

// do y
{
    // ...
}

Isso adiciona uma definição clara ao código relevante.

Editar : como um bônus adicional, é fácil preceder um desses blocos de código lógico com um if (false)se você quiser pular temporariamente sobre ele.

Acabei de escrever meu código, seguindo os padrões da empresa. Se eu quiser "embelezado", posso executá-lo através de um embelezador de código.