ti-enxame.com

Quais partes de seu padrão de codificação contribuem para o código de qualidade?

Em resposta a esta pergunta , pergunto: Quais são as melhores partes do seu padrão de codificação?

Quais são as melhores práticas que ajudam com a qualidade do código, confiabilidade, facilidade de manutenção, legibilidade, etc.

Inclua o idioma, o item do padrão e o motivo pelo qual seu código foi aprimorado.

31
AShelly

Todos os idiomas: escreva um código legível em vez de comentários

  • Um comentário seguido por um bloco de código pode ser substituído por um método que declara a intenção tão bem quanto o comentário e torna o código mais modular e reutilizável.
  • Isso faz com que a refatoração aconteça com mais frequência.
  • Isso nos ajuda a escrever simples, legívelcódigo limpo . É uma alegria trabalhar com códigos legíveis.
  • Tende a tornar os métodos curtos e agradáveis.
  • Isso evita que os comentários fiquem fora de sincronia com o código
  • Ele desafia você a reescrever o código comentado que é difícil de entender.

Compare isto:

public void update() {
  // Fetch the data from somewhere
  lots of lines of;
     code;
     for;
       fetching;
     data;
  from somewhere;
  // Sort the data
  more lines of;
      code;
         which sorts;
         stuff;
      around;
  a bit and then;
  // Update the database
  lines of code;
      which uses;
         some lib;
         to update;
            using iteration;
            and logic; 
      the database;
  done;
}

Com esta versão, onde os comentários são substituídos por chamadas de função:

public void update() {
    data = fetchData();
    sorted = sortResults(data);
    updateDatabase(sorted);
}
23
Martin Wickman

Apenas uma classe pública deve ser colocada em cada arquivo, não mais.

12
Maniero

Qualquer idioma:

so adequado e consistente de espaços em branco, vertical e horizontal, amplamente melhora a capacidade do código de ser rapidamente lido também conforme lido em um ritmo normal. Não vou discutir sobre tabulações versus espaços, contanto que seu uso seja consistente, mas a indentação adequada e o uso criterioso de linhas em branco e espaços ao redor dos operadores são absolutamente necessários.

Relacionado: manter os comprimentos de linha em um limite razoável, como 80 colunas, tem benefícios demonstráveis: sem agrupamento estranho em consoles, sem necessidade de rolar e a capacidade de visualizar vários arquivos lado a lado em um monitor amplo, sem mencionar que tende a ajudam a encorajar a refatoração de código profundamente aninhado e expressões run-on.

9
Jon Purdy

C #: estilos de nomenclatura diferentes para diferentes tipos de nomes.

Por exemplo:

public class ClassNamesArePascalCase{
    public int FieldsArePascalCase;
    private int _privateFieldsAreUnderscoredCamelCase
    public const int CONSTANTS_ARE_CAPITAL = 3;

    public void MethodNamesArePascalCase( string parametersAreCamel ){
        int localVariablesAreCamel;
    }
}

Não importa muito quais padrões você usa para quais tipos de nome, contanto que seja consistente entre aquele tipo (por exemplo, todas as constantes são maiúsculas), consistente dentro do projeto e diferentes umas das outras. A vantagem aqui é que posso dizer à primeira vista que _someVar é um campo privado sem ter que procurá-lo.

7
Fishtoaster

C : As 'funções' da macro de pré-processador devem estar em letras maiúsculas

Exemplo: #define CUBE(x) ((x)*(x)*(x))

Motivo: ao escanear o código, as macros se destacam das funções regulares e alertam que pode haver efeitos colaterais que uma chamada de função normal nunca teria, como alterar o valor do argumento "input" ou avaliá-lo 3 vezes.

6
AShelly

Nunca use a notação húngara. Em linguagens de tipos estáticos é desnecessário, e em linguagens de tipagem dinâmica é quase sempre prejudicial. Além disso, a notação húngara é a arma nuclear tática das técnicas de ofuscação de código-fonte .

5
pillmuncher

Em Java.

  • Chame o formatador de código-fonte do Eclipse automaticamente sempre que um arquivo for salvo.

Isso significa que as mudanças no código-fonte são registradas no primeiro commit depois, ao invés de algum tempo depois quando uma reformatação é feita. Isso é bom ao fazer investigações de "quando isso foi alterado".

5
user1249

