Estilo de programação - Programming style
O estilo de programação , também conhecido como estilo de código , é um conjunto de regras ou diretrizes usadas ao escrever o código-fonte de um programa de computador . Costuma-se afirmar que seguir um determinado estilo de programação ajudará os programadores a ler e compreender o código-fonte em conformidade com o estilo e a evitar a introdução de erros.
Um trabalho clássico sobre o assunto foi The Elements of Programming Style , escrito na década de 1970 e ilustrado com exemplos das linguagens Fortran e PL / I predominantes na época.
O estilo de programação usado em um programa específico pode ser derivado das convenções de codificação de uma empresa ou outra organização de computação, bem como das preferências do autor do código. Os estilos de programação são freqüentemente projetados para uma linguagem de programação específica (ou família de linguagens): o estilo considerado bom no código-fonte C pode não ser apropriado para o código-fonte BASIC , etc. No entanto, algumas regras são comumente aplicadas a muitas linguagens.
Elementos de bom estilo
O bom estilo é uma questão subjetiva e difícil de definir. No entanto, existem vários elementos comuns a um grande número de estilos de programação. Os problemas normalmente considerados como parte do estilo de programação incluem o layout do código-fonte, incluindo indentação ; o uso de espaço em branco em torno de operadores e palavras-chave; a capitalização ou não de palavras-chave e nomes de variáveis; o estilo e a grafia dos identificadores definidos pelo usuário, como nomes de funções, procedimentos e variáveis; e o uso e estilo dos comentários .
Aparência do código
Os estilos de programação geralmente lidam com a aparência visual do código-fonte, com o objetivo de legibilidade. Há muito tempo há software disponível que formata o código-fonte automaticamente, deixando os codificadores se concentrarem em nomenclatura, lógica e técnicas superiores. Como um ponto prático, usar um computador para formatar o código-fonte economiza tempo e é possível aplicar os padrões de toda a empresa sem debates .
Recuo
Os estilos de recuo auxiliam na identificação do fluxo de controle e blocos de código. Em algumas linguagens de programação, o recuo é usado para delimitar blocos lógicos de código; o recuo correto nesses casos é mais do que uma questão de estilo. Em outras linguagens, o recuo e o espaço em branco não afetam a função, embora o recuo lógico e consistente torne o código mais legível. Comparar:
if (hours < 24 && minutes < 60 && seconds < 60) {
return true;
} else {
return false;
}
ou
if (hours < 24 && minutes < 60 && seconds < 60)
{
return true;
}
else
{
return false;
}
com algo como
if ( hours < 24
&& minutes < 60
&& seconds < 60
)
{return true
;} else
{return false
;}
Os primeiros dois exemplos são provavelmente muito mais fáceis de ler porque são recuados de uma maneira estabelecida (um estilo de "parágrafo suspenso"). Este estilo de recuo é especialmente útil ao lidar com várias construções aninhadas.
ModuLiq
O ModuLiq Zero Indentation Style agrupa com retornos de carro em vez de indentações. Compare todos os itens acima com:
if (hours < 24 && minutes < 60 && seconds < 60)
return true;
else
return false;
Lua
Lua não usa as chaves ou parênteses tradicionais . As instruções if / else exigem apenas que a expressão seja seguida por then, e feche a instrução if / else com end.
if hours < 24 and minutes < 60 and seconds < 60 then
return true
else
return false
end
O recuo é opcional. and, or, notSão utilizados em entre verdadeiras declarações falsas /.
São declarações verdadeiras / falsas, como
print(not true)
significaria falso.
Pitão
Python usa indentação para indicar estruturas de controle, portanto, é necessária uma indentação correta . Ao fazer isso, a necessidade de colchetes com chaves (ou seja, {e }) é eliminada. Por outro lado, copiar e colar o código Python pode causar problemas, porque o nível de indentação do código colado pode não ser o mesmo que o nível de indentação da linha atual. Essa reformatação pode ser entediante de fazer manualmente, mas alguns editores de texto e IDEs têm recursos para fazer isso automaticamente. Também há problemas quando o código Python se torna inutilizável quando postado em um fórum ou página da web que remove os espaços em branco, embora esse problema possa ser evitado onde é possível incluir o código em tags de preservação de espaço em branco, como "<pre> .. . </pre> "(para HTML )," [code] "..." [/ code] "(para bbcode ), etc.
if hours < 24 and minutes < 60 and seconds < 60:
return True
else:
return False
Observe que o Python não usa chaves, mas dois pontos regulares (por exemplo else:).
Muitos programadores de Python tendem a seguir um guia de estilo comumente aceito, conhecido como PEP8. Existem ferramentas projetadas para automatizar a conformidade PEP8.
Haskell
Haskell da mesma forma tem a regra de off-side , ou seja, tem uma sintaxe de duas dimensões onde a indentação é significativa para definir blocos (embora, uma sintaxe alternativa use chaves e ponto-e-vírgulas). Haskell é uma linguagem declarativa, existem declarações, mas declarações dentro de um script Haskell. Exemplo:
let c_1 = 1
c_2 = 2
in
f x y = c_1 * x + c_2 * y
pode ser escrito em uma linha como:
let {c_1=1;c_2=2} in f x y = c_1 * x + c_2 * y
Haskell encoraja o uso de programação letrada , onde o texto estendido explica a gênese do código. Em scripts Haskell letrados (nomeados com a lhsextensão), tudo é um comentário, exceto os blocos marcados como código. O programa pode ser escrito em LaTeX , neste caso o codeambiente marca o que é código. Além disso, cada parágrafo de código ativo pode ser marcado precedendo-o e terminando com uma linha em branco e iniciando cada linha de código com um sinal de maior que e um espaço. Aqui está um exemplo usando marcação LaTeX:
The function \verb+isValidDate+ test if date is valid
\begin{code}
isValidDate :: Date -> Bool
isValidDate date = hh>=0 && mm>=0 && ss>=0
&& hh<24 && mm<60 && ss<60
where (hh,mm,ss) = fromDate date
\end{code}
observe that in this case the overloaded function is \verb+fromDate :: Date -> (Int,Int,Int)+.
E um exemplo usando texto simples:
The function isValidDate test if date is valid
> isValidDate :: Date -> Bool
> isValidDate date = hh>=0 && mm>=0 && ss>=0
> && hh<24 && mm<60 && ss<60
> where (hh,mm,ss) = fromDate date
observe that in this case the overloaded function is fromDate :: Date -> (Int,Int,Int).
Alinhamento vertical
Muitas vezes é útil alinhar elementos semelhantes verticalmente, para tornar mais óbvios os erros gerados por erros de digitação. Comparar:
$search = array('a', 'b', 'c', 'd', 'e');
$replacement = array('foo', 'bar', 'baz', 'quux');
// Another example:
$value = 0;
$anothervalue = 1;
$yetanothervalue = 2;
com:
$search = array('a', 'b', 'c', 'd', 'e');
$replacement = array('foo', 'bar', 'baz', 'quux');
// Another example:
$value = 0;
$anothervalue = 1;
$yetanothervalue = 2;
O último exemplo deixa duas coisas intuitivamente claras que não estavam claras no primeiro:
- os termos de busca e substituição estão relacionados e correspondem: não são variáveis discretas;
- há mais um termo de pesquisa do que termos de substituição. Se for um bug, agora é mais provável que seja detectado.
No entanto, observe que existem argumentos contra o alinhamento vertical:
- Dependências falsas entre linhas ; a formatação tabular cria dependências entre linhas. Por exemplo, se um identificador com um nome longo for adicionado a um layout tabular, pode ser necessário aumentar a largura da coluna para acomodá-lo. Isso força uma mudança maior no código-fonte do que o necessário, e a mudança essencial pode ser perdida no ruído. Isso é prejudicial para o controle de revisão, onde a inspeção das diferenças entre as versões é essencial.
- Fragilidade ; se um programador não formata ordenadamente a tabela ao fazer uma mudança, talvez legitimamente com o ponto anterior em mente, o resultado se torna uma bagunça que se deteriora com novas mudanças. Operações de refatoração simples, como pesquisar e substituir, também podem interromper a formatação.
- Resistência à modificação ; a formatação tabular requer mais esforço de manutenção. Isso pode impedir o programador de fazer uma mudança benéfica, como adicionar, corrigir ou melhorar o nome de um identificador, porque bagunçará a formatação.
- Dependência de fonte mono-espaçada ; a formatação tabular assume que o editor usa uma fonte de largura fixa. Muitos editores de código modernos suportam fontes proporcionais e o programador pode preferir usar uma fonte proporcional para facilitar a leitura.
- Dependência de ferramenta ; parte do esforço para manter o alinhamento pode ser aliviado por ferramentas (por exemplo, um editor de código-fonte que suporte tabulações elásticas ), embora isso crie uma dependência de tais ferramentas.
Por exemplo, se uma operação de refatoração simples for realizada no código acima, renomeando as variáveis "$ replacement" para "$ r" e "$ anothervalue" para "$ a", o código resultante terá a seguinte aparência:
$search = array('a', 'b', 'c', 'd', 'e');
$r = array('foo', 'bar', 'baz', 'quux');
// Another example:
$value = 0;
$a = 1;
$yetanothervalue = 2;
A formatação sequencial original ainda ficará boa após essa mudança:
$search = array('a', 'b', 'c', 'd', 'e');
$r = array('foo', 'bar', 'baz', 'quux');
// Another example:
$value = 0;
$a = 1;
$yetanothervalue = 2;
Espaços
Nas situações em que algum espaço em branco é necessário, as gramáticas da maioria das linguagens de formato livre não se preocupam com a quantidade que aparece. O estilo relacionado ao espaço em branco é comumente usado para melhorar a legibilidade . Atualmente não há fatos concretos conhecidos (conclusões de estudos) sobre quais estilos de espaço em branco têm a melhor legibilidade.
Por exemplo, compare os seguintes exemplos sintaticamente equivalentes de código C:
int i;
for(i=0;i<10;++i){
printf("%d",i*i+i);
}
versus
int i;
for (i = 0; i < 10; ++i) {
printf("%d", i * i + i);
}
Abas
O uso de guias para criar espaço em branco apresenta problemas específicos quando não é tomado cuidado suficiente, pois a localização do ponto de tabulação pode ser diferente dependendo das ferramentas sendo usadas e até mesmo das preferências do usuário.
Por exemplo, um programador prefere paradas de tabulação de quatro e tem seu conjunto de ferramentas configurado dessa forma e usa-os para formatar seu código.
int ix; // Index to scan array
long sum; // Accumulator for sum
Outro programador prefere paradas de tabulação de oito e seu conjunto de ferramentas é configurado dessa forma. Quando outra pessoa examina o código da pessoa original, ela pode achar difícil de ler.
int ix; // Index to scan array
long sum; // Accumulator for sum
Uma solução amplamente usada para esse problema pode envolver a proibição do uso de tabulações para alinhamento ou regras sobre como as paradas de tabulação devem ser definidas. Observe que as guias funcionam bem, desde que sejam usadas de forma consistente, restritas ao recuo lógico e não usadas para alinhamento:
class MyClass {
int foobar(
int qux, // first parameter
int quux); // second parameter
int foobar2(
int qux, // first parameter
int quux, // second parameter
int quuux); // third parameter
};