Stoa :: C/C++ :: Fórum

Autor Introdução à programação em C/C++ – parte 3

Introdução à programação em C/C++ - parte 3

 

Retomemos o exemplo da parte 1 desta introdução:

 

1: #include<stdio.h>

2:

3: int main() {

4:     printf("\nOla, mundo da programacao!!!\n");

5:     return 0; }

6:

 

Na parte 2 da introdução vimos que a primeira linha deste código fonte refere-se à inserção, nesse ponto do programa, de um outro arquivo, o “stdio.h”. Vimos também que essa inserção corresponde à funcionalidade de uma biblioteca de funções. Caso você queira informações sobre esse tópico, leia a parte 2 desta introdução.

 

A segunda linha do código fonte do programa exemplificado acima está em branco; isso significa que nenhuma instrução será executada pelo computador, que ficará ocioso por um tempinho? Na verdade, não - o compilador C, como por exemplo o GCC, irá ignorar linhas em branco. Isto é, durante a tradução do código fonte para o arquivo executável, essa linha em branco será suprimida, e, para o computador, será como se ela não existisse.

 

Entretanto, essa linha em branco é uma das muitas coisas que um programador deve fazer que não tem um efeito computacional imediato: a linha em branco cumpre a função de tornar o código mais legível para humanos.

 

A vantagem dessa estratégia é que um código fonte mais legível para humanos é também um código fonte que será mais facilmente compreendido e modificado, e, inclusive, melhorado.

 

A legibilidade de um código fonte depende de dois fatores, essencialmente: do estilo de codificação e da documentação do código. Existem muitos estilos de codificação, e a maioria deles é muito boa, e, portanto, a principal preocupação estilística de um programador que quer escrever um código legível é a de usar apenas um estilo de codificação em cada projeto.

 

O estilo de codificação determina coisas como se as variáveis serão em maiúsculas, minúsculas ou com algumas letras maiúsculas e outras minúsculas; se os nomes de variáveis e de funções serão em português (ou em outra língua “estrangeira”) e não em inglês; se a “indentação” (ou seja, a distância entre a margem esquerda e o texto do código) será feita incrementalmente ou se será uniforme, entre outras opções que, inicialmente, parecem ser tolas, especialmente se formos avisados do fato de que essas opções não têm efeito na execução do programa. Entretanto, essas opções, e, mais importante que as opções específicas adotadas, sua uniformidade, levam a uma melhor legibilidade do código fonte, e portanto a uma maior qualidade do software como texto que deverá ser modificado de tempos em tempos.

 

Por exemplo: o código abaixo é muito ilegível:

 

int i = j =3;

for(;i<j*3;i++,j--) { printf(“\ni = %d, j = %d”,i,j); scanf(“%d”,&i);}

calcvalorMEDIO(n,i,j);

 

Já o mesmo código, escrito de maneira mais bem-comportada, é mais fácil de ser compreendido:

 

int i,j;

for(min = 3, max = 3; min < (max*3); max--) {

    printf(“\ni = %d, j = %d”, min, max);

    scanf(“%d”, &min); }

media(num, min, max);

 

A diferença entre os dois casos é que em um deles foram utilizados nomes de variáveis e de funções com um mesmo padrão, e procurando usar para seus nomes palavras que sugiram qual é seu conteúdo. As expressões dentro do laço for foram indentadas cada uma em uma linha. Algumas partes supérfluas como a atribuição de valor a i na instrução de incremento do laço for foram eliminadas.

 

Um outro recurso muito importante para a legibilidade do código fonte é a documentação desse código. O principal elemento da documentação do código fonte é formado pelos comentários inseridos no código fonte. Em C, um comentário tem a seguinte sintaxe: tudo o que estiver contido dentro de um par /* */ é considerado comentário. Exemplos:

 

/* Isto eh um comentario */

/* Este

tambem

eh um unico

comentario */

/* Comentario */ printf(“Isto eh codigo\n”); /* Outro comentario */

 

A única exceção é quando o par /* */ vem dentro de uma sequência de caracteres a ser impressa, como as sequências usadas nos comandos printf:

 

printf(“Isto sera impresso: /* Isto nao eh comentario */, tal como previsto\n”);

 

