Esta seção também é realmente um pré-requisito para a codificação, como McConnell aponta: “Estabelecer convenções de programação antes de começar a programação. É quase impossível alterar o código para os igualar mais tarde.”

conforme listado perto do final das Convenções de codificação, existem diferentes convenções para diferentes linguagens de programação, por isso pode ser contraproducente aplicar as mesmas convenções em diferentes linguagens. É importante notar que não existe uma convenção de codificação específica para qualquer linguagem de programação. Cada organização tem um padrão de codificação personalizado para cada tipo de projeto de software. É, portanto, imperativo que o programador escolha ou forme um conjunto particular de Diretrizes de codificação antes do início do projeto de software. Algumas convenções de codificação são genéricas que podem não se aplicar para cada projeto de software escrito com uma linguagem de programação particular.

O uso de Convenções de codificação é particularmente importante quando um projeto envolve mais de um programador (tem havido projetos com milhares de programadores). É muito mais fácil para um programador ler o código escrito por outra pessoa se todo o código segue as mesmas convenções.

para alguns exemplos de más Convenções de codificação, Roedy Green fornece um artigo longo (tongue-in-cheek) sobre como produzir código não possível.

CommentingEdit

devido a restrições de tempo ou programadores entusiastas que querem resultados imediatos para o seu código, comentando o código muitas vezes toma um assento traseiro. Programadores que trabalham em equipe acharam melhor deixar os comentários para trás já que a codificação geralmente segue ciclos, ou mais de uma pessoa pode trabalhar em um módulo particular. No entanto, alguns comentários podem diminuir o custo da transferência de conhecimento entre desenvolvedores que trabalham no mesmo módulo.

nos primeiros dias da computação, uma prática de comentário foi deixar uma breve descrição do seguinte::

1. Nome do módulo
2. Finalidade do Módulo
3. Descrição do Módulo
4. Autor Original
5. Modificações
6. Autores que modificou o código com uma descrição sobre o motivo foi modificado.

a” descrição do módulo ” deve ser tão breve quanto possível, mas sem sacrificar a clareza e a abrangência.

no entanto, os dois últimos itens foram amplamente obsoletos pelo advento de sistemas de controle de revisão. Modificações e sua autoria podem ser rastreadas de forma confiável usando tais ferramentas ao invés de usar comentários.

também, se a lógica complicada está sendo usada, é uma boa prática deixar um comentário “bloco” perto dessa parte para que outro programador possa entender exatamente o que está acontecendo.

O teste de unidade pode ser outra forma de mostrar como o código deve ser usado.

Naming conventionsEdit

o uso de Convenções de nomenclatura adequada é considerado uma boa prática. Às vezes os programadores tendem a usar X1, Y1, etc. como variáveis e esquecer de substituí-las por significativas, causando confusão.

geralmente é considerado boa prática usar nomes descritivos.

exemplo: uma variável para tomar em peso como um parâmetro para um caminhão pode ser chamado de TrkWeight ou TruckWeightKilograms, com TruckWeightKilograms sendo o preferível, uma vez que é instantaneamente reconhecível. Veja CamelCase naming of variables.

mantenha o código simpleEdit

o código que um programador escreve deve ser simples. Lógica complicada para alcançar uma coisa simples deve ser mantida ao mínimo, uma vez que o código pode ser modificado por outro programador no futuro. A lógica implementada por um programador pode não fazer sentido para outro. Então, mantenha sempre o código o mais simples possível.

Por exemplo, considere estas linhas equivalentes de código em C:

if (hours < 24 && minutes < 60 && seconds < 60){ return true;}else{ return false;}

e

if (hours < 24 && minutes < 60 && seconds < 60) return true;else return false;

e

return hours < 24 && minutes < 60 && seconds < 60;

A 1ª abordagem, que é muito mais comumente usado, é consideravelmente maior do que o 3º. Em particular, consome 5 vezes mais espaço vertical de tela (linhas), e 97 caracteres versus 52 (embora ferramentas de edição podem reduzir a diferença na digitação real). É discutível, no entanto, que é “mais simples”. O primeiro tem um If/then else explícito, com um valor de retorno explícito obviamente conectado com cada um; mesmo um programador novato não deve ter dificuldade em entendê-lo. O segundo simplesmente descarta os suspensórios, cortando o tamanho “vertical” ao meio com pouca mudança na complexidade conceitual. Na maioria das línguas, as declarações “return” também poderiam ser anexadas às linhas anteriores, trazendo o tamanho “vertical” para apenas mais uma linha que a terceira forma.

