O que significa escrever “ bom código ”? [fechado]

Não há realmente nenhum bom critério outro do que o quão rápido você pode entender o código. Você faz seu código parecer bom encontrando o meio-termo perfeito entre sucinto e legibilidade.

Os “WTF” s por minuto “(acima) é verdade, mas é apenas um corolário da regra mais geral. Quanto mais WTFs, mais lento é o entendimento.

Comentários

• @rmx: define " fazendo o trabalho bem "
• Bem, que o método RemoveCustomer realmente remove o cutomer sem bagunçar. Você pode passar horas fazendo com que pareça bonito, mas isso não significa que realmente funcione. ' O quão rápido você pode entender o código ' não é o único critério para ' bom código ' é o que eu ' estou dizendo.
• @rmx: mas estar livre de erros está implícito, isn ' não é? Se o seu código não ' não realizar o trabalho corretamente, ' não é código (ainda).
• @ rmx: na verdade, não. Se o seu código for fácil de entender, em conclusão, ele ' é fácil de entender se o fizer ' mal o trabalho. OTOH, se ' for difícil de entender, será ' difícil de entender se for ' s trabalho em tudo.
• @rmx: PS Simplificando, seu decrement () é um WTF clássico e, portanto, retarda a compreensão das partes do código onde esta função é usada

Você sabe que escreve um bom código quando …

1. O cliente está feliz
2. Colegas de trabalho pegam seu código emprestado como ponto de partida
3. O novato / garota acabou de dizer para fazer modificações em um sistema que você construiu há 6 meses e ele / ela nunca fez uma pergunta a você
4. Seu chefe pediu que você desenvolvesse novos widgets para a equipe a ser usada
5. Você olha para o código que escreve hoje e diz para si mesmo “Eu gostaria de ter escrito um código como este há dois anos”

Como você meça se o código é bom …

• Qual é o tempo de resposta?
• Quantas viagens de ida e volta para o servidor ele faz?
• Você usaria pessoalmente o aplicativo ou acha que é desajeitado?
• Você o construiria da mesma forma na próxima vez?

Um bom código funciona quando é suposto. Um bom código pode ser facilmente modificado quando necessário. Um bom código pode ser reutilizado para gerar lucro.

Comentários

• " O cliente está feliz " é ortogonal a isso.
• @TRA – Se o cliente estiver satisfeito, isso significa que você entendeu os requisitos e forneceu a solução que eles esperavam.
• claro, mas um código ruim pode fazer o mesmo.

Um código que é

1. sem bugs

2. reutilizável

3. independente

4. menos complexo

5. bem documentado

6. fácil de modificar

é chamado de bom código.

Um bom programa funciona perfeitamente e não tem bugs. Mas que qualidades internas produzem tal perfeição? Não é nenhum mistério, só precisamos de alguns lembretes ocasionais. Quer você codifique em C / C ++, C #, Java, Basic, Perl, COBOL ou ASM, toda boa programação exibe as mesmas qualidades consagradas pelo tempo: simplicidade, legibilidade, modularidade , camadas, design, eficiência, elegância e clareza eficiência, elegância e clareza

Fonte: MSDN

Comentários

• Simplicidade, legibilidade, elegância e clareza são a mesma coisa. Modularidade e camadas são apenas métodos para tornar seu código claro e elegante. A única coisa que resta na lista é a eficiência, o que está meio implícito e, além disso, muitas vezes é uma questão de compromisso entre eficiência e clareza.
• Verifique isto: goo.gl/hdQt8
• O código pode estar livre de erros?
• Não, pode ' t. (Praticamente)
• Eficiente deve ser adicionado à sua lista. Velocidade isn ' t necessária arily um indicador primário de bom código, mas bom código não deve ' t ser desnecessariamente lento ou desperdiçador.

Isso parece familiar?

A Philips me deu a oportunidade de assistir ao design de um novo produto. Com o desenvolvimento, fiquei cada vez mais inquieto e comecei a confidenciar minhas preocupações ao meu supervisor. Eu disse várias vezes a ele que os designs não eram “limpos” e que deveriam ser “bonitos” da mesma forma que os designs de Dijkstra eram bonitos. Ele não achou este comentário útil.Ele me lembrou que éramos engenheiros, não artistas. Em sua mente, eu estava simplesmente expressando meu gosto e ele queria saber que critério eu estava usando para fazer meu julgamento. Não consegui dizer a ele! Como não pude explicar quais princípios estavam sendo violados, meus comentários foram simplesmente ignorados e o trabalho continuou. Sentindo que deveria haver uma forma de explicar e motivar o meu “gosto”, comecei a tentar encontrar um princípio que pudesse distinguir os bons designs dos ruins. Os engenheiros são muito pragmáticos; eles podem admirar a beleza, mas buscam utilidade. Tentei encontrar uma explicação de por que “beleza” era útil.

Veja o resto aqui .

Comentários

• Visto que o link na postagem de @mlvljr ' está quebrado , aqui está um link para a página do Google Livros: books.google.co.in/…
• @balajeerc Obrigado (eu também corrigi o link, então ele aponta para uma versão hospedada pela Springer do mesmo pdf) 🙂

à parte dos critérios naturais de qualidade do código (mínimo copiar / colar, sem espaguete, etc.), um bom código industrial deve sempre parecer um pouco ingênuo, um pouco prolixo, como

int key = i; const bool do_not_create = false; Record r = cache.get(key, do_not_create); ++i; 

em oposição a

Record r = cache.get(i++, false); 

Comentários

• Mas do_not_create = false significa “passar false como o argumento do_not_create para que será criado ”ou“ pas s false como o argumento do_create para que não seja criado ”? Em um idioma em que você possa usar nomes de argumento, eu preferiria cache.get (key:i, create: false); i += 1;.