Por que comentar, se o código está ali para quem quiser ler?

Nem sempre o código é a maneira mais fácil de entender o que o código faz. Por exemplo, numa função muito comprida textualmente, pode ser difícil compreender o que a função faz lendo seu código, pois será necessário interpretar cada comando de um conjunto extenso de comandos. Se houver um comentário que diga, em bom português (ou em outra língua estrangeira, ou em bom inglês) o que faz a função, nossa tarefa será enormemente facilitada, pois poderemos “decifrar” a função um pouco de cada vez, sem ter que interpretar toda ela de uma só vez para descobrir o que faz.

 

Somente para reforçar o que já foi dito, é importantíssimo comentar seu código pois bons programas são atualizados, enquanto que os maus programas são abandonados - e portanto se você quer escrever bons programas, que sejam utilizados o máximo possível, você deve escreve-los com abundantes comentários, pois dessa maneira você irá facilitar a tarefa da pessoa que tiver que corrigir ou melhorar o seu código (que será, possivelmente, você mesmo!). Além disso, uma boa parte da programação em C/C++ é feita em torno de bibliotecas de funções, ou seja, com vistas ao reuso do código. De modo que se você escrever uma função bem-comentada hoje, e quiser utiliza-la num outro programa seu daqui a alguns meses, bastará ler os comentários que você escreveu para identificar qual o propósito daquela função e como ela funciona.

 

Tá bom, tá bom, você me convenceu. Mas quando comentar?

Sempre que houver um trecho complicado ou representativo em seu programa. Por complicado, eu quero dizer difícil de ler. Por exemplo, laços que utilizam variáveis de controle e realizam várias modificações nos dados, devem ser comentados. Por representativo, eu quero dizer partes do seu código que são “pedaços” razoavelmente bem delimitados do programa: a entrada de dados, o processamento e a saída devem ser identificados através de comentários. Além disso, as variáveis utilizadas devem ter nomes sugestivos e comentários explicativos de o que será armazenado nelas. As funções devem comentar o que fazem, quais suas entradas de dados e qual a sua saída.

 

Exemplo: Considere o seguinte código. O que ele faz?

 

#include<stdio.h>

 

int fat(int n);

 

int main() {

    int n;

    scanf(“%d”, &n);

    printf(“%d\n”, fat(n)); }

 

int fat(int n) {

    if (n == 1)

        return 1;

    else

        return n*fat(n-1); }

 

É verdade que ele também está um tanto ilegível devido aos nomes poucos sugestivos de variáveis e função. Então tente dizer o que faz o seguinte código:

 

/*****************************************************

* fatorial.c - calcula e imprime o fatorial de um inteiro *

*****************************************************/

 

#include<stdio.h>

 

int fatorial(int fatorando);

 

int main() {

/* Variaveis:

numero armazena o numero cujo fatorial iremos calcular.

fat armazena o valor do fatorial de numero. */

    int numero, fat;

 

    /* Entrada de dados */

    printf(“Digite um no. inteiro cujo fatorial quer calcular: “);

    scanf(“%d”, &numero);

 

    /* Processamento */

    fat = fatorial(numero);

 

    /* Saida de resultados */

    printf(“O fatorial de %d eh %d.”, numero, fat);

    return 0; }

 

int fatorial(int fatorando) {

    /* Funcao fatorial:

    Recebe um numero inteiro,

    Calcula seu fatorial,

    Retorna esse fatorial. */

 

    /* Se o inteiro recebido for 1, retorne 1, afinal 1! = 1.

    Se o inteiro recebido for maior que 1, retorne esse numero vezes o fatorial desse numero menos 1, afinal n! = n*(n-1)! */

    if (fatorando == 1)

        return 1;

    else

        return fatorando*fatorial(fatorando-1); }

 

A segunda versão do exemplo é muito mais legível do que a primeira versão. Isso significa que se eu quiser utilizar essa função fatorial em outros programas, ou caso eu queira melhorar esse programa para que, por exemplo, calcule o fatorial de número reais, eu terei muito maior facilidade de fazer isso, pois o código fonte está legível.

 

Palavras-chave: Documentação de Código, Estilo de Codificação, Introdução à Programação


<< Voltar aos tópicos Responder