Coding Standards para Linguagem C

Bruno Clemente
Outubro 2017

1 Indentação
As indentações são feitas utilizando 8 caracteres. Pode parecer um exagero,
porém realmente ajuda a manter a legibilidade além de que uma TAB tem 8
caracteres. Sim, use TAB e não espaços.
Não coloque múltiplas declarações na mesma linha. Pode economizar espaço
vertical, porém pode facilmente passar despercebido na hora de ler o código.
Exemplo:
i f ( a == b ) r e t u r n 1 ; // Errado
i f (a > b)
return 1; // Certo
Nunca deixa espaços em branco no final da linha e nem linhas em branco no
final da página.
Linhas não devem ultrapassar 80 caracteres. Linhas muito grandes dificul-
tam a clareza do código.

2 Chaves
A posição das chaves sempre devem obedecer a seguinte regra: A chave de
abertura fica no final da linha e a chave de fechamento fica no inico de uma
linha. Como no exemplo:
i f (x i s true ) {
we do y
}
Exite, porém, uma exceção. Em funções, neste caso a abertura da chave deve
vir no começo de uma linha, como no exemplo:
int function ( int x)
{
body o f f u n c t i o n
}
Em caso de condicionais com apenas uma declaração, não deve-se usar
chaves.

1
3 Espaços
Deve ser usados espaços depois destes comandos: if, switch, case, for, do, while,
return.
Não utilize espaços envolta da parte de dentro de parenteses. Como mostra
o exemplo:
i f ( a == b ) // Errado
i f ( a == b ) // Certo
Em caso de nome de ponteiros, o asterisco deve vir acompanhado do nome
da variável e não do tipo. Exemplo:
int ∗ a ; // Errado
c h a r ∗tmp ; // Certo
Deve-se utilizar um espaço de cada lado dos operadores binários e terciários:
= + − < > ∗ / % | & ˆ <= >= == ! = ? :
Porém não deve-se usar espaços depois de operadores unários: & ∗ + − !
sizeof typeof alignof attribute defined ++ – Além disso, não deve-se usar
espaços entre os operadores de membros de estruturas (. e -¿).
Por fim, em caso de parâmetros de funções, deve-se colocar um espaço depois
de cada vı́rgula para separar os parâmetros e um espaço depois do nome da
função. Exemplo:
void function ( i n t a , i n t b , i n t c ) ;

4 Nomenclaturas
Todos os nomes devem ser escritos em inglês para garantir uma maior univer-
salização do código.

4.1 Variáveis
Os nomes de variáveis devem ser escritos com todas as letras minusculas. Em
caso de nome composto, deve-se utilizar ’underline’ para separar os nomes.
Variáveis globais devem possuir um nome mais descritivo possı́vel. Detalhe,
evite ao máximo utilizar variáveis globais.
Variáveis locais, por outro lado, podem ter um nome mais enxuto desde que
ainda entendı́veis. Há em C, certo nome de variáveis que estão consagrados e
podem ser utilizados para variáveis locais, como: tmp, i, c, buffer, foo, bar etc.

4.2 Macros e enums

Tanto as macros como os enums devem ser escrito utilizado todas as letras em
maiúsculo. Em caso de nome composto, deve-se utlizar ’underline’ para separar
os nomes.

2
 Para cada valor declarado dentro de um enum, deve-se prefixar na frente
dele o nome do enum. Como mostrado no exemplo:
enum TASK STATUS{
TASK STATUS SUSPENDED,
TASK STATUS ACTIVE,
TASK STATUS DIED
}
Em caso de um define ou enum que só faça sentido dentro de um namespace,
deve-se adicionar um ’underline’ no começo do nome.

4.3 Estruturas e Typedefs

Quando definido o nome das estruturas e typedefs, deve-se utilizar apenas etras
minusculas. Em caso de nome composto, deve-se utilizar ’underline’ para sepa-
rar os nomes. Além disto, no final do nome deve-se adicionar ’ t’.
Agora, quando for instanciar um typedef, deve-se seguir as mesmas re-
gras das variáveis. Porém, no caso de estruturas, em caso de nome composto
não utiliza-se ’underline’. Nesta situação, deve-se utilizar a primeira letra do
próximo nome em maı́usculo.
Em caso de uma estrutura ou typedef que só faça sentido dentro de um
namespace, deve-se adicionar um ’underline’ no começo do nome.

4.4 Funções
A nomeclatura das funções seguem a mesmas regras das variáveis.
Em caso de uma função que só faça sentido dentro de um namespace, deve-se
adicionar um ’underline’ no começo do nome.