A terceira forma obviamente minimiza o tamanho, mas pode aumentar a complexidade: Ele deixa os valores” verdadeiro “e” falso “implícitos, e intermixa as noções de” condição “e”valor de retorno”. É provável que seja óbvio para a maioria dos programadores, mas um novato pode não entender imediatamente que o resultado da avaliação de uma condição é realmente um valor (do tipo booleano, ou seu equivalente em qualquer língua), e assim pode ser manipulado ou devolvido. Em exemplos mais realistas, a terceira forma poderia ter problemas devido à precedência do operador, talvez retornando um tipo inesperado, onde os formulários anteriores em algumas línguas relatariam um erro. Assim, “simplicidade” não é apenas uma questão de comprimento, mas de estrutura lógica e conceitual; tornar o código mais curto pode torná-lo menos ou mais complexo.

para programas de longa duração usando alternativas verbosas pode contribuir para o inchaço.

a compacidade pode permitir que os codificadores vejam mais código por página, reduzindo gestos de deslocamento e teclas. Dado o número de vezes que o código pode ser visto no processo de escrita e manutenção, pode ser uma economia significativa nas teclas dos programadores na vida do Código. Isso pode não parecer significativa para um aluno que primeiro aprender a programar, mas, quando a produção e a manutenção de grandes programas de redução de quantas linhas de código existem permite mais o código para caber na tela, menor simplificação do código podem melhorar a produtividade, e também diminuir o dedo, pulso e a tensão do olho, que são comuns, de questões médicas sofrido pela produção de programadores e operadores de informações.

terser coding speeds compilation very slightly, as less symbols need to be processed. Além disso, a terceira abordagem pode permitir que Linhas de código semelhantes sejam mais facilmente comparadas, particularmente quando muitas dessas construções podem aparecer em uma tela ao mesmo tempo.

finalmente, muito terses layouts podem utilizar melhor displays modernos de computador de tela larga, dependendo da disposição e configuração do monitor. No passado, as telas eram limitadas a 40 ou 80 caracteres (tais limites se originaram muito antes: manuscritos, livros impressos e até pergaminhos, têm usado por milênios linhas bastante curtas (veja por exemplo a Bíblia de Gutenberg). Telas modernas podem facilmente exibir 200 ou mais caracteres, permitindo linhas extremamente longas. A maioria dos estilos e padrões de codificação modernos não ocupam toda essa largura. Assim, se usar uma janela tão larga como a tela, uma grande quantidade de espaço disponível é desperdiçada. Por outro lado, com várias janelas, ou usando uma IDE ou outra ferramenta com várias informações em painéis laterais, a largura disponível para o código está na faixa familiar dos sistemas anteriores.também vale a pena notar que o sistema visual humano é muito afectado pelo comprimento da linha.; linhas muito longas aumentam ligeiramente a velocidade de leitura, mas reduzem a compreensão e adicionam erros de rastreamento de olhos. Alguns estudos sugerem que linhas mais longas se saem melhor online do que na impressão , mas isso ainda vai até cerca de 10 polegadas, e principalmente para a velocidade bruta de leitura em prosa.

PortabilityEdit

Program code should not contain “hard-coded” (literal) values refering to environmental parameters, such as absolute file paths, file names, user names, host names, IP address, URLs, UDP/TCP ports. Caso contrário, o aplicativo não será executado em um host que tem um projeto diferente do previsto. Um programador cuidadoso pode parametrizar tais variáveis e configurá-las para o ambiente de hospedagem fora da aplicação propriamente dita (por exemplo, em arquivos de propriedade, em um servidor de aplicação, ou mesmo em um banco de dados). Compare o mantra de um”ponto único de definição” (SPOD).

Como uma extensão, recursos como arquivos XML também devem conter variáveis ao invés de valores literais, caso contrário a aplicação não será portátil para outro ambiente sem editar os arquivos XML. Por exemplo, com aplicações J2EE rodando em um servidor de aplicações, tais parâmetros ambientais podem ser definidos no escopo da JVM e a aplicação deve obter os valores a partir daí.

ScalabilityEdit

Design code with scalability as a design goal because very often in software projects, new features are always added to a project which because bigger. Portanto, a facilidade de adicionar novas características a uma base de código de software torna-se um método inestimável na escrita de software

ReusabilityEdit

re-uso é um objetivo de design muito importante no desenvolvimento de software. A reutilização reduz os custos de desenvolvimento e também reduz o tempo de desenvolvimento se os componentes ou módulos que são reutilizados já forem testados. Muitas vezes, projetos de software começam com uma linha de base existente que contém o projeto, em sua versão anterior e, dependendo do projeto, muitos dos existentes módulos de software e componentes são reutilizados, o que reduz o desenvolvimento e testes, por conseguinte, aumentando a probabilidade de entrega de um projeto de software na programação.orientações para a construção em briefEdit

uma visão geral de todos os aspectos acima: