CSS : Selecteur : after

Utilisation du sélecteur after :

1
2
<div class="field"></div>
<div class="field"></div>
1
2
3
4
.field:after{
  content:"*";
  color:red;
}

Utilisation du sélecteur avec différents types de champs :

1
2
3
4
5
<div class="req"><button>bouton</button></div>
<div class="req"></div>
<div class="req"></div>
<div class="req"></div>
<div class="req"><textarea></textarea></div>
1
2
3
4
.req:after{
    content: "*";
    color: red;
}

Norme de développement

Présentation générale
• Une ligne, y compris pour les commentaires, ne doit pas excéder 80 colonnes.
• Une seule instruction par ligne.
• Une fonction ne doit pas excéder 25 lignes entre les accolades.
• Un fichier ne doit pas contenir plus de 5 fonctions.
• Seuls les inclusions de headers (système ou non), les définitions, les defines, les prototypes et les macros sont autorisés dans les fichiers headers.
• Toute inclusion de header doit etre justifiée.
• Les macros multilignes sont interdites.
• Les prototypes de fonctions et les macros doivent se trouver exclusivement dans des fichiers .h. Les seules macros tolérées dans les fichiers .c sont celles qui activent des fonctionnalités (ex : _BSD_SOURCE).

Les commentaires
• Les commentaires peuvent se trouver dans tous les fichiers source.
• Il ne doit pas y avoir de commentaires dans le corps des fonctions.

Indentation
• L’indentation est obligatoire, quand on ouvre une accolade on indente et inversement.

Nomination
• Les objets (variables, fonctions, macros, types, fichiers ou répertoires) doivent avoir les noms les plus explicites ou mnémoniques.
• Les abréviations sont tolérées dans la mesure où elles permettent de réduire significativement la taille du nom sans en perdre le sens. Les parties des noms composites seront séparées par ’_’.
• Tous les identifiants (fonctions, macros, types, variables etc.) doivent être en anglais.
• Les noms de variables, de fonctions, de fichiers et de répertoires doivent être composés exclusivement de minuscules, de chiffres et de ’_’.
• Seuls les noms de macros sont en majuscules.
• Un typedef sur s_my_struct doit s’appeler t_my_struct.
• Un nom de structure doit commencer par s_.
• Un nom de type doit commencer par t_.
• Un nom d’union doit commencer par u_.
• Un nom de globale doit commencer par g_.
• Toute utilisation de variable globale doit etre jusitifiée.

Déclarations / Affectations
• On sautera une ligne entre la déclaration de variable et les instructions. On met une variable par ligne. Il ne doit pas y avoir d’autres lignes vides dans les blocs. Si vous avez envie de séparer des parties d’un bloc, faites soit plusieurs blocs, soit une fonction.
• On alignera les déclarations avec des tab (sous Emacs M-i). Cela est valable aussi pour les prototypes de fonction.
• Il est interdit d’affecter et de déclarer une variable en même temps, excepté lorsque l’on manipule des variables statiques ou globales
• Abuser des static pour faire des globales est interdit. Toute variable statique doit etre justifiée.
• Le symbole de pointeur (*) porte toujours sur la variable (ou fonction), et jamais sur le type

Structures de contrôle
• Une structure de contrôle sera toujours suivie d’un retour à la ligne et des accolades (même pour un if … return …).

Paramètres
• La déclaration des paramètres se fera à la syntaxe ISO/ANSI C.
• Les virgules ne sont autorisées que dans ce contexte.
• Au maximum on doit trouver 4 paramètres dans une fonction. Pour passer plus d’information, faites une structure et passez un pointeur sur cette structure (et jamais la structure directement).

Espaces
• Un espace derrière la virgule.
• Pas d’espace entre le nom d’une fonction et la ’(’.
• Un espace entre un mot clé C (avec ou sans argument) et la ’(’ ou le ’ ;’ dans le cas d’un return.
• Pas d’espace après un opérateur unaire.
• Tous les opérateurs binaires et ternaires sont séparés des arguments par un espace de part et d’autre.
• Il faut indenter les caractères qui suivent un #if ou un #ifdef.
• Il faut indenter les macros imbriquées.
• Une ligne vide doit séparer les définitions de fonctions.

Makefile
• Les règles $(NAME), clean, fclean, re et all sont obligatoires.
• Le projet est considéré comme non fonctionnel si le makefile relink.
• Dans le cas d’un projet multi-binaires, en plus des règles précédentes, vous devez avoir une règle all compilant les deux binaires ainsi qu’une règle spécifique à chaque binaire compilé.
• Dans le cas d’un projet faisant appel à une bibliothèque de fonctions (par exemple une libmy), votre Makefile doit compiler automatiquement cette bibliothèque.
• L’utilisation de ’wildcard’ (*.c par exemple) est interdite.

En-tête d’un fichier source de type « Application » ou « Implémentation d’utilitaire »

L’en-tête d’un fichier source de type APPLICATION ou IMPLEMENTATION D’UTILITAIRE comporte les rubriques suivantes, dont certaines rubriques peuvent être facultatives.

Type :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/**************************************
*
* NOM : nom.c
* TYPE : APPLICATION ou UTILITAIRE
* SUJET : descr. sommaire de la fct. d'usage
*
* AUTEUR : nom de (des) l'auteur(s)
* VERSION : numéro de version
* CREATION : date de création
* DER. MODIF. : date de dernière modification
*
* ACCES SRC : chemin du code source
* ACCES OBJ : chemin du code obj pour UTILITAIRE
* ACCES EXEC : chemin de l'exec pour APPLICATION
* FABRICATION : cmde de compil.ou nom de Makefile
*
* LIMITES : limites d'utilisation
* CONTRAINTES : contraintes d'implémentation
*
**************************************/

Exemple :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/**************************************
*
* NOM : video.c
* TYPE : UTILITAIRE
* SUJET : Gestion video d'un camera
*
* AUTEUR : VIEUX Nicolas
* VERSION : 0.1
* CREATION : 10/10/10
* DER. MODIF. : 10/10/10
*
* ACCES SRC : /usr/local/src/video.c
* ACCES OBJ : /usr/local/obj/video.o
* FABRICATION : gcc -Wall video.c -o video_v_0_1
*
* LIMITES : aucune
* CONTRAINTES : video.h
*
**************************************/