Existe algum benefício na obsessão de tornar o código "bonito"?

Às vezes, passo quantidades ridículas de tempo (horas) agonizando para tornar o código "bonito". Quero dizer, fazer as coisas parecerem simétricas. Na verdade, vou rolar rapidamente por toda uma turma para ver se algo salta como não parecendo "bonito" ou "limpo".

Estou perdendo meu tempo? Existe algum valor nesse tipo de comportamento? Às vezes, a funcionalidade ou o design do código nem mudam; eu apenas o reestruturo para que fique mais bonito.

Estou apenas sendo totalmente TOC ou há algum benefício oculto nisso?

Use um formatador automático. Se você realmente está gastando muito tempo editando o código manualmente, eu gostaria de adivinhar que você não é muito desafiado / entediado, porque não há absolutamente nenhuma razão para isso. Ctrl + K, Cntrl + D no VS formatará um documento inteiro. Você pode usar algo como Style Cop se quiser algo um pouco mais pesado.

É bom ter orgulho do seu código, mas não quando se trata de ser inteligente (procurando a solução mais eficiente. Nesse caso, usando uma ferramenta para automatizar um processo tedioso) e fazer as coisas (o que mais poderia você trabalhou durante essas horas?).

Se você não está mudando nada que permita que seja melhor compreendido, então sim, você está desperdiçando seu tempo.

Nada oculto, código bonito, é fácil de ler e fácil de manter.

"Horas" parece um pouco excessivo, a menos que você tenha uma enorme base de código. Nem tudo tem que ser perfeito, apenas tem que ser bom

É uma questão de julgamento; se você estiver gastando horas, eu diria que você está exagerando. No entanto, há coisas que um ser humano pode fazer que um formatador automático não pode e coisas que você pode fazer para tornar seu código mais legível e difícil de capturar nos padrões corporativos de codificação.

Por exemplo, ao declarar variáveis ​​em uma classe, eu gosto de ter agrupamentos lógicos - facilita o acompanhamento da lógica.

O código geralmente é considerado "escreva uma vez, leia muitos", portanto, tornar a experiência de leitura agradável é um bom hábito - mas na minha opinião o layout é muito menos problemático do que convenções de nomenclatura claras, abstrações limpas e assinaturas de método bem estruturadas.

Eu vi código lindamente formatado que causou momentos graves de WTF porque o processo de pensamento subjacente foi defeituoso. Se você tiver horas para gastar, eu gastaria em design e refatoração, em vez de layout ...

Não, você não está sendo totalmente TOC. O maior elogio que já ouvi como programador foi: "Seu código é tão limpo que meu irmãozinho conseguiu descobrir."

Algum dia alguém precisará dar suporte ao seu código. Código limpo é muito mais fácil de suportar. E algum dia pode ser você. Em 6 meses ou um ano você não vai se lembrar do que fez. Mas se for limpo e fácil de ler, voltará rapidamente.

Dito isto, se o código é lixo, não ajuda ser um lixo bonito. Mas se estiver bem estruturado e tiver apenas problemas de funcionalidade, será muito mais fácil melhorar a funcionalidade.

Não - ser obcecado em fazer o código parecer bonito está faltando .

Aqui estão algumas dicas que eu achei úteis:

Pergunte por que o código precisa ser arrumado.

Você pode ou não estar perdendo seu tempo, dependendo da sua definição de bonita.

O Teorema Fundamental da Formatação diz que um bom layout visual mostra a estrutura lógica do programa. Fazer o código parecer bonito vale algo, mas vale menos do que mostrar a estrutura do código. [página 732, Code Complete 2nd Edition, Steve McConnell]

Se você usar o sistema de versões simultâneas para rastrear alterações no código - não misture alterações de formatação de código com alterações lógicas / adicionando recursos dentro do mesmo commit.

Isso tornará as alterações mais difíceis de detectar e causará conflitos desnecessários de mesclagem se outros membros da equipe estiverem editando o arquivo. Se você precisar fazer alterações na formatação, verifique se outros membros da equipe não estão trabalhando nesse arquivo. [Parafraseado, página 93, Controle de versão pragmático usando o Subversion, 2ª edição]

Martin Fowler também fala sobre 'usar dois chapéus' e alternar entre eles ao longo do dia. Um chapéu para adicionar recursos, um chapéu para refatoração.

1. Você considera adicionar um novo recurso (Feature Hat)
2. Você lê o código existente para obter entendimento, organizando-o à medida que avança. (Chapéu de refatoração)
3. Confirme as alterações.
4. Adicione o recurso. (Chapéu de recurso) e assim por diante ....

[Parafraseado, página 57, Refatoração, Martin Fowler]

Portanto, não gaste horas tentando embelezar toda a base de código. Basta pré-codificar o código necessário para adicionar o próximo recurso.

Resumindo ... deixe cada pedaço de código em um estado melhor do que quando você chegou pela primeira vez.

Se for puramente formatado, é melhor você investir algum tempo ensinando a uma impressora bonita como deseja que seu código seja formatado. Isso é um pouco caro, mas imagino que você recuperará esse cronômetro em 2 a 3 usos.

