Vous êtes sur la page 1sur 13

La norme de 42

Version 1.5
Benny benny@42.fr
Thor thor@42.fr
marvin marvin@42.fr

Rsum: Ce document dcrit la norme C en vigueur 42. Une norme de


programmation dfinit un ensemble de rgles rgissant lcriture dun code. Il est
obligatoire de respecter la norme lorsque vous crivez du C 42.

Table des matires


I
I.1
I.2
I.3

Avant-propos
Pourquoi imposer une norme ? . . . . . . . . . . . . . . . . . . . . . .
La norme dans vos rendus . . . . . . . . . . . . . . . . . . . . . . . .
Conseils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

II.1
II.2
II.3
II.4
II.5
II.6
II.7
II.8
II.9
II.10
II.11

La norme de 42
Convention de dnomination .
Formatage . . . . . . . . . . .
Paramtres de fonction . . . .
Fonctions . . . . . . . . . . . .
Typedef, struct, enum et union
Headers . . . . . . . . . . . . .
Macros et Pr-processeur . . .
Choses Interdites ! . . . . . . .
Commentaires . . . . . . . . .
Les fichiers . . . . . . . . . . .
Makefile . . . . . . . . . . . .

II

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

2
2
2
2
3
3
4
7
8
9
10
10
11
11
11
12

Chapitre I
Avant-propos
Ce document dcrit la norme C en vigueur 42. Une norme de programmation dfinit
un ensemble de rgles rgissant lcriture dun code. Il est obligatoire de respecter la norme
lorsque vous crivez du C 42.

I.1

Pourquoi imposer une norme ?

La norme a deux objectifs principaux :


Uniformiser vos codes afin que tout le monde puisse les lire facilement, tudiants et
encadrants.
Ecrire des codes simples et clairs.

I.2

La norme dans vos rendus

Tous vos fichiers de code C doivent respecter la norme de 42. La norme sera verifie
par vos correcteurs et la moindre faute de norme donnera la note de 0 votre projet ou
votre exercice.
La moulinette de correction utilise en plus de vos soutenances lancera un programme
appell Norminette. La Norminette vrifiera le sous-ensemble des rgles de norme quil
lui est possible de vrifier. En consquence, la Norminette aura tendance se montrer
plus clmente que vos souteneurs.

I.3

Conseils

Comme vous le comprendrez rapidement, la norme nest pas une contrainte. Au


contraire, la norme est un garde-fou pour vous guider dans lcriture dun C simple et
basique. Cest pourquoi il est absolument vital que vous codiez directement la norme,
quite coder plus lentement les premires heures. Un fichier de sources qui contient une
faute de norme est aussi mauvais quun fichier qui en compte dix. Soyez studieux et
appliqus et la norme deviendra un automatisme sous peu.

Chapitre II
La norme de 42
II.1

Convention de dnomination

Les objets syntaxiques (variables, fonctions, macros, types, fichiers ou rpertoires)


doivent avoir les noms les plus explicites ou mnmoniques. Seul les compteurs
peuvent tre nomms votre guise.
Les abrviations sont tolres dans la mesure o elles permettent de rduire significativement la taille du nom sans en perdre le sens.
Les parties des noms composites seront spares par _ (underscore).
Tous les identifiants (fonctions, macros, types, variables, etc.) doivent tre en anglais. Pas de franais ou de franglais.
Un nom de structure doit commencer par "s_".
Un nom de typedef doit commencer par "t_".
Un nom dunion doit commencer par "u_".
Un nom denum doit commencer par "e_".
Un nom de globale doit commencer par "g_".
Toute utilisation de variable globale doit tre justifie.
Les noms de variables, de fonctions, de fichiers et de rpertoires doivent tre composs exclusivement de minuscules, de chiffres et de _. (Unix Case)

La norme de 42

Version 1.5

void

ft_do_stuff(void);

/* WRONG : Nous ne savons pas ce que fait cette fonction */

