Você pode se perguntar o que se entende pelo título. Código é código, certo? É importante estar livre de insetos e é isso que mais? O desenvolvimento é mais do que escrever código e testar/depurar. Imagine que você tem que ler o trabalho de outra pessoa, e suponho que você já fez isso, e todas as variáveis ​​são chamadas de foo, bar, baz, var, etc, etc. E o código não é comentado nem documentado. Você provavelmente sentirá o desejo repentino de invocar deuses desconhecidos, depois irá ao pub local e afogue suas tristezas. Eles dizem que você não deve fazer aos outros o que você não deseja fazer a você, então essa parte focará as diretrizes de codificação geral, além de idéias específicas para GNU que ajudarão você a aceitar seu código. Você deveria ter lido e entendido as partes anteriores desta série, bem como resolver todos os exercícios e, de preferência, ler e escrever o máximo de código possível.

Recomendações

Antes de começar, tome nota do significado real da palavra acima. De alguma forma, não quero dizer como escrever seu código, nem estou inventando essas recomendações. Estes são o resultado de anos de trabalho de programadores experientes, e muitos não se aplicam apenas a C, mas a outros idiomas, interpretados ou compilados.

Acho que a primeira regra que quero enfatizar é: comente seu código e verifique se você comentou o suficiente, então comente mais um pouco. Isso não é benéfico para outras pessoas que lerão/usarão seu código, mas também para você. Fique convencido de que você não se lembrará do que exatamente você queria escrever depois de dois ou três meses, nem saberá o que int ghrqa34; deveria significar, se alguma coisa. Bons desenvolvedores comentam (quase) todas as linhas de seu código o mais detalhadamente possível, e o retorno é mais do que você pode perceber a princípio, apesar do aumento do tempo necessário para escrever o programa. Outra vantagem é que, ao comentar, porque é assim que nosso cérebro funciona, o que quer que desejásse. Ou por quê.

O analisador C realmente não se importa com o quanto o seu código é ordenado. Isso significa que você pode escrever um programa típico de "Olá, mundo" como este, e ainda compilaria:

#include int main () printf ("Olá, mundo!"); retornar 0; 

Parece muito mais legível da maneira como escrevemos pela primeira vez, não? As regras gerais sobre a formatação são: uma instrução por linha, escolha a largura da sua guia e seja consistente com ela, mas verifique se ela está em conformidade com as diretrizes do projeto, se você estiver trabalhando em um, também faça uso liberal de linhas em branco, para delimitando várias partes do programa, juntamente com comentários e, finalmente, embora isso não seja necessariamente codificando o estilo, antes de começar a codificar seriamente, encontre um editor que você gosta e aprenda a usá-lo bem. Em breve, publicaremos um artigo sobre editores, mas até então o Google o ajudará com algumas alternativas. Se você ouvir pessoas em fóruns, listas de discussão, etc. dizendo “Editor X é uma merda, editor y ftw!", ignore-os. Este é um assunto muito subjetivo e o que é bom para mim pode não ser tão bom para você, então pelo menos tente alguns dos editores disponíveis para o Linux por alguns dias cada um antes mesmo de começar a tentar criar alguma opinião.

Ser consistente na nomeação variável. Verifique também que os nomes se encaixam com os outros, para que haja harmonia em todo o programa. Isso se aplica mesmo que você seja o único autor do software, será mais fácil manter mais tarde. Crie uma lista de prefixos e sufixos usados ​​(e.g. max, min, obtenha, set, é, cnt) e vá com eles, a menos que seja perguntado o contrário. Consistência é a palavra -chave aqui.

Diretrizes específicas para GNU

O que se segue é um resumo dos padrões de codificação da GNU, porque sabemos que você não gosta de ler essas coisas. Então, se você está escrevendo código que gostaria de se encaixar no ecossistema GNU, este é o documento para ler. Mesmo se não o fizer, ainda é uma boa leitura sobre como escrever código adequado.

Este documento sempre vale a pena ler na íntegra se você estiver criando ou mantendo o software GNU, mas encontrará as partes mais importantes abaixo. Uma primeira questão que vale a pena mencionar é como lidar com protótipos de função. Volte para a parte que lida com isso se você tiver algum problema. A idéia é “Se você tiver suas próprias funções, use uma declaração de protótipo antes de main (), defina a função quando necessário.”Aqui está um exemplo:

#include int func (int, int) int main () […] int func (int x, int z) […] 

Use o recuo adequado e constante. Isso não pode ser enfatizado o suficiente. Programadores experientes com anos e anos de código atrás vão levar isso muito mal quando você enviar código com indentação inadequada. No nosso caso, a melhor maneira de se acostumar com a forma como isso é usando o GNU Emacs (embora isso não seja de nenhuma forma para lhe dizer que “GNU Emacs é bom para você, use -o.”, Como somos proponentes de livre arbítrio e escolha), onde o comportamento padrão do código C é o indentação definido em dois espaços e aparelhos em uma linha para si mesmos. O que nos leva a outra questão importante. Algumas pessoas usam aparelhos como este:

enquanto (var == 1) code… 

… Enquanto outros, incluindo o povo da GNU, fazem assim:

enquanto (var == 1) code…

Obviamente, isso também se aplica a expressões condicionais, funções e todas as ocasiões em que você precisa usar aparelhos no código C. Tanto quanto notado, essa escolha é algo muito específico da GNU, e quanto disso você respeita depende apenas do seu gosto e da posição sobre o assunto.

Nossa próxima edição é técnica, e uma promessa que eu tive que cumprir: o problema do malloc (). Além de escrever mensagens de erro pertinentes e significativas, ao contrário das que vimos em outros sistemas operacionais, verifique se Malloc () e amigos sempre retornam zero. Estes são problemas muito sérios, e você terá algumas palavras lição sobre MALLOC () e quando usá -lo. Até agora você sabe o que alocar a memória automaticamente ou estaticamente é. Mas esses métodos não cobrem todas as bases. Quando você precisa alocar memória e ter mais controle sobre a operação, há Malloc () e amigos, para alocação dinâmica. Seu objetivo é alocar a memória disponível do pilha, Em seguida, o programa usa a memória por meio de um ponteiro que Malloc () retorna, então a memória deve ser livre () D. E "Must" é ser escrito com capitais em letras de 2 pés com uma cor vermelha em chamas. É isso com isso com Malloc (), e as razões já foram expostas no início da parte anterior.

Você deve usar uma interface consistente em todos os seus programas de linha de comando. Se você já é um usuário experiente do GNU/Linux, notou que quase todos os programas têm -version e -Help, além de, por exemplo, -v para verbose, se esse for o caso. Não entraremos em tudo isso aqui; Pegue uma cópia dos padrões de codificação GNU, você precisará de qualquer maneira.

Embora eu pessoalmente tendam a ignorar isso, e para muitos é um problema menor, ele melhorará a legibilidade do seu código, porque, novamente, é assim que nosso cérebro funciona. A idéia é: quando você estiver em dúvida sobre o uso de espaços, use -os. Por exemplo:

int func (var1, var2); int func (var1, var2);

Há alguns que dizem que você não pode evitar o aninhado se. Há outros que dizem “Por que evitar se as sedas aninhadas?”E ainda há outros que simplesmente não usam ses aninhados. Você criará sua própria opinião sobre isso com o passar do tempo e as linhas de código que você escreve aumenta. A idéia é que, se você os usar, torne-os tão legíveis quanto humanamente possível, pois eles facilmente podem levar a um código quase-saghetti, difícil de ler e manter. E novamente, use comentários.

O padrão de codificação GNU diz que é bom ter seu código tão portátil quanto possível, "mas não paramount". Em termos de hardware portátil? Isso depende do objetivo do programa e de quais máquinas você tem à sua disposição. Estamos nos referindo mais ao lado do software, ou seja, portabilidade entre sistemas UNIX, código aberto ou não. Evite ifdefs, se puder, evite suposições em relação aos locais de arquivo (e.g. Solaris instala software de terceiros em /opt, enquanto o BSD e o GNU /Linux não) e geralmente buscam código limpo. Falando em suposições, nem sequer assuma que um byte é de oito bits ou que o espaço de endereço de uma CPU deve ser um número par.

Documentar seu código, na forma de páginas manuais e leitura bem escrita e assim por diante, é outro aspecto primordial do desenvolvimento de software. Sim, é uma tarefa tediosa, mas se você não tem um escritor de documentação em sua equipe, é sua responsabilidade fazê -lo, pois todo bom programador faz seu trabalho de A a Z.

Conclusão

Da próxima vez, continuaremos de onde paramos aqui: passando da ideia para um programa completo, com makefiles, documentação, ciclos de liberação e todas as coisas divertidas. O único exercício que tenho para você é desviar os padrões de codificação GNU e modificar seu código como conforme em conformidade. E prepare -se, da próxima vez que é divertido!

Aqui está o que você pode esperar a seguir:

• EU. C Desenvolvimento no Linux - Introdução
• Ii. Comparação entre C e outras linguagens de programação
• Iii. Tipos, operadores, variáveis
• 4. Controle de fluxo
• V. Funções
• Vi. Ponteiros e matrizes
• Vii. Estruturas
• Viii. E/S básico
• Ix. Estilo de codificação e recomendações
• X. Construindo um programa
• XI. Embalagem para Debian e Fedora
• Xii. Obtendo um pacote nos repositórios oficiais do Debian

Tutoriais do Linux relacionados:

• Tutorial de depuração do GDB para iniciantes
• Instale Arch Linux na estação de trabalho VMware
• Uma introdução à automação, ferramentas e técnicas do Linux
• Coisas para instalar no Ubuntu 20.04
• Expressões regulares do Python com exemplos
• Como construir um aplicativo Tknter usando um objeto orientado…
• Bash Regex avançado com exemplos
• Bash Loops com exemplos
• Coisas para fazer depois de instalar o Ubuntu 20.04 fossa focal linux
• Loops aninhados em scripts de basquete