O Normal

Version 2.0.2

Resumo: Este documento descreve a norma aplicável (Norm) aos 42. A padrão de programação define um
conjunto de regras a seguir ao escrever código. Você deve sempre respeite a Norma para todos os projetos C na
escola, salvo especificação em contrário.
Conteúdo
Eu prefácio 2
Eu. 1 Por que impor um padrão? . . . . . . . . . . . . . . . . . . . . . . . . . 2
Eu. 2 A norma para submissões... . . . . . . . . . . . . . . . . . . . . . . 2
Eu. 3 sugestões... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Eu. 4 avisos legais... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
II O Norm 3
II. 1 Denominação... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
II. 2 Formatação... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
II. 3 parâmetros de funções... . . . . . . . . . . . . . . . . . . . . . . . . . 5
II. 4 Funções... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
II. 5 Typedef, estrutura, enum e união . . . . . . . . . . . . . . . . . . . . . 5
II. 6 cabeçalhos... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
II. 7 Macros e Pré-processadores... . . . . . . . . . . . . . . . . . . . . . . 6
II. 8 Coisas proibidas! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
II. 9 Comentários... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
II.10 Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
II. Show 11... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Capítulo I
Foreword
Este documento descreve a norma aplicável (Norm) em 42. Um padrão de programação
define um conjunto de regras a seguir ao escrever código. Você deve sempre respeitar o Norm por
todos os projetos C na escola, salvo especificação em contrário.
Eu. 1 Por que impor um padrão?
Os dois principais objetivos da Norma: 1. Para formatar e padronizar o seu código para que qualquer pessoa
(estudantes, funcionários e até você mesmo) podem lê-los e entendê-los facilmente. 2. Para te guiar
por escrever código curto e simples.
Eu. 2 A norma para submissões
Todos os seus arquivos C devem respeitar o Normal da escola. Será verificado pelo seu aluno. Se
cometeste qualquer erro Normal, vais receber um 0 pelo exercício ou até mesmo pelo projeto todo.
Durante as avaliações pelos pares, o seu aluno terá de lançar a "Norminette" presente em
as lixeiras da sua apresentação. Apenas a parte obrigatória da Norma será verificada pelo
"Norminette".
I. 3 sugestões
Vais perceber em breve que o Norm não é tão intimidador quanto parece. Na secção
ao contrário, vai ajudar-te mais do que imaginas. Isso permitirá que você leia o código dos seus colegas de
turma
mais facilmente e vice-versa. Um arquivo fonte contendo um erro de Norm será tratado o
da mesma forma que um arquivo fonte contendo 10 erros de Normalização. Aconselhamos vivamente que
mantenha o
Norm em mente enquanto codifica - mesmo que sintas que isso te está a abrandar no início. Em
tempo, vai tornar-se um reflexo.
Eu. 4 avisos legais
"Norminette" é um programa, e todos os programas estão sujeitos a bugs. Você deve encontrar um,
Por favor, denuncie na seção apropriada do fórum. No entanto, como a "Norminette" sempre
prevalece, todos os seus envios devem se adaptar aos seus bugs.
2
Capítulo II
O Normal

II. 1 Denominação
Parte obrigatória

 nome de uma estrutura deve começar por s_.

 nome de um typedef deve começar por t_.
 nome de um sindicato deve começar por u_.
 nome de um enum deve começar por e_.
 nome de um global deve começar por g_.
 Variáveis e nomes de funções só podem conter minúsculas, dígitos e ’_’ (Unix Caso).
 Os nomes de arquivos e diretórios só podem conter minúsculas, dígitos e ’_’ (Case Unix).
 O arquivo deve compilar.
 Personagens que não fazem parte da tabela ascii padrão são proibidos.

Parte do conselho

• Objetos (variáveis, funções, macros, tipos, arquivos ou diretórios) devem ter o máximo nomes
explícitos ou mais mnemónicos possível. Apenas "contadores" podem ser nomeados para o seu
curtindo.
• As abreviações são toleradas desde que seja para encurtar o nome original, e isso
permanece inteligível. Se o nome contiver mais do que uma palavra, as palavras serão Separados por '_'.
• Todos os identificadores (funções, macros, tipos, variáveis, etc) devem estar em inglês.
• Qualquer utilização de variável global deve ser justificável

II. 2 Formatação
Parte obrigatória
  Todos os seus arquivos devem começar com o cabeçalho padrão da escola (a partir da primeira linha do
arquivo). Este cabeçalho está disponível por omissão com o emacs e o vim nas lixeiras.
 Você deve indentar o seu código com tabulações de 4 espaços. Isto não é o mesmo que 4 espaços
comuns, estamos a falar de tabulações reais aqui.
 Cada função deve ter no máximo 25 linhas, sem contar com os próprios suportes encaracolados da
função.
 Cada linha deve ter no máximo 80 colunas de largura, comentários incluídos. Aviso: uma tabulação não