void

ft_print_char(void);

/* RIGHT : Nous savons que cette fonction affiche un char */

void
{

ft_testing_function(void)
int
int
char

bla;
prout;
*gruik;

/* WRONG */
/* WRONG */
/* WRONG */

}
ft_testing_function(void)

void
{

int
int
char

counter;
user_input_size;
*user_input;

/* RIGHT */
/* RIGHT */
/* RIGHT */

}
int ft_calculator_function(void);
int ftCalculatorFunction(void);
int FtCalculatorFunction(void);

II.2

/* RIGHT : Unix case */


/* WRONG : Camel case */
/* WRONG : Java case */

Formatage

Tous vos fichiers devront commencer par le header standard de 42 ds la premire


ligne. Le header ressemble :
/*******************************************************************************/
/*
*/
/*
:::
::::::::
*/
/*
filename_____________________________.ext
:+:
:+:
:+:
*/
/*
+:+ +:+
+:+
*/
/*
by: login____ <login____@student.42.fr>
+#+ +:+
+#+
*/
/*
+#+#+#+#+#+
+#+
*/
/*
Created: yyyy/mm/dd hh:mm:ss by login____
#+#
#+#
*/
/*
Updated: yyyy/mm/dd hh:mm:ss by login____
###
########.fr
*/
/*
*/
/*******************************************************************************/

Chaque fonction doit faire au maximum 25 lignes sans compter les accolades du
bloc de la fonction. Exemple dune fonction de 5 lignes :
int ft_fct_demo(void)
{
int count;
count = 41;
count = count + 1;
return (count);
}

Chaque ligne ne peut faire plus de 80 colonnes, commentaires compris. (Attention,


une tabulation ne compte pas pour une colonne mais bien pour les n espaces quelle
reprsente).
Une seule dclaration par ligne.
Une seule instruction par ligne.
Une ligne vide ne doit pas contenir despaces ou de tabulations.
4

La norme de 42

Version 1.5

Une ligne ne doit jamais se terminer par des espaces ou des tabulations.
Une accolade ouvrante ou fermante doit tre seule sur sa ligne avec la bonne identation.
Vous devez retourner la ligne la fin dune structure de contrle (if, while, etc.).
Vous devez indenter votre code avec des tabulations de 4 espaces (Ce nest pas
quivalent 4 espaces, ce sont bien des tabulations.). Dans sa configuration de base,
votre diteur est susceptible dinsrer des espaces en lieu et places de tabulations,
soyez attentifs. Consultez la documentation.
Exemples :
if (test > 0 && test < 42) { return value; }

/* WRONG */

if (test > 0 && test < 42) return value;

/* WRONG */

if (test > 0 && test < 42)


{
return value;
}
if (test > 0 && test < 42)
{
return value;
}
if (test > 0 && test < 42) {
return value;
}
if (test > 0 && test < 42)
{
return value;
}
if (test > 0 && test < 42)
{
return value;
}
if (test > 0 && test < 42)
return value;

/* WRONG */

/* WRONG */

/* WRONG */

/* RIGHT */

/* RIGHT mais bof */

/* RIGHT (parce quil ny quune ligne dans ce bloc) */

Chaque virgule ou point-virgule doit tre suivi dun espace si nous ne sommes pas
en fin de ligne.
Chaque oprateur (binaire ou ternaire) et ses oprandes doivent tre spars par
un espace et seulement un.
Chaque mot clef du C doit tre suivi dun espace sauf pour les spcifieurs de type
(comme int, char, float, const, etc.) ainsi que sizeof. (On a gard parce que KRP a
dit 82 qui accessoirement est pair)

La norme de 42

Version 1.5

Exemples :
if(test==0)
{
return value;
}
if (test==0)
{
return value;
}
if(test == 0)
{
return value;
}
if (test == 0)
{
return value;
}
if (test == 0)
{
return ;
}

/* WRONG */

/* WRONG */

/* WRONG */

