# Conventions ## Code Suivre le clang format. ### Magic_value ```c #define MAGIC_VALUE 255 ``` ### Gestion des structs #### Nommage fonctions associes \<struct_name\>\_\<action\>(\<struct\_name\> *arg, ...) Separation des definitions des structures dans un .h et des fonctions associees dans un autre .h pour eviter les includes circulaires my_struct_struct.h ```c struct my_struct { int attribut_name; }; ``` my_struct_fuction.h ```c void my_struct_create(void); ``` #### Struct Parametrique Structure utilise si une fonction a plus de 4 args. - Alloue sur la stack => pas de fonctions associes. params_<function_name> ```c struct params_foo { char *name1; char *name2; char *name3; char *name4; }; void foo(struct params_foo in, bool out); ``` ### Gestion des erreurs Le type de renvoie n'est que dans les paramatres. Cela permet d'avoir un type d'erreur a la remonte. ```c typedef int error_t; #define UNREACHABLE -1 #define NO_ERROR 0 #define ERROR_SOMETHING 1 #define ERROR_SOMETHING_ELSE 2 error_t foo(..., int *out); error_t bar(T other_args); ``` #### Remonter une erreur de maniere securise ```c // utils/error.h //free_count premier = ptr to free et apres c pour le format error_t error_callback(error_t error, int free_count, const char *format, ...) { free_all(free_count premier, ...); vfprintf(stderr, va_args); return error; } error_t foo(void) { void *ptr2 = calloc(1, 2); if(!ptr2) return error_callback(ERROR_SOMETHING, 1, "msg", ptr2); ... return NO_ERROR; } ``` ### Gestion des pointeurs #### Definition Si une fonction retourne un pointeur alors le dev doit definir une duree de vie dans la description dans le .h Maximiser l'allocation puis la liberation dans la meme fonction. #### Liberation Pour eviter les erreurs du type: ... On definit un override de la fonction free() de la libc. ```c // utils/memory.h void free_unset(void **p) { if(!p) return; free(*p); *p = NULL; } void free_all(size_t count, ...); ``` #### Autres - Favoriser la duplication plutot que le partage de ptr - pas de malloc que des calloc ### Fonctions #### Nommage \<action/verb\>_<desc\>() ```c char *get_token(); char *peek_token(); ``` ### Commentaire - pas hesiter a //TODO //FIXME - Commentaire recommande dans le .h afin de maximiser la comprehension de la fonction. ## Gestion GIT - Branch - Commit ### Branch - Pour l'implem principale: 1 branch 1 feature - Sinon situationnelle ### Commit Base sur le [site](https://graphite.com/guides/git-commit-message-best-practices) suivant. Resume: ```sh <type>(<scope>): <description> <type>: - feat: Introduces a new feature. - fix: Patches a bug. - docs: Documentation-only changes. - style: Changes that do not affect the meaning of the code (white-space, formatting, etc). - refactor: A code change that neither fixes a bug nor adds a feature. - perf: Improves performance. - test: Adds missing tests or corrects existing tests. - chore: Changes to the build process or auxiliary tools and libraries such as documentation generation. ``` Regex associe: ``` ^(build|chore|ci|docs|feat|fix|perf|refactor|style|test)(\([^()]*\))?!?: [^:\n]*(\n\n(\n|.)*)?$ ``` ## Methode de Dev Essayer de suivre les regles suivantes. Il y a bien sur des cas expectionnels. 1. Ecriture du .h + visualisation d'un pseudo algorithme 2. Ecriture du tests unitaires associes aux fonctions 3. Ecriture du corps de la fonction