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

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 no prazo.

Lembro-me da postagem no blog de Joel Spolsky: The Duct Tape Programmer .

Ele cita Codificadores no trabalho :

At the end of the day, ship the f*****g thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products. - Jamie Zawinsky

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

So. Be smart. Be clean. Be simple. Ship! And keep a small roll of duct tape at the ready, and don’t be afraid to use it. - Uncle Bob

Se o código, um desenvolvedor escreve, está limpo e funciona (é entregável), então seja bom para todos. Mas se um desenvolvedor está tentando fazer um código limpo e legível às custas de ser capaz de entregá-lo em tempo hábil, então isso é ruim. Faça funcionar, 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 às custas de ser capaz de fornecer. O benefício de entregar um produto com fita adesiva no tempo supera em muito os benefícios de um código limpo que nunca foi concluído e entregue.

Um bom pedaço de código que eu encontrei não é limpo. Alguns são francamente feios. Mas eles foram todos liberados e usados na produção. Alguns podem dizer que não é profissional escrever código confuso. Discordo. O profissional é entregar o código que funciona, seja ele limpo ou confuso. O desenvolvedor deve fazer o melhor que puder, dado o tempo que foi alocado antes da entrega. Então, volte para limpar - isso é profissional. Espero que o código entregue não seja fita adesiva pura e esteja "limpo o suficiente".

Você deve garantir que seu código seja legível, limpo e sustentável. Isso é o que todos os programadores devem fazer.

Mas você está falando sobre over styling (como aquele termo melhor que código de garota ) que não serve senão para o ego de seu autor.

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

É demais.

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

Eu não concordaria com a resposta aceita sobre essa questão.

Sua responsabilidade é, obviamente, de enviar, mas normalmente você também tem a responsabilidade de enviar algo que seja sustentável da maneira mais econômica possível para você e futuros desenvolvedores.

Eu passei períodos como aquele programador de manutenção ou consultor de baixa qualidade que tem que entender e depurar algum sistema imenso e não documentado, e posso dizer que projetos ruins e código bagunçado confuso podem levar a horas ou até dias de esforço desperdiçado . Posso pensar em muitas situações em que um esforço adicional de N horas do desenvolvedor inicial poderia 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 que está escrita é lida 5-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 é provável que haja uma economia líquida de custos ao longo da vida do projeto.

Algum de nós compraria um carro se soubéssemos que, por dentro, tudo é confuso e difícil de solucionar problemas, manter ou consertar e é preciso mais recursos para executar 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 o saberão. Mais cedo ou mais tarde, ele aparecerá.

Respondendo a pergunta "Você realmente escreve 'código limpo'?" - Sim, sim!

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

Pare com isso.

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

Honestamente, isso depende. Eu gosto de como todo mundo fala na linha do partido sobre como "nada menos que código bem documentado e limpo é uma pura farsa!", Mas eu trabalho em um negócio com ciclos de implementação ridículos e zero supervisão: eu faço o melhor que posso, mas escrevo muito código é extremamente difícil escrever o código perfeito que todos os outros afirmam escrevem.

Eu tento escrever código que pode ser facilmente mantido por alguém que tenha mais ou menos a minha capacidade. Eu comento as partes complicadas, eu nomeio os programas, variáveis e classes de nomes amigáveis, eu implantei e segui em frente. Não tenho tempo para fazer mais nada.

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

É extremamente difícil para mim acreditar, porcaria tão horrível como eu vi nos meus anos como programadora, que todos só gera código limpo.

Eu não acho que eu goste do termo "código de garota", mas código limpo = código de manutenção. Qualquer coisa menos é pouco profissional.

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

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

Eu tento escrever "código limpo" no sentido Bob Martin (por exemplo, design OO). Existe um valor ótimo ao escrever código limpo. É muito mais sustentável.

Então deixo o ReSharper fazer "código bonito" para mim (por exemplo, alinhamento, quebras de linha etc.). Existe um valor bom ao escrever um código bonito. Mas há retornos decrescentes. Alguns prettification torna um pouco mais sustentável, devido à facilidade de leitura.

Se você acha que alinhar blocos enormes de código é necessário para torná-lo legível, então o problema é o seu enorme bloco de código! É muito grande. Vejo muitos exemplos de pessoas que se esforçam muito para aperfeiçoar um código muito mal projetado.

Se eu não tivesse o ReSharper, ainda teria 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 em mim. O que significa que quanto mais poderoso for meu editor e quanto mais proficiente estou com ele, mais beleza eu posso fazer.

Parece que ninguém levanta o ponto de qual é o melhor interesse da sua empresa?

Muitas vezes, se nem sempre, os programadores são apenas funcionários e, embora as decisões administrativas possam nos frustrar, muitas vezes não temos todos os dados que eles fazem.

Por exemplo, digamos que a empresa é contratada com uma cláusula 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). Sim, código limpo é importante, mas o mais importante é ter o código funcionando no dia do pagamento!

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

Um argumento pode ser "Por que eu deveria vender e escrever código de baixa qualidade?" Bem, por que sua empresa deveria pagar um bom cheque a cada mês? Escolhas, meu amigo. Se você está atrás do idealismo, tente a Fundação do Software Livre ; Ouvi dizer que eles estão fazendo algumas coisas bem legais (quero dizer, e respeito a FSF e OSS).

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