/* RIGHT */

/* RIGHT */

Chaque dclaration de variable doit tre indente sur la mme colonne. Les toiles
des pointeurs doivent tre colles au nom de la variable et les unes aux autres.
Le type dune variable et son identifiant doivent tre spars par au moins une
tabulation.
Une seule dclaration de variable par ligne.
On ne peut PAS faire une dclaration et une initialisation sur une mme ligne,
lexception des variables globales, des variables statiques et des constantes.
Exemples :
void
{

main(void)
char letter;
double current_value;
char *words;

/* WRONG */

letter = c;
}
void
{

main(void)
char
double
char

letter = c;
current_value;
*words;

/* WRONG */

}
void
{

main(void)
char
double
char

letter;
current_value;
*words;

/* RIGHT */

letter = c;
}

La norme de 42

Version 1.5

Les dclarations doivent tre en dbut de bloc et doivent tre spares de limplmentation par une ligne vide.
Aucune ligne vide ne doit tre prsente au milieu des dclarations ou de limplmentation.
main(void)

void
{

char
letter;
double big_number;
char
*words;
letter = a;
big_number = 0.2;

/* WRONG */

}
main(void)

void
{

char
double
char

letter;
big_number;
*words;

/* WRONG */

letter = a;
big_number = 0.2;
}
main(void)

void
{

char
double
char

letter;
big_number;
*words;

/* RIGHT */

letter = a;
big_number = 0.2;
}

Vous pouvez retourner la ligne lors dune mme instruction ou structure de


contrle, mais vous devez rajouter une indentation par parenthse ou oprateur
daffectation. Les oprateurs doivent tre en dbut de ligne. Retourner la ligne
peut nuire la lisibilit de votre code, soyez donc mesurs. Plus gnralement, si
vous avez des instructions ou des expressions trop longues, cest que vous navez
pas suffisamment factoris votre code.
toto = 42 + 5
- 28;
if (toto == 0
&& titi == 2
&& (tutu == 3
&& tata == 4)
|| rara == 3)

II.3

/* RIGHT (Mais difficile a lire :P) */

/* RIGHT (Mais difficile a lire :P) */

Paramtres de fonction

Une fonction prend au maximum 4 paramtres nomms.


Une fonction qui ne prend pas dargument doit explicitement tre prototype avec
le mot void comme argument
7

La norme de 42
int fct();
int fct(void);

II.4

Version 1.5
/* WRONG */
/* RIGHT */

Fonctions

Les paramtres dun prototype de fonction doivent possder des noms.


Vous ne pouvez dclarer que 5 variables par bloc au maximum.
Vos identifiants de fonction doivent tre aligns dans un mme fichier (sapplique
aux headers).
Chaque dfinition de fonction doit tre spare par une ligne vide.
Le type de retour dune fonction et lidentifiant de cette fonction doivent tre spars
par au moins une tabulation.
main(void)

void
{
...
}

/* WRONG */
struct s_info
{
...
}

get_info(void)

/*=============================================*/
main(void)

void
{
...
}

/* RIGHT */
struct s_info
{
...
}

get_info(void)

Souvenez vous que lon met toujours un espace aprs une virgule ou un point-virgule
si nous ne sommes pas en fin de ligne.
fct(int arg1, int arg2, int arg3)

void
{
...
}

main(void)

int
{
...

fct(arg1, arg2, arg3);


...
}

La norme de 42

II.5

Version 1.5

Typedef, struct, enum et union

Les structs, unions et enums anonymes sont interdites.


La dclaration de structs, unions et enums doivent tre dans le scope global.
Vous devez mettre une tabulation avant lidentifiant lorsque vous dclarez une
struct, enum ou union.
struct s_buff
{
...
};
struct
{

/* WRONG */

s_buff
...

/* RIGHT */

};

Lors de la dclaration dune variable de type struct, enum ou union vous ne mettrez
quun espace dans le type.
struct s_buff
struct s_buff