[~ # ~] consistência [~ # ~]

Não estou incomodado com nenhuma convenção de nomenclatura ou codificação em particular (embora, obviamente, eu tenha preferências), desde que a base de código à qual elas se apliquem use essas convenções consistentemente.

Tenho passado por Clean Code ultimamente, e acho que me ajudou um pouco (embora eu não concorde/use tudo isso).

3
Steven Evers

C #: Use o método de extração em vez de comentários

Se acharmos que precisamos adicionar um comentário a um bloco de código para explicar o que ele está fazendo, em vez disso, extrairíamos esse código em um novo método com um nome descritivo.

Isso torna o código mais legível e modular e reduz o número de comentários (desatualizados) flutuando.

3
David Anderson

Formatação - especialmente recuo! Estou usando Delphi e a primeira coisa a fazer quando obtenho o código não formatado para o meu uso, eu o reformato. O formatador embutido no Delphi serve como um dos fetaures mais usados ​​nesses casos.

3
Uwe Raabe

SQL

Usamos uma convenção de nomenclatura para nossos elementos de banco de dados.

  • tblTableNames
  • viewViewName
  • spAdminProcedureName
  • spProcedureName

Muitas vezes, criamos um widget para um cliente e, 3 meses depois, revendemos esse widget para outro cliente. Eventualmente, surgiram conflitos de nomenclatura e tivemos que recodificar um widget.

Por exemplo:
Widget de comunicado à imprensa

  • tblContent
  • tblCategories
  • tblImages

Widget da Galeria de Fotos

  • tblPhotos
  • tblCategories

Se o cliente-A já tinha o widget de comunicado à imprensa e agora queria o widget Galeria de fotos, tivemos um conflito de nomenclatura com tblCategories. Não podíamos apenas criar um script para os elementos da Galeria de fotos e executá-los no banco de dados da Empresa-A. Argh!

Então, começamos a anexar um "widget" referências aos nossos elementos SQL:

  • tblPG_Photos
  • tblPG_Categories
  • tblPR_Content
  • tblPR_Categories
  • tblPR_Images
  • spPG_Proc1
  • spPG_Proc2
  • spPG_Proc3
  • spPR_Proc1
  • spPR_Proc2
  • spPR_Proc3

Isso manteve as coisas bem organizadas e nos ajudou a ser mais lucrativos no longo prazo.

1
Michael Riley - AKA Gunny

C # e Java:

  • Certificando-se de que o registro de seções críticas está definido corretamente (log4 *).
  • Manter métodos e classes pequenos (Responsabilidade Única).
  • TDD ou escrever testes de unidade para seções importantes da lógica de negócios (jUnit ou nUnit).
1
Watson

Para herança C++. Apontando isso,

  • Herança múltipla: Só muito raramente a herança de implementação múltipla é realmente útil.

Para outras coisas.

  • Macros de pré-processador: Tenha muito cuidado com macros. Prefira funções embutidas, enums e variáveis ​​const a macros.
  • Ponteiros inteligentes: Se você realmente precisa da semântica de ponteiros, scoped_ptr é ótimo. Você só deve usar std :: tr1 :: shared_ptr sob condições muito específicas, como quando os objetos precisam ser mantidos por contêineres STL. Você nunca deve usar auto_ptr.
1
grokus

Em Python, use apenas a biblioteca padrão e, se não puder evitar o uso de outra biblioteca, explique o motivo em algum lugar. Algum dia, essa lib pode precisar ser substituída e seria bom saber por onde começar.

Além disso, mantenha-o muito simples.

0
Christopher Mahan

Eu escrevi sobre isso no meu blog outro dia.

Convenções e padrões de codificação C #

http://www.codehustle.com/2011/06/c-coding-conventions-and-standards.html

Acho que, no que diz respeito às convenções de codificação, o principal fator que contribui para a confiabilidade, facilidade de manutenção e legibilidade do código são as convenções de nomenclatura. O resto das coisas é bastante normal.

Não existe uma maneira "certa" ou "errada" de usar as convenções de nomenclatura. A chave é consistência. Por exemplo, eu sempre uso camelCasing para parâmetros e variáveis ​​locais, uso camelCasing prefixado com um sublinhado para membros de campo privado/protegido e uso PascalCasing para nomes de classes, propriedades, eventos, funções, etc.

Eu geralmente evito a notação húngara também por uma questão de legibilidade, mas acho que em alguns cenários é útil (eu geralmente uso a notação húngara para tipos de GUI).

Um efeito colateral de se ater às convenções é que é fácil controlar o tipo de identificador que você está procurando ao ler o código. Por exemplo, sempre posso confiar no fato de que as propriedades utilizam PascalCasing enquanto as variáveis ​​locais não, o que me salva de ter que fazer a varredura para trás e encontrar a definição de um identificador ao ler o código.

Fazer com que sua equipe siga as mesmas convenções e padrões de codificação pode ajudar a tornar seu software mais legível e uniforme, mantendo as coisas consistentes e limpas. Isso facilita a manutenção, permitindo que os membros de sua equipe sejam capazes de ler e compreender o código escrito por colegas de trabalho mais rapidamente, sem ter que executar mentalmente um filtro de plano de fundo para interpretar as diferenças de layout e estilo, etc. Também promove as melhores práticas e pode contribuir para mantendo suas APIs consistentes também.

Se o seu código for limpo, consistente e fácil de ler, ele se tornará mais sustentável e menos sujeito a erros.

0
John Connelly

Método de nomenclatura único, não importa no idioma. Por exemplo .. G = Global, L = Local, P = Parâmetro. Agora, quando você tem uma variável como G_strFoo, sei que sua definição pode estar localizada no meu arquivo global. Ajuda a acompanhar todas as variáveis ​​em meus programas.

0
Jeremy