Techniques générales de programmation en C - Page 1

if (condition){
  <du code>
}

if (condition)
{
  <du code>
}

int proto( int a, char b )
{
   if ( a == 25 ) {
      int huhu= 0 ;
      invokeFunc(0, 2) ;
   }
   return a ;
}

Folco (./1) :
Je me pose pas mal de question quant à la mise en forme du code d'une part, et quant aux choix techniques à faire d'autre part.

Déjà, pour la mise en forme :
Convient-t-il mieux d'écrire :

if (condition){
  <du code>
}

ou

if (condition)
{
  <du code>
}

J'imagine que les années d'habitude ont donné de bonnes raisons de choisir une méthode ou l'autre, mais moi j'ai pas l'habitude.

Autre question :
Vaut-il mieux déclarer toutes les variables en début de fonction, ou les déclarer quand on va en avoir réellement besoin (par exemple, si une variable donnée n'a d'utilité qu'à un petit endroit donné de la fonction) ?

Encore une autre question, relevant plus d'un choix technique :
Vaut-il mieux avoir des variables globales (que TIGCC fout dans des BSS, et j'aime pas ça), ou mieux vaut-il avoir une structure dans main() les contenant et passer un pointeur en argument aux fonctions qu'on appelle ? J'ai choisi cette solution. Je penche plus pour la seconde solution, ayant l'habitude d'avoir ces variables sur la pile en ASM, et ayant un registre d'adresse global pointant vers ce frame et permettant à toutes les fonctions de voir ces variables.

Ximoon (./3) :
Si tu parles de trucs du genre "for(int i =0; i

Zephyr (./5) :
Par exemple le format proposé par pen^2 m'apparait comme un condensé de fautes de style (désolé ^^) et c'est très probablement réciproque

( )

Sally (./4) :
Edit : accessoirement je fais aussi comme a dit Pen^2, j'utilise en fait une grosse structure dont l'adresse est dans un registre ^^).

<début du fichier, un fichier par fonction >
<includes utilisés *directement* par la fonction, et rien qu'eux>
<cartouche décrivant la date, l'auteur, les I/O, les révisions, les fonctionnalités et algos, les variables globales et les constantes utilisées>

/* description rapide de la fonction */
Error_Code_t pref_Proto (
        /* INPUTS */
        /* Description rapide de b */
        Byte_t      B,
        /* OUTPUTS */
        /* Description rapide de a */
        Int_Ptr_t   *A_Ptr)
{
    /* Variables */
    /* Variable locales de sortie */
    UInt_t  A;
    /* Variable truc */
    UInt_t  Huhu;

    /* Explication sioux */
    if (B == MACRO_QUI_VA_BIEN)
    {
        /* Note : cette variable ne sert à rien */
        Huhu = 0;
        
        /* Explication de l'appel */
        pref_Invoke_Func (
                /* INPUTS */
                MACRO_QUI_VA_BIEN_AUSSI,
                MACRO_QUI_VA_BIEN_ENCORE);
    }

    /* Mise à jour des sorties */
    *A_Ptr = A;
    
    /* Pas d'erreur */
    return OK;
}

 > Comme ça :register word *stack_base asm ("a4");
register byte *base_ptr asm ("a3");
register long pc_offset

/* Pour éviter au maximum les variables globales j'en remplace certaines par des macros. */

#define data_head (*(header_t*)base_ptr)
#define objd_obj_base (base_ptr + data_head.object_o)
[...]
#define global_ptr (base_ptr + data_head.variable_o)
#define common_word_ptr (base_ptr + data_head.common_word_o)
#define vocab (base_ptr + data_head.vocab_o)

/* Et je mets les autres dans une structure... */

#include <graph.h>

typedef struct {
  word        *stack;
  byte        *prog_block_ptr;

[...]

} structure_magique_t;


#ifndef NO_GLOBAL_REGISTER_VARIABLES
register word *stack_base asm ("a4");
register byte *base_ptr asm ("a3");
register long pc_offset asm ("d7");
#else
extern word *stack_base;
extern byte *base_ptr;
extern long pc_offset;
#endif

#define structure_magique ((structure_magique_t*)stack_base)
#define stack (structure_magique->stack)
#define prog_block_ptr (structure_magique->prog_block_ptr)
[...]

Pen^2 (./6) :

Ximoon (./3) :
Si tu parles de trucs du genre "for(int i =0; i

? ben au contraire, ça réduit la portée du i, je ne vois pas le problème

(genre la dissymétrie de l'affectation c'est lui qui me l'avait conseillée)

Zephyr (./8) :
- Astérisque (ou & pour le C++) collé au type et non à la variable (ça caractérise le type d'une variable, pas son nom) : int* a = &b;

Ximoon (./9) :
note : - il serait mieux de faire "(MACRO_QUI_VA_BIEN == B)" mais je n'arriverai jamais à m'y faire.

- ne jamais utiliser les types standard.

Sasume (./11) :

Pen^2 (./6) :

Ximoon (./3) :
Si tu parles de trucs du genre "for(int i =0; i

? ben au contraire, ça réduit la portée du i, je ne vois pas le problème

Et justement, un nom de variable insignifiant comme « i » est très bien pour un compteur de boucles.

Sasume (./11) :

Ximoon (./9) :
note : - il serait mieux de faire "(MACRO_QUI_VA_BIEN == B)" mais je n'arriverai jamais à m'y faire.

Pourquoi ?

Sasume (./11) :

- ne jamais utiliser les types standard.

Pourquoi ?

Zephyr (./12) :
À propos de la deuxième remarque de Ximoon, je suppose que c'est pour pouvoir changer facilement un type de données (int 16 bits -> int 32 bits par exemple) dans le programme en modifiant juste un "typedef" dans un header.

Ximoon (./13) :

Sasume (./11) :

Pen^2 (./6) :

Ximoon (./3) :
Si tu parles de trucs du genre "for(int i =0; i

? ben au contraire, ça réduit la portée du i, je ne vois pas le problème

Et justement, un nom de variable insignifiant comme « i » est très bien pour un compteur de boucles.

Sauf que ça ne te dit pas ce que tu comptes.

Zephyr (./8) :
- Indentation avec des tabulations (souvent à 4 espaces), pas avec des espaces

Zephyr (./8) :
- Déclaration des noms de variables et de fonctions alignées, avec une variable par ligne

Zephyr (./8) :
- Espaces autour des opérateurs binaires, les assignations ne font pas exception : plop = array[i] + (5 * step);

Zephyr (./8) :
- Espaces avant la parenthèse ouvrante des appels de fonction (je trouve illogique d'en mettre pour les mots-clés et pas pour les appels) : result = function (a, b);

Zephyr (./8) :
Astérisque (ou & pour le C++) collé au type et non à la variable (ça caractérise le type d'une variable, pas son nom) : int* a = &b;

Zephyr (./8) :
Blocs logiques dans le code séparés par une ligne vide

Sasume (./14) :

Zephyr (./12) :
À propos de la deuxième remarque de Ximoon, je suppose que c'est pour pouvoir changer facilement un type de données (int 16 bits -> int 32 bits par exemple) dans le programme en modifiant juste un "typedef" dans un header.

Mais pourquoi serait-on amené à faire ça ? Quid de stdint.h et inttypes.h ?

Zephyr (./8) :
- Indentation avec des tabulations (souvent à 4 espaces), pas avec des espaces

Ximoon (./9) :
Pen² > c'est moche, c'est tout, une déclaration de type de variable n'a rien à faire dans un for D'ailleurs, elle devrait avoir un nom plus explicite que "i"

Sasume (./11) :
Ah, et ça apporte quoi ? Moi je trouve que ça fait mal aux yeux.

Zephyr (./17) :
Ah bon, c'est pas si différent que ce que je croyais alors ^^

Ximoon (./19) :

Zephyr (./8) :
- Indentation avec des tabulations (souvent à 4 espaces), pas avec des espaces

Pourquoi pas des espaces ?

if (condition)
    machin;

if(condition)
{
  instruction;
}

Ximoon (./19) :
Pourquoi pas des espaces ?

c'est moche, c'est tout, une déclaration de type de variable n'a rien à faire dans un for

if (val)
    une_seule_expression;

if (val)
    une_seule_expression;
    une deuxième expression;

if (val) {
    une_seule_expression;
    une deuxième expression;
}

if (val)
    une_seule_expression;
    return;
// !!! ici, il y a du code non atteignable !!!

Ni emacs ni vi, même leurs versions améliorées (vim, etc.), ne sont de vrais éditeurs de texte, de toute façon

Lionel Debroux (./29) :
./23: pour moi, les if sans { } sont à bannir absolument etc.