toto;
toto;

/* WRONG */
/* RIGHT */

Vous devez utiliser une tabulation entre les deux paramtres dun typedef.
typedef int myint;
typedef int
myint;

/* WRONG */
/* RIGHT */

Lorsque vous dclarez une struct, union ou enum avec un typedef toutes les rgles
sappliquent et vous devez aligner le nom du typedef avec le nom de la struct, union
ou enum.
typedef struct s_buff
{
....
}
t_buff;
typedef struct
{
....
}t_buff;

s_buff

typedef struct
{
....
}
t_buff;

s_buff

typedef struct
{
....
}

s_buff

/* WRONG */

/* WRONG */

/* WRONG */

/* RIGHT */
t_buff;

La norme de 42

II.6

Version 1.5

Headers

Seuls les inclusions de headers (systme ou non), les dfinitions de structures de


donnes, les defines, les prototypes et les macros sont autoriss dans les fichiers
headers.
Toute inclusion de header doit etre justifie autant dans un .c que dans un .h.
Tous les includes de .h doivent se faire au dbut du fichier (.c ou .h).
La norme sapplique aussi aux headers.
Les headers doivent tre protgs contre la double inclusion. Si le fichier est foo.h,
la macro tmoin est __FT_FOO_H__.
#ifndef __FT_FOO_H__
# define __FT_FOO_H__
/* code du header */
#endif /* !__FT_FOO_H__ */

Une inclusion de header (.h) dont on ne se sert pas est interdite.


Les macros doivent se trouver exclusivement dans des fichiers .h. Les seules macros tolres dans les fichiers .c sont celles qui activent des fonctionnalits (ex :
BSD_SOURCE).

II.7

Macros et Pr-processeur

Les macros multilignes sont interdites.


Seuls les noms de macros sont en majuscules.
#define FOO bar

Il faut indenter les caractres qui suivent un #if , #ifdef ou #ifndef avec un espace
chaque niveau.
#ifndef __TOTO_H__
# define __TOTO_H__
# ifdef __WIN32
# define FOO bar
# endif /* __WIN32 */
#endif /* !__TOTO_H__ */

Pas de #if, #ifdef ou #ifndef aprs la premire dfinition de fonction dans un .c.

10

La norme de 42

II.8

Version 1.5

Choses Interdites !

Vous navez pas le droit dutiliser :


for (parce que cest tomb sur Face)
do . . .while
switch
case
goto
Les ternaires imbriqus
(a ? (b ? : -1 : 0) : 1)

II.9

/* WRONG */

Commentaires

Les commentaires peuvent se trouver dans tous les fichiers source.


Il ne doit pas y avoir de commentaires dans le corps des fonctions.
Les commentaires sont commencs et termins par une ligne seule. Toutes les lignes
intermdiaires salignent sur elles, et commencent par "**".
Pas de commentaire C++ ("//").
Vos commentaires doivent tre en anglais et utiles.
Le commentaire ne peut pas justifier une fonction tordue.
/*
** This function makes people laugh
*/
void
ft_lol(void)
{
}
/*
** Right
*/
/*
* Wrong
*/

II.10

Les fichiers

Vous ne pouvez pas inclure un .c. Jamais.


Vous ne pouvez pas avoir plus de 5 dfinitions de fonction dans un .c.
11

La norme de 42

II.11

Version 1.5

Makefile

Les rgles $(NAME), clean, fclean, re et all sont obligatoires.


Le projet est considr comme non-fonctionnel si le makefile relink.
Dans le cas dun projet multibinaire, en plus des rgles prcdentes, vous devez
avoir une rgle all compilant les deux binaires ainsi quune rgle spcifique chaque
binaire compil.
Dans le cas dun projet faisant appel une bibliothque de fonctions (par exemple
une libft), votre Makefile doit compiler automatiquement cette bibliothque.
Lutilisation de wildcard (*.c par exemple) est interdite.

12