Spécification de codage du langage c intégré

Les étudiants qui étudient l'embarqué doivent d'abord maîtriser la spécification de codage embarqué, afin d'améliorer le système embarqué.

Expliquons la spécification de codage c embarqué à partir de ces aspects.

Style de commentaire, style de composition, style de fichier d'en-tête, définition de variable, définition de macro, fonction

Style 1 commentaire

1.1 Le principe des commentaires est de faciliter la lecture et la compréhension du programme, et les commentaires ne doivent être ni trop nombreux ni trop peu nombreux. Le langage des commentaires doit être précis, compréhensible, concis et sans ambiguïté.

1.2 Le code d'en-tête du fichier programme doit être commenté. Les commentaires doivent indiquer : déclaration de copyright, numéro de version, date de génération, auteur, contenu, fonction, relation avec d'autres fichiers, journal des modifications, etc. Il devrait également y avoir une brève description de la fonction function dans les commentaires du fichier d'en-tête.

/*

* Copyright(C), 2007-2008, Red Hat Inc. // Avis de copyright

* Nom du fichier : // nom du fichier

* Auteur : // auteur

*Version : // version

* Date : // Date d'achèvement

* Description : // Décrivez la fonction de ce fichier et la relation avec les autres modules

* Liste des fonctions : // Une liste des fonctions principales, chaque enregistrement doit inclure le nom de la fonction et une brève description de la fonction

* Historique : // Historique des modifications, y compris la date de chaque modification, la personne qui l'a modifiée et une brève description du contenu modifié

*/

1.3 L'en-tête de la fonction doit être annoté, énumérant la fonction, les paramètres d'entrée, les paramètres de sortie, la valeur de retour, la relation d'appel, etc. de la fonction.

/*

* Fonction : // nom de la fonction

* Description : // Description de la fonction fonction, performance, etc.

* Appels : // Liste des fonctions appelées par cette fonction

* Called By : // Liste des fonctions appelant cette fonction

* Entrée : // Description du paramètre d'entrée, y compris la fonction de chaque paramètre

* Sortie : // Description du paramètre de sortie, renvoie parfois certaines valeurs variables via des paramètres de pointeur

* Return : // Description de la valeur de retour de la fonction

* Autres : // Autres instructions

*/

1.4 Pour toutes les variables, constantes, macros, structures et autres structures de données ayant des significations spécifiques, si leurs noms ne sont pas entièrement explicites, ils doivent être déclarés avec des commentaires pour expliquer leurs significations réelles. Les commentaires pour les variables, les constantes et les macros doivent être placés au-dessus ou à droite d'eux.

1.5 Les variables globales doivent avoir des commentaires plus détaillés, y compris les fonctions, les plages de valeurs, les fonctions qui y accèdent et les précautions à prendre lors de l'accès.

1.6 Afin que la composition du programme soit soignée et facile à lire et à comprendre, les commentaires doivent également être mis en retrait et alignés.

void example_function( void )

{

     /* commente un */

     unsigned int min_port, max_port ;

     /* commentaires deux */

     si ...

}

1.7 Ajouter un commentaire à droite de la ligne de fin d'un bloc de programme complexe pour indiquer la fin d'un bloc de programme.

Exemple:

si (...)

{

    ...

    alors que ( ... )

    {

      ...

    } /* tandis que ( ... ) l'instruction de boucle se termine */

     ...

} /* fin de if (...) fin de l'instruction */ 

2 styles de typographie

2.1 Des lignes vides doivent être ajoutées entre des blocs de programme relativement indépendants et après les déclarations de variables.

int conn_fd ;

int ret;

conn_fd = socket(AF_INET, SOCK_STREAM,0);

si (conn_fd < 0) {

    erreur("création de socket");

}

2.2 Les blocs de programme doivent être écrits dans un style indenté, et l'indentation doit être de 4 espaces ou d'une touche de tabulation.