conta como uma coluna, mas como o número de espaços que representa.
 Uma instrução por linha.
 Uma linha vazia deve estar vazia: sem espaços ou tabulações.
 Uma linha nunca pode acabar com espaços ou tabulações.
 Você precisa começar uma nova linha após cada suporte encaracolado ou fim da estrutura de controle.
 A menos que seja o fim de uma linha, cada vírgula ou ponto e vírgula deve ser seguido por um espaço.
 Cada operador (binário ou ternário) ou operando deve ser separado por um e apenas um espaço.
 Cada palavra-chave C deve ser seguida por um espaço, exceto por palavras-chave para tipos (como int,
char, float, etc. ), bem como tamanho.
 Cada declaração variável deve ser marcada na mesma coluna.
 Os asteriscos que acompanham ponteiros devem estar presos a nomes de variáveis.
 Uma única declaração variável por linha.
 Não podemos colar uma declaração e uma inicialização na mesma linha, exceto para variáveis globais e
variáveis estáticas.
 As declarações devem estar no início de uma função, e devem ser separadas por uma linha vazia.
 Não pode haver uma linha vazia entre declarações ou implementações.
 Várias atribuições são estritamente proibidas.
 Pode adicionar uma nova linha após uma estrutura de instrução ou controlo, mas terá de adicionar uma
indentação com parênteses ou operador de afetação.
 Os operadores devem estar no início de uma linha.

II. 3 parâmetros de funções

Parte obrigatória:

 Uma função pode levar 4 parâmetros nomeados no máximo.

 Uma função que não aceita argumentos deve ser explicitamente pototipada com a palavra "vaid" como
argumento.

II. 4 Funções
Parte obrigatória

 Os parâmetros nos protótipos das funções devem ser nomeados.

 Cada função deve ser separada da próxima por uma linha vazia.
 Não pode declarar mais de 5 variáveis por bloco.
 retorno de uma função tem que ser entre parênteses.

Parte do conselho
 Os identificadores das suas funções devem estar alinhados dentro de um mesmo arquivo. O mesmo se
aplica aos arquivos de cabeçalho.

II. 5 Typedef, estrutura, enum e união

Parte obrigatória
 Adicione uma tabulação ao declarar uma estrutura, enum ou união.
 Ao declarar uma variável de tipo estrutura, enum ou união, adicione um único espaço no digite.
 Adicione uma tabulação entre dois parâmetros de um typedef.
 Ao declarar uma estrutura, união ou enum com um typedef, aplicam-se todas as regras. Você deve
 alinhar o nome do typedef com o nome da estrutura/união/enum.
 Você não pode declarar uma estrutura em um. arquivo c.

II. 6 cabeçalhos
Parte obrigatória
  As coisas permitidas nos arquivos de cabeçalho são: inclusões de cabeçalho (sistema ou não),
declarações, define, protótipos e macros.
 Tudo include (. c ou . h) deve estar no início do arquivo.
Protegeremos cabeçalhos de inclusões duplas. Se o arquivo for ft_foo. H, é espectador macro é FT_FOO_H.
Os protótipos das funções devem estar exculivamente em . Ficheiros H.
Inclusões de cabeçalho não usadas (. h) são proibidos.

Parte de conselhos
 Todas as inclusões de cabeçalho devem ser justificadas em um . arquivo c, bem como em um. arquivo h.

II. 7 macros e pré-processadores

Parte obrigatória
 As constantes de pré-processador (ou #define) que você criar devem ser usadas apenas para valores
literais e constantes associados.
 Todos os #definidos criados para contornar a norma e/ou o código ofuscado são proibidos. Este ponto
deve ser verificado por um humano.
 Você pode usar macros disponíveis em bibliotecas padrão, apenas se essas forem permitidas no âmbito
do projeto indicado.
 Macros multiline são proibidos.
 Apenas os nomes de macros são maiúsculas.
 Você deve indentar caracteres seguindo #if, #ifdef ou #ifndef.

II. 8 Coisas proibidas!

Parte obrigatória

 Você não está autorizado a usar :

o For
o do...while
o switch
o case
o goto
o Operadores ternários aninhados como ‘? ’.
o VLAs - Matrizes de Comprimento Variável.

II. 9 comentários
Parte obrigatória
 Tens permissão para comentar o teu código nos teus ficheiros fonte.
 Os comentários não podem estar dentro dos corpos das funções.
 Comentários começam e terminam por uma única linha. Todas as linhas intermediárias devem alinhar-
se e começar por "**".
 Sem comentários com //.

Parte do conselho
 Seus comentários devem estar em inglês. E eles devem ser úteis.
 Um comentário não pode justificar uma função "bastardo".

II.10 Arquivos
Parte obrigatória
 Você não pode incluir um arquivo .c .
 Você não pode ter mais de 5 definições de função em um arquivo .c .

II. 11 Makefiles
Parte obrigatória
 $(NOME), clean, fclean, re e todas as regras são obrigatórias.
 Se o makefile voltar a ligar, o projeto será considerado não funcional.
 No caso de um projeto multibinário, além das regras que vimos, deve ter uma regra que compila ambos
os binários, bem como uma regra específica para cada binário compilado.
 No caso de um projeto que chama uma biblioteca de funções (por exemplo: libft), o seu makefile deve
compilar esta biblioteca automaticamente.
 Todos os arquivos de origem que precisa para compilar o seu projeto devem ser explicitamente
nomeados no seu Makefile.