5 Typedefs
Em regra geral, NUNCA utilize typedefs. As pessoas tendem a usar typedefs
para duas situações, esconder tipos muito grandes (unsgined int) e evitar utilizar
’struct’ toda vez. Nos dois casos, creio que tu estás perdendo informação por
uma razão boba. Vale a pena saber se algo é uma struct, por exemplo.
O único caso no qual consigo pensar em que criar tipos é algo útil, são
em casos muitos especı́ficos onde pretende-se criar um novo tipo para realizar
’type-checking’.

6 Funções
As funções devem ser pequenas, simples e realizarem apenas uma coisa. Geral-
mente, se a sua função tem mais do que 30 linhas, provavelmente tu podes
simplifica-la

3
 Além disso, disso, dificilmente uma função tem mais do que 5-10 variáveis.
Tente sempre separar a função em partes mais especı́ficas. Caso a performance
seja algo muito importante, então utilize funções inline.
No código, deve-se separar cada função com uma linha em branco.
Nos protótipos das funções, sempre adicione os nomes dos parâmetros para
melhorar o entendimento.

7 Comentários
Comentários são fundamentas, porém não exagere. Seu comentário deve dizer
O QUE seu código faz e não COMO ele faz. Todos os comentários devem ser
em inglês. Os exemplo aqui escritos estão em português somente para um maior
entendimento.
Evite colocar comentários dentro do corpo da função. As únicas exceções
são para alertar sobre algum perigo ou um ’TODO’.
Antes do corpo de cada função, deve-se adicionar um comentário de acordo
com o seguinte padrão:
/∗
∗ f u n c a o ( ) − Breve d e s c r i c a o da f u n c a o .
∗ @arg1 : D e s c r i c a o do p r i m e i r o argumento .
∗ @arg2 : D e s c r i c a o do segundo argumento .
∗
∗ D e s c r i c a o mais completa da f u n c a o
∗
∗ Return : D e s c r i c a o do v a l o r de r e t o r n o .
∗/
Antes do corpo de cada função, deve-se adicionar um comentário de acordo
com o seguinte padrão:
/∗
∗ s t r u c t s t r u c t n a m e − Breve d e s c r i c a o .
∗ @member name1 : D e s c r i c a o do p r i m e i r o membro .
∗ @member name2 : D e s c r i c a o do segundo membro .
∗
∗ D e s c r i c a o da e s t r u t u r a .
∗/

8 Condicionais de Pŕe-Processamento
Evite utilizar condicionais de complamento (#ifdef) dentro do código .c . De
preferência, coloque todo o pré-processamento dentro dos headers.
Além disso, é necessário no inicio de cada header, utilizar um condicional
para ter certeza que o mesmo hedaer não será executado duas vezes pelo com-
pilador. O define deste condicional deve seguir as normas de nomenclatura de

4
macros já definidas neste documento e, além disso, deve-se adicionar um pré-fixo
com o nome do projeto e um pós-fixo com ’ H’. Como no exemplo:
#i f n d e f PROJECT TASK H
#d e f i n e PROJECT TASK H
.
.
.
#e n d i f

9 Estruturas
As estrturas devem seguir todas as normas já definidas neste documento para
nomenclatura de estruturas. Seus membros devem seguir as normas de nomen-
claturas para variáveis.
Falta falar sobre os membros privados. A linguagem C, não possui membros
privados, o que aumenta a importância do cuidado necessário ao tratar de cer-
tas informações que deveriam ser privadas. Estes membros deve ser nomeados
incluindo um ’underline’ no inicio do nome.
Toda struct que não é restringida a um determinado userspace, deve possuir
uma função para alocação e outra para desalocação.
A função de alocação deve retornar um ponteiro da strutct recém criada
e inicializar TODOS os membros da struct. Sua nomenclatura deve seguir o
exemplo(com ’ new’):
struct task t {
i n t type ;
int state ;
};
s t r u c t t a s k t t a s k n e w ( i n t type ) ;
A função de desalocação deve desalocar todos os membros no qual a struct
tem ’ownership’. Ou seja, membros que façam parte da struct. Sua nomen-
clatura deve seguir o exemplo(com ’ delete’):
void t a s k d e l e t e ( s t r u c t t a s k t ∗ task ) ;
Todas as funções ’membros’ de certa struct, devem ter em seus nomes o nome
da struct como prefixo(sem ’ t’). Além disso, o primeiro argumento sempre deve
ser o ponteiro para a struct em questão, de acordo com o exemplo:
v o i d t a s k s e t s t a t e ( s t r u c t t a s k t ∗ task , i n t s t a t e ) ;