Se for refatoração real, possivelmente não. O código conceitualmente limpo tende a ser mais fácil de modificar daqui para frente e ter "sempre limpo" diminui a tentação de deixar passar alguma coisa só porque há outro código fedorento por aí.

Isso ajuda um pouco, mas não vale a pena gastar muito tempo com isso. Verifique também se suas melhorias também adicionam escopo variável, RAII, código de cópia / colagem de grupo etc. Se você fizer tudo isso, fica 1000x mais fácil quando precisar entender o que o código faz depois de um ano ou mais.

Você deve produzir um código limpo, mas não deve levar horas.

Para C, existe o programa gnu-gnu-indent gnu-indent , no eclipse, há pelo menos um formatador de código para Java, e acho que também existem ferramentas para a maioria das outras linguagens. Devem ser necessários alguns cliques para recuar um arquivo corretamente e alguns minutos, se você quiser violar as regras para fins específicos - como eu faço para instruções curtas de caso de troca:

 switch (foo) {
      case a:  foo (a);             break; 
      case b:  foob ();             break;
      case c:  /* intent. empty */
      case d:  foocd ();            break; 
      default: allPrettyAligned (); break; 
 }

o que é difícil de especificar.

Se você acha que algo parece limpo ao deslizá-lo, você está se concentrando em algo superficial que pode ser automatizado.

Leia este artigo clássico sobre "Fazendo o código errado parecer errado" e você verá exatamente por que as pessoas geralmente pensam que o recuo (o que pode ser feito automaticamente) é trivial:

http://www.joelonsoftware.com/articles/Wrong.html

Particularmente esta lista:

OK, até agora mencionei três níveis de conquista como programador:

1 Você não sabe limpar de imundo.

2) Você tem uma idéia superficial de limpeza, principalmente no nível de conformidade com as convenções de codificação.

3) Você começa a cheirar dicas sutis de impureza sob a superfície e elas o incomodam o suficiente para alcançar e corrigir o código.

Há um nível ainda mais alto, porém, é sobre isso que eu realmente quero falar:

4) Você deliberadamente arquitetou seu código de forma que seu nariz por imundice torne seu código mais provável de estar correto.

Essa é a arte real: criar código robusto, literalmente, inventando convenções que fazem com que os erros se destacem na tela.

"Horas"? Bem, eu diria que sua resposta é "e", não "ou": sim, você está sendo TOC, mas há algum benefício nisso.

Provavelmente.

Isso facilita a leitura rápida do seu código? Torna mais fácil percorrer, descobrir o que para e começa onde, encontrar funções, variáveis, etc? Isso torna a maneira como seu código funciona mais claro? O processo de esclarecimento força você a revisitar algumas decisões de design e a remover o código morto ou remover as soluções incompletas que você abandonou? Se assim for, absolutamente tem valor.

Por outro lado, se você descobriu uma maneira perversa de apelar ao seu próprio senso de estética sem realmente tornar seu código mais fácil de trabalhar, então sim, é uma grande perda de tempo.

Quanto a mim, tenho a tendência de cair no fim do TOC - mas não vou parar. O ato de fornecer documentação para uma classe ou função me obriga a pensar sobre como a coisa realmente funciona - estou escrevendo para que alguém que não seja eu possa entender, afinal. E se eu me deparar com várias advertências, avisos e desculpas por que o código funciona da maneira que funciona, é um aviso bastante forte de que precisa de mais uma rodada de ajustes antes que eu o declare concluído.

Primeiro, nada de errado em tornar seu código bonito porque, eventualmente, você deseja se orgulhar de sua criação e apresentação / formatação de código fazer parte disso.

No entanto, seria cuidadoso em não formatar demais o seu código para bem dos seus colegas de trabalho ou futuros desenvolvedores. Bonita para você pode não ser bonita para mim. :)

Você reconhece o problema (comportamento compulsivo) e o sintoma (formatação obsessiva).

E a causa e a cura?

• Você está trabalhando muitas horas?
• Você está frustrado, entediado, ansioso?
• Qual é a sua próxima tarefa? É algo que você não quer fazer?
• Quando você tirou férias pela última vez? Promoção? Reconhecimento por uma conquista?
• É um problema relacionado ao esgotamento?
• Você está em uma marcha da morte?

Às vezes, esses sintomas são um sinal de que é hora de fazer mudanças ousadas ou seguir em frente.

Apesar de seu título mais baixo, o livro de Yourdon tem muitas sugestões úteis e, para muitas organizações, está fazendo uma descrição bastante real.

http://dev.co.ua/docs/Edward%20Yourdon%20-%20Death%20March.pdf

Você parece bem perspicaz e acho que talvez você saiba a resposta.

Agora, permita-se agir sobre isso.

Santo Bovino!
Vocês nunca ouviram falar de recuo?

é um utilitário de formatação de código que existe há mais de 20 anos. Possui um mega balde de opções para que seu código possa ser formatado da maneira que você desejar, automaticamente.

ermm - mas funciona apenas em C e em alguns, mas não em C ++ .... (wtf? por que o GNU não atualiza isso?)