Talvez uma resposta ilustrando o oposto ajude (além disso, é uma desculpa para inserir o XKCD aqui).

Um bom código é

• simples de entender,
• fácil de manter ,
• não tenta resolver todos os problemas, apenas o que está em mãos
• vive por muito tempo sem fazer os desenvolvedores procurarem alternativas

Os exemplos incluem

• Apache Commons
• framework Spring
• framework Hibernate

Vou simplesmente optar por “sustentável”

Todo o código deve ser mantido: não há necessidade de tornar essa tarefa mais difícil do que o necessário

Se algum leitor não entender este requisito simples ou precisar que ele seja explicado, então esse leitor não deve escrever código …

Um bom código será diferente para cada pessoa e a linguagem com que eles estão trabalhando também tem um impacto sobre o que pode ser considerado para ser um bom código. Geralmente, quando abordo um projeto, procuro o seguinte:

• Como o projeto é organizado? Os arquivos de origem estão organizados de maneira limpa e posso encontrar o código sem muito esforço?
• Como o código é organizado? Está claramente documentado o que o código no arquivo faz, como por meio do uso de um cabeçalho de arquivo ou pelo uso de cada classe que reside em seu próprio arquivo? Existem funções no arquivo que não estão mais sendo usadas no aplicativo?
• Como as funções são organizadas? Existe um padrão claro para onde as variáveis são declaradas ou é um padrão razoavelmente aleatório? O código tem um fluxo lógico e evita estruturas de controle desnecessárias? Está tudo claramente documentado com o código sendo autodocumentado onde necessário e os comentários expressam claramente o porquê e / ou como o que o código está fazendo?

Além de tudo isso, o design do aplicação faz sentido como um todo? O código que reside no aplicativo pode ser o melhor do mundo, mas ainda assim pode ser difícil de trabalhar se o design geral do aplicativo não fizer sentido.

Gostaria de discordar quanto à legibilidade. Não, não completamente: um bom código deve ser legível e isso pode ser facilmente alcançado com comentários suficientes.

Mas considero dois tipos de WTF: aqueles em que você se pergunta se o programador foi além da programação 101 e aqueles em que você absolutamente não compreende a genialidade do código. Alguns códigos podem parecer muito estranhos em primeiro, mas é na verdade uma solução muito inventiva para um problema difícil. O segundo não deve contar no medidor WTF e pode ser evitado por comentários.

Um código muito legível pode ser muito, muito lento . Uma solução menos legível pode proporcionar uma melhoria múltipla na velocidade. R é um ótimo exemplo de uma linguagem onde isso geralmente é verdade. Gostamos de evitar loops for lá o máximo possível.Em geral, eu consideraria o código mais rápido o melhor código, embora seja menos legível. Ou seja, se a melhoria está substancialmente fora do curso e comentários suficientes são inseridos para explicar o que o código faz.

Ainda mais, o gerenciamento de memória pode ser crucial em muitas aplicações científicas. O código que é muito legível, tende a ser meio desleixado no uso de memória: há apenas mais objetos criados. Em alguns casos, o uso inteligente da memória torna o código novamente menos legível. Mas se você manipular gigabytes de sequências de DNA, por exemplo, a memória é um fator crucial. Novamente, considero que quanto menos código intensivo de memória, melhor, independentemente da legibilidade.

Então, sim, a legibilidade é importante para um bom código. Eu conheço o adágio de Uwe Liggis: pensar dói e computadores são baratos. Mas na minha área (genômica estatística), tempos computacionais de uma semana e uso de memória de mais de 40 Gb não são considerados anormais. Portanto, uma melhoria de duas vezes a velocidade e metade da memória vale muito mais do que um pouco mais de legibilidade.

Comentários

• Sem regras / regras sem exceção
• Deixe-me discordar da sua discordância: você diz que no seu campo a velocidade é muito importante e diz que é mais importante do que a legibilidade. Eu discordo, você deve se esforçar para usar o equilíbrio certo. Se a velocidade não for necessária, por exemplo para uma interface de alto nível, você pode preferir algo fácil de manter, se a velocidade for necessária, então eu concordo com você. Em vez de regras rígidas, é melhor usar o bom senso e você deve evitar a otimização prematura de qualquer maneira.
• @BlueTrin Por que ambos não compilam os códigos-fonte de alto desempenho e documentam o que diabos ' está acontecendo lá (ali nos comentários)?

Até onde vai para mim … Eu sei que estou escrevendo um bom código quando um colega de trabalho que trabalha em outro projeto aparece e é capaz de pular e entender o que estou fazendo sem que eu repasse cada bloco de código e mostrando o que está fazendo.
Em vez de ele dizer: “Espere um minuto, o quê ?!” Ele está dizendo: “Ah, ok, vejo o que você fez aí.”

Um bom código também não tem muitas soluções alternativas ou “hacks”. Falas quando, enquanto você está escrevendo, você também está dizendo a si mesmo: “Eu sei que esta não é uma boa maneira de fazer isso, mas terei que fazer dessa maneira por enquanto. “Vou me lembrar de melhorá-lo mais tarde …”

Existem muitos recursos no código “bom” , mas o mais importante, IMHO, são a legibilidade e a manutenção.

Seu código irá conter bugs, será provavelmente estendido e reutilizado, e deve ser re-fatorado em algum ponto – mesmo que seja você visitando novamente, as chances são de que você não terá a menor ideia do que diabos você fez em primeiro lugar, para fazer um favor a si mesmo e não coloque nenhuma barreira no caminho.

Claro, use esse algoritmo complexo-mas-super-eficiente, mas certifique-se de gastar um pouco mais de tempo documentando-o, mas caso contrário, faça seu código claro e consistente.