Programadores amam código 'limpo', o que quer que isso signifique. Nós não podemos nem concordar com o que é limpo, mas nós amamos isso. No entanto, às vezes isso não importa tanto quanto a usabilidade e a correção fazem. Estes podem parecer sinônimos, mas não são - se você viu o 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, com o ego de lado, devemos apenas fazer com que funcione. Note que eu não recomendo escrever código ruim como um hábito; Só estou apontando que isso pode ser necessário. Perfeição leva tempo que sua empresa pode não ter. Portanto, se o seu empregador não se importar, crie software, mas, se precisar, apenas escreva um código de trabalho, não importa a 'limpeza'. Não é apenas uma resposta 'tamanho único' - você deve priorizar.

Não sei se "parece bem" e ser "elegante, perfeitamente compreensível e sustentável" é equivalente.

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

Não vejo nenhuma desvantagem, exceto o custo resultante no tempo.

Para que o código fique "bonito", há várias ferramentas automatizadas que recolhem e espaçam adequadamente tudo que você desejar.

Grande parte de algo nunca é bom.

No entanto, uma coisa importante a ter em mente com o código "impuro" é que ele pode levar facilmente 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 eventualmente 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 nisso (~ 5% foi mencionado). Aprenda a usar as ferramentas do seu ofício para automatizar tarefas manuais (formatação de código, neste caso). Assuma a responsabilidade pelo que você faz e sempre faça o que você considera mais benéfico para sua empresa / clientes / usuários.

Esta é uma citação do Código Limpo, de Bob Martin:

To drive this point home, what if you were a doctor and had a patient who demanded that you stop all the silly hand-washing in preparation for surgery because it was taking too much time? Clearly the patient is the boss; and yet the doctor should absolutely refuse to comply. Why? Because the doctor knows more than the patient about the risks of disease and infection. It would be unprofessional (never mind criminal) for the doctor to comply with the patient.

So too it is unprofessional for programmers to bend to the will of managers who don’t understand the risks of making messes.

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

Eu gosto de código para ser legível, mas o mais importante é a consistência. Para mim, isso significa consistência com as 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 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 e muitas instruções if aninhadas, e linhas com mais de 80 caracteres. Mas isso ainda me incomoda:)

Eu faço muito para limpar o código. Eu acho que ajuda muito os bugs se destacarem.

Eu não concordo com o conceito de "ship the fucking thing now", porque o código limpo é um investimento para o futuro. Também muitos softwares são enviados com muitos erros. Resolver um bug na minha opinião é melhor do que implementar um novo recurso.

Além disso, se você olhar para estimativas de produtividade do programador , eu não acho que vou marcar muito mal. Escrever código limpo é um hábito, e quanto mais experiência como programador, mais eficiente se torna nisso. Se nunca se tenta, obviamente, nunca se experimentará.

Outro ponto a ter em conta, é que a maior parte do tempo do programador vai para a leitura de código, por isso o código legível reduz bastante os tempos de leitura. Compreender algoritmos não documentados, por exemplo, pode ser caro e convidar novos bugs.

Uma coisa que definitivamente sinto falta e gostaria de ter um dia é um formatador de código automático que eu poderia 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 tem o risco de nunca se concretizar, mas acho que isso é principalmente um problema quando você começa, porque você investe mais tarde e reutiliza seus próprios códigos elegantes, combinados com a sua experiência, envelhecendo você será muito produtivo e muito menos assombrado por bugs do que os codificadores confusos.

Esta é uma peça de código que demonstra meu estilo de codificação.

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

Eu escrevo código que tenta resolver o problema dado de maneira mais eficiente e teoricamente 'elegante'. Nesse sentido, apenas está limpo. Se acontecer de ser "bonita" quando eu terminar, que assim seja.

O que eu encontrei em minhas experiências limitadas é que quando as pessoas reclamam de 'código limpo', a fealdade é geralmente resultado de uma solução terrível ao invés de convenção de codificação.

Eu diria que faço um esforço para escrever 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 quando se concentra em fazê-lo funcionar. Então eu vou voltar e limpar como eu revê-lo. Se você retornar ao código e tiver que gastar muito tempo atualizando sua memória, não comentou o suficiente.

O código limpo é bom, mas como tudo mais, 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 eu estou escrevendo um aplicativo de prova de conceito, então eu sou basicamente um código de cowboy e não olho para trás. Se estou trabalhando em um aplicativo no qual eu realmente trabalharei por um tempo, então me certifico de codificá-lo bem o suficiente, além de torná-lo compreensível daqui a um mês.

Eu acho que estilizar seu código é um pouco duvidoso. Como alguns acima disseram, o seu trabalho é fazer um produto, não um código formatado, mas eu diria que, pelo menos, um deve ficar com um estilo definido de comentar e codificar as coisas. Eu odiaria ver metade das variáveis camel e a outra metade húngara.

Mas também depende do que você entende por 'código limpo'.

Admito fazer isso; e o benefício não está ficando irritado toda vez que eu 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.

Refatorar seu 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 analisar 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.

Acabei de escrever meu código, seguindo os padrões da empresa. Se eu quiser "enfeitar", posso executá-lo por meio de um embelezador de código.