2.3 Pour les phrases plus longues (plus de 80 caractères), elles doivent être écrites sur plusieurs lignes, et les nouvelles lignes doivent être indentées de manière appropriée pour rendre la composition soignée et les phrases lisibles. Les fonctions avec de longs paramètres doivent également être divisées en plusieurs lignes.

ret = connect(conn_fd, (struct sockaddr *)&serv_addr, 

                  sizeof (struct sockaddr));

2.4 N'écrivez qu'une seule déclaration sur une seule ligne et il n'est pas permis d'écrire plusieurs déclarations courtes sur une seule ligne.

Les déclarations suivantes ne sont pas canoniques :

min_port = 1 ; max_port = 65535 ;

Il doit être écrit comme suit :

min_port = 1 ; 

max_port = 65535 ;

2.5 Les instructions telles que if, for, do, while, case, switch et default occupent chacune une ligne, et la partie de l'instruction d'exécution de if, for, do, while et d'autres instructions doit être entre crochets { }, quel que soit le nombre .

Les déclarations suivantes ne sont pas canoniques :

if (conn_fd < 0) perror("socket create");

Il doit être écrit comme suit :

si (conn_fd < 0) {

     erreur("création de socket");

}

2.6 '{' et '}' doivent être sur une seule ligne

pour (i=1; i<argc; i++)

{

     ...

}

Ou dans le code, '{' va avec l'instruction for, et il doit y avoir un espace avant '{'.

pour (i=1; i<argc; i++) {

     ...

}

2.7 Utilisation des espaces

(1) Ajoutez un espace après la virgule dans l'instruction suivante.

     int min_port, max_port ;

(2) "+", "-", "*", "=" et les autres opérateurs arithmétiques ont un espace des deux côtés.

     un = je + j ;

(3) "<", ">=" et les autres opérateurs de comparaison ont un espace des deux côtés.

     si (conn_fd < 0) {

(4) "!", "~", "++", "--", "&" (opérateur d'adresse) et les autres opérateurs unaires n'ajoutent pas d'espaces avant et après.

     je++ ;

(5) Il n'y a pas d'espaces avant et après "->" et ".".

     portinfo.min_port = i * seg_len + 1 ;

3 Définition des variables

3.1 Les noms de variables doivent être clairs et clairs, avec des significations claires et utiliser des mots complets ou des abréviations que tout le monde peut comprendre pour éviter les malentendus.

Exemple:

Temp peut être abrégé en tmp

le message peut être abrégé en msg

3.2 Pour le nommage des variables, il est interdit d'utiliser un caractère unique (tel que i, j, k) Il est recommandé qu'en plus d'avoir une signification spécifique, il puisse également indiquer son type de données, etc., mais i, j , k sont autorisés comme variables de boucle locale.

int iwidth; // i indique que la variable est de type int, width indique la largeur

3.3 Sous Linux, les noms de variables sont généralement tous en minuscules et soulignés.

Usage général:

int min_port ;

Généralement non utilisé :

int minPort ;

3.4 Lors de l'utilisation de variables globales dans des programmes multithread, il convient de prêter attention à l'atomicité des opérations sur les variables.

3.5 Il faut éviter que les variables locales aient le même nom que les variables globales.

3.6 Il est strictement interdit d'utiliser des variables non initialisées comme rvalues. Dans un programme C, faire référence à un pointeur non assigné provoque souvent le plantage du programme.

Le code suivant provoquera une erreur sous Linux car : il est faux d'opérer p_string sans pointer sur un certain espace mémoire.

char *p_string;

p_piqûre[0] = 'a' ;

Il doit d'abord être initialisé :

char *p_string;

p_string = (char *)malloc(BUFF_SIZE); // suppose ici que BUFF_SIZE est défini

p_piqûre[0] = 'a' ;     

4 Définition des macros

4.1 Utilisez moins de constantes littérales dans le code et utilisez plutôt des macro constantes.

4.2 Les noms de macro doivent être en majuscules autant que possible lors de la définition des macros

4.3 Si le nom de la macro se compose de plusieurs mots, ajoutez _ entre chaque mot

#define BUFF_SIZE 1024

input_data = (char *)malloc(BUFF_SIZE);

4.4 Lorsque vous utilisez des macros pour définir des expressions, des parenthèses complètes doivent être utilisées.

Il existe certains risques associés aux macros définis comme suit :

#define GET_AREA(a,b) a*b

doit être défini comme :

#define GET_AREA(a,b) ((a)*(b))

4.5 S'il y a plusieurs instructions dans une macro, ces instructions doivent être entourées d'une paire d'accolades.

Dans l'instruction suivante, seule la première expression de la macro est exécutée.

#define INTI_RECT_VALUE( a, b )\

    un = 0;\

    b = 0 ;

pour (indice = 0 ; indice < RECT_TOTAL_NUM ; indice++)

             INTI_RECT_VALUE( rect.a, rect.b );

L'utilisation correcte doit être :

#define INTI_RECT_VALUE( une, b ) {\

            un = 0;\

            b = 0;\

}

pour (indice = 0; indice < RECT_TOTAL_NUM; indice++) { 

          INTI_RECT_VALUE( rect[index].a, rect[index].b );

}

5 définition de fonction

5.1 Une fonction complète une fonction spécifique et ne doit pas essayer de réaliser plusieurs fonctions non liées dans une seule fonction.

5.2 Vérifiez la validité de tous les paramètres d'entrée de la fonction, par exemple si le paramètre de pointeur est vide et si le paramètre de membre de tableau est hors limites.

5.3 La taille d'une fonction doit être limitée à 200 lignes (hors lignes vides et lignes de commentaires).

5.4 La fonction de la fonction doit être prévisible, c'est-à-dire que tant que les données d'entrée sont les mêmes, elle doit produire la même sortie attendue.

5.5 Les paramètres de la fonction ne doivent pas être trop nombreux, de préférence 1-3.

5.6 Le nom de la fonction doit décrire avec précision la fonction de la fonction, et il est généralement nommé sous la forme d'un verbe et d'un objet.

void print_record( struct *p_record, int record_len) ;

5.7 La valeur de retour de la fonction doit être claire et claire, de sorte que l'utilisateur ne soit pas facile d'ignorer la condition d'erreur. La signification de chaque valeur de retour d'erreur de la fonction doit être claire et claire pour empêcher les utilisateurs d'abuser, de comprendre les erreurs ou d'ignorer les codes de retour d'erreur.

5.8 Si plusieurs morceaux de code font la même chose à plusieurs reprises, vous devriez envisager d'implémenter la fonctionnalité répétitive en tant que fonction.

5.9 Réduire les appels récursifs de la fonction elle-même ou entre fonctions.

Les appels récursifs, en particulier les appels récursifs entre fonctions (comme A->B->C->A), affectent l'intelligibilité du programme ; les appels récursifs occupent généralement plus de ressources système (comme l'espace de la pile) ; Le test n'est pas bon.

6 styles de fichier d'en-tête

6.1 Le fichier d'en-tête peut enregistrer le contenu suivant : définition de macro, définition de type, définition de structure, déclaration de variable, déclaration de fonction

    N'ont pas les éléments suivants : définition de variable, définition de fonction

6.2 Les fichiers d'en-tête doivent avoir des restrictions d'inclusion en double

#ifndef _ALPS_H

#define _ALPS_H

...

#fin si

L'Internet des Objets embarqué a besoin d'apprendre beaucoup. Ne vous trompez pas d'itinéraire et de contenu, ce qui fera augmenter votre salaire !

Partagez un forfait de données avec tout le monde, environ 150 G. Le contenu d'apprentissage, les écritures face à face et les projets qu'il contient sont relativement nouveaux et complets ! (Cliquez pour trouver un petit assistant à recevoir)

Je suppose que tu aimes

Origine blog.csdn.net/m0_70911440/article/details/131654443
conseillé
Classement