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. grin

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.

2

Pour le formatage du code, c'est à toi de voir.

Moi j'écris qq chose dans le genre de
int proto( int a, char b )
{
   if ( a == 25 ) {
      int huhu= 0 ;
      invokeFunc(0, 2) ;
   }
   return a ;
}

En gros, ça se rapproche du K&R.
J'aime bien la dissymétrie autour de l'affectation ^^

Autre réponse :
le mieux est de déclarer ses variables au plus proche de l'endroit où elles sont utilisées. Mais en C tu es forcé de les déclarer en début de portée (après l'accolade), donc... Pouvoir déclarer n'importe où est un avantage du C++

Encore une autre réponse :
Tu peux faire une structure globale avec toutes tes variables globales à l'intérieur. Ça a l'avantage de ne faire qu'un relogement, tout en t'évitant de passer un argument qui ne sert à rien dans toutes tes fonctions (j'avais lu cette astuce ici, d'un post de squale92 je crois...)

3

Toi, tu ne sais pas dans quoi tu t'aventures là grin
Le mieux est encore de prendre ses propres habitudes, il n'y a rien qui soit meilleur qu'autre chose au final...
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. grin

En ce qui me concerne, je trouve la seconde solution plus claire et lisible : j'aime bien pouvoir identifier mes blocs au premier coup d'œil.


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) ?


trifus
Bon, j'imagine que tu dois savoir qu'on ne peut pas déclarer de variable en plein milieu du code, mais seulement en début de bloc ? grin

Si tu parles de trucs du genre "for(int i =0; i<truc; i++)", je trouve ça horrible, et d'un moint de vue maintenance du code c'est du suicide.
95% de mes variables sont déclarées en début de fonction, et ça me permet d'éviter de chercher trois heure qui est déclaré où. Parfois (par exemple sur certains blocs "for") je déclare des variables locales à ces blocs, mais c'est relativement rare.


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.


Personnellement, je préfère n'utiliser aucune variable globale, et en effet passer en paramètre des variables déclarées dans les fonctions de plus haut niveau. Pas forcément une structure énorme contenant tout, ceci dit. Mais un code bien construit doit, à mon sens, limiter ce genre de nécessité.
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

4

Personne ne sera sans doute d'accord, mais :
1/ je préfère le premier (une ligne inutile de moins)

2/ en principe le standard C (ou en tous cas les vieilles versions, mais j'ai continué par habitude) ne te permet de déclarer les variables qu'en début de bloc (ie juste après une accolade ouvrante). Même si ça n'est peut-être pas obligatoire avec tigcc, ça reste plus lisible à mon avis que d'avoir des déclarations en plein milieu du code ^^. (Note que tu peux ouvrir un bloc à n'importe quel moment, pas besoin que ce soit dans une boucle, un if ou autre, et l'utilité est justement d'introduire des variables locales à ce bloc).

Déclarer les variables avec le plus petit scope possible permet normalement de repérer plus d'erreurs (il va râler si tu utilises la variable à l'extérieur du bloc, par exemple parce que tu t'es trompé de nom de variable...)

Pour ta question technique : ben tu te réponds à toi-même non ? cheeky il n'y a pas spécialement de bonne raison de préférer les variables globales. (Dans foblub je fous des variables globales dans des registres, mais c'est un peu particulier, c'est parce que c'est une machine virtuelle et que ces variables sont utilisées absolument tout le temps. Edit : accessoirement je fais aussi comme a dit Pen^2, j'utilise en fait une grosse structure dont l'adresse est dans un registre ^^. Mais je fais ça à coups de #define #triloveoui#).
avatar
« Le bonheur, c'est une carte de bibliothèque ! » — The gostak distims the doshes.
Membrane fondatrice de la confrérie des artistes flous.
L'univers est-il un dodécaèdre de Poincaré ?
(``·\ powaaaaaaaaa ! #love#

5

[edit] gros cross

Pour la première question, je ne suis pas sûr qu'il y ait de réponse valable. 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. Tant que tu programmes pour toi-même, profite au maximum de cet énorme avantage qui est de pouvoir choisir tes propres conventions smile
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

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 confus
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

Pas de mal chapo (mad vtff embarrassed)
Mais par contre ça m'étonne, parce que j'ai le souvenir que tu avais dit que tu utilisais un format simulaire à Thibaut et il me semble qu'il utilise un format pas si éloigné de ce que je fais grin (genre la dissymétrie de l'affectation c'est lui qui me l'avait conseillée)
Et pour le reste, c'est du K&R pour autant que je m'en souvienne !

7

Merci à tous pour vos réponses, tant mieux si j'ai de la latitude pour agir en effet, j'ai déjà choisi mes préférences. grin
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 ^^).

Tu fais comment pour être sûr de ça ? Comment "parles-tu" au compilateur pour être sûr qu'un registre pointe sur ta structure, ie que quand tu passeras l'adresse de ta structure en argument aux fonction, ça ne génêrera en fait pas de code inutile, vu que le registre servira globalement dans le programme ?

8

./6 : Ah ? Je ne me souviens plus exactement du style de Thibaut mais il me semble que ça n'était pas très différent de ce que j'utilise habituellement. Pour moi, en gros ça donne :

- Accolades ouvrantes et fermantes seules sur leurs lignes, et indentées au même niveau (comme le 2eme exemple de Folco)
- Indentation avec des tabulations (souvent à 4 espaces), pas avec des espaces
- Déclaration des noms de variables et de fonctions alignées, avec une variable par ligne
- Espaces autour des opérateurs binaires, les assignations ne font pas exception : plop = array[i] + (5 * step);
- 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);
- 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;
- Blocs logiques dans le code séparés par une ligne vide

Au final ça ressemble à ça : http://www.mirari.fr/Ql0m (pas de code C sous la main ^^)
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

9

<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;
}




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.


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

(et mettre trois espaces par tab est impardonnable)
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

10

./7 asm ("d7");
 > Comme ça :register word *stack_base asm ("a4");
register byte *base_ptr asm ("a3");
register long pc_offset
dans un fichier .h qui est inclus par tous les fichiers source. Alors pourquoi a4 et a3 ? je ne me souviens plus avec certitude mais il me semble que a5 est utilisé par une certaine option de tigcc, que je voulais activer (genre il y stocke l'adresse d'AMS et il s'en sert pour faire tous les ROM calls).
Si tu veux voir la partie correspondante de mon .h en entier :
mon code
/* 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)
[...]
Bon la principale raison pour laquelle tout est fait à coups de define, c'est qu'avant ça j'utilisais des variables globales ordinaires — d'ailleurs en fait je n'ai pas tout écrit, je suis parti d'un code existant —, et ce hack m'a en fait permis de passer à l'adressage indirect via la structure sans changer le code (c'est une optimisation après coup, quoi ^^)

edit : c'est beau les tab à trois espaces trilove (par contre l'idéal c'est d'utiliser le caractère tab et de le régler visuellement à trois espaces, pas de taper les trois espaces ^^)
avatar
« Le bonheur, c'est une carte de bibliothèque ! » — The gostak distims the doshes.
Membrane fondatrice de la confrérie des artistes flous.
L'univers est-il un dodécaèdre de Poincaré ?
(``·\ powaaaaaaaaa ! #love#

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 confus
pencil
Et justement, un nom de variable insignifiant comme « i » est très bien pour un compteur de boucles.
(genre la dissymétrie de l'affectation c'est lui qui me l'avait conseillée)
Ah, et ça apporte quoi ? Moi je trouve que ça fait mal aux yeux.
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;
pencil
Ximoon (./9) :
note : - il serait mieux de faire "(MACRO_QUI_VA_BIEN == B)" mais je n'arriverai jamais à m'y faire.
Pourquoi ?
- ne jamais utiliser les types standard.
Pourquoi ?
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

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. Pour la première par contre, il y a tout un tas de raisons possibles et aucune ne m'a jamais vraiment convaincu ^^
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

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 confus
pencil
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.
Sasume (./11) :
Ximoon (./9) :
note : - il serait mieux de faire "(MACRO_QUI_VA_BIEN == B)" mais je n'arriverai jamais à m'y faire.
Pourquoi ?


Parceque si tu te plantes et oublies un "=", tu auras une erreur de compilation. Ceci dit, c'est discutable, et les compilateurs modernes font des warnings sur ce genre de syntaxe.
Donc en ce qui me concerne, j'ai laissé tomber.
Sasume (./11) :
- ne jamais utiliser les types standard.
Pourquoi ?


Parce que les types standards, à part le char, ne sont pas réellement définis par la norme (et que tout compilateur ne respecte pas forcément la norme : j'ai déjà vu des char sur 16 bits), et en tout cas, ne sont pas portables. Le seul moyen de savoir réellement avec quoi on travaille est donc de redéfinir des types personnalisés autant de fois qu'on a de cibles et de n'utiliser que ceux-ci.
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

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 ?
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

15

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 confus
pencil
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.
Les itérations de la boucle. Mais je crois comprendre ce que tu veux dire. En fait, la variable i ne devrait pas être utilisée dans le corps de la boucle.

Ok, pour les autres points, merci.
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

16

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

pencil mais mon chef m'a forcé à utiliser des espaces cry (par contre, trois espaces c'est juste bien je trouve, ça découpe bien sans prendre trop de place : 4 ça fait déjà beaucoup)
Zephyr (./8) :
- Déclaration des noms de variables et de fonctions alignées, avec une variable par ligne

alignement je ne fais pas, mais je suis parfois tenté. Par contre, une par ligne, oui, je pencil.
Zephyr (./8) :
- Espaces autour des opérateurs binaires, les assignations ne font pas exception : plop = array[i] + (5 * step);

pareil (sauf pour les affectations)
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);

Ben justement, c'est pas une histoire de logique, c'est juste que ça permet de bien différencier au premier coup d'oeil embarrassed
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;

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

pencil

17

Ah bon, c'est pas si différent que ce que je croyais alors ^^
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

18

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 ?

Tu peux les utiliser si tu veux, vu que ce ne sont justement pas les types standard.
Mais tu présupposes que ce header existe pour toutes les cibles du monde, moi, pas grin (et leurs types ne correspondent pas à mes standards d'appellation de types, mais ça n'a rien à voir grin)



Sinon, pour "i", si elle ne fait strictement rien d'autre que compter, ok, mais perso je préfère des trucs plus verbeux.
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

19

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


Pourquoi pas des espaces ?
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

20

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

au contraire, un index qui ne sert que dans la boucle n'a rien à faire dans la portée du dessus (pkoi pas une variable globale tant qu'on y est embarrassed)
'Et ce n'est pas moi qui ai choisi le i tongue)
De toutes façons, il suffit d'utiliser un itérateur et puis voilà embarrassed
Sasume (./11) :
Ah, et ça apporte quoi ? Moi je trouve que ça fait mal aux yeux.

ben ça déséquilibre l'expression vers la variable qui reçoit l'affectation, mais bon c'est juste une question d'habitude, comme le reste, d'ailleurs grin

21

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

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


Pourquoi pas des espaces ?

C'est beaucoup plus chiant à gérer, parfois problèmes d'alignement si tu effaces une espace sans faire gaffe (pas toujours facile à voir qu'il manque une espace avec un décalage de quelques lignes par exemple.)
On s'y fait si c'est pas trop mal géré par l'éditeur, mais je préférais aussi les tab love

22

Merci pour tous vos conseils ! Je ne savais pas qu'il y avait tant à discuter en effet. Merci beaucoup à Bob pour ses explications détaillées et argumentées !

23

Ca vous arrive d'écrire :
if (condition) machin;

ou alors vous préférez :
if (condition)
    machin;

?

24

Perso j'écris toujours le premier, le deuxième c'est un coup à oublier les accolades si jamais tu veux rajouter quelque chose d'autre dans le if. (Par contre rien ne t'empêche de mettre des accolades même quand il n'y a qu'une instruction, bien sûr, mais parfois c'est un peu lourd.)
avatar
« Le bonheur, c'est une carte de bibliothèque ! » — The gostak distims the doshes.
Membrane fondatrice de la confrérie des artistes flous.
L'univers est-il un dodécaèdre de Poincaré ?
(``·\ powaaaaaaaaa ! #love#

25

Moi j’écris souvent :
if(condition)
{
  instruction;
}


[edit] parfois, pour gagner un peu de place :
if(condition) { instruction; }
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

26

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

Parceque si un mec passe derrière moi et qu'il a des goûts étranges (indenter avec une largeur de 3 caractères par exemple ^^), un code source avec des tabulation sera lisible pour lui (son éditeur affichera des tabulations avec la largeur qu'il aura configuré).

Certes, il existe des éditeurs qui sont capables de changer la taille des indentations même si elles ont été faites avec des espaces, mais c'est quand même se compliquer sacrément la tâche plutôt que d'utiliser tout simplement le caractère qui justement est prévu pour ça ^^
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

27

Le comble de l'atrocité, c'est quand même l'indentation automatique d'emacs avec les options par défaut (Dieu merci ça se désactive, mais comment ont-ils pu tricoler au point de seulement avoir l'idée de ce système pourri ? cheeky)
Pour ceux qui ne savent pas, ça mélange les tabs et les espaces tritop, et donc c'est totalement dépendant de la largeur du tab, je crois que par défaut la tab vaut 8, donc au premier niveau d'indentation il insère deux espaces, au second quatre, au troisième six, et au quatrième... tab trigic (et au cinquième tab+2 espaces etc.) Et comme c'est le mode par défaut, si t'es pas au courant... sick
avatar
« Le bonheur, c'est une carte de bibliothèque ! » — The gostak distims the doshes.
Membrane fondatrice de la confrérie des artistes flous.
L'univers est-il un dodécaèdre de Poincaré ?
(``·\ powaaaaaaaaa ! #love#

28

yep les fichiers source tapés sous emacs et ouverts avec un vrai éditeur de code (c'était gratuit embarrassed) ensuite, c'est toujours un vrai bonheur grin
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

29

Je suis d'accord avec les autres: à toi de trouver ta propre convention, tant qu'elle ne t'est pas imposée wink
Par exemple, je pense que le 'if (cond) {' sur la même ligne est une question de goût. En revanche, le '} else {' ne me paraît pas bon pour la lisibilité (c'est moins facile de trouver le "else").
c'est moche, c'est tout, une déclaration de type de variable n'a rien à faire dans un for tongue

Ben, il me semble me souvenir que c'est comme ça en Pascal et Ada, non ?
Au moins, ça empêche de faire le truc très moche, parce qu'impossible à porter entre des compilos différents et éventuellement entre des versions du même compilo (il me semble que ce n'est pas garanti par le standard, et heureusement ^^), qui consiste à utiliser la valeur d'une variable d'itération principale hors du corps de la boucle grin

./23: pour moi, les if sans { } sont à bannir absolument. C'est une source de bugs subtils qui peuvent difficiles à trouver, venant de la transformation, un jour où tu es fatigué / pressé, de
if (val)
    une_seule_expression;

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

alors que tu voudrais écrire
if (val) {
    une_seule_expression;
    une deuxième expression;
}

Ce n'est pas hypothétique: j'ai déjà corrigé une occurrence de
if (val)
    une_seule_expression;
    return;
// !!! ici, il y a du code non atteignable !!!

au boulot. L'erreur "unreachable code" n'avait pas été détectée pour cause de warnings trop bas...


Les espaces et tabs mélangés, c'est vraiment TROP bien trioui
(mais quand tu viens après le début d'un projet qui a été formatté avec les pieds, tu peux être obligé de respecter ce format et d'écrire du nouveau code à ce format. En effet, faire des changements whitespace pur met des modifications fonctionnellement inutiles dans l'historique des commits, et complique donc la recherche de qui pourrait être compétent dans un morceau de code donné.)

Ni emacs ni vi, même leurs versions améliorées (vim, etc.), ne sont de vrais éditeurs de texte, de toute façon grin
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

30

Lionel Debroux (./29) :
./23: pour moi, les if sans { } sont à bannir absolument etc.
Ben sauf si tu respectes la convention (à laquelle je pensais en ./24, c'était peut-être pas clair) :
SOIT if (machin) une_seule_expression; *sur une seule ligne*
SOIT if (machin) {
tralala
}
autrement dit la seule chose qui pour moi est à banir absolument c'est les if sans accolades où tu vas à la ligne après le if ; les if sans accolades sur une seule ligne ça va encore ^^
avatar
« Le bonheur, c'est une carte de bibliothèque ! » — The gostak distims the doshes.
Membrane fondatrice de la confrérie des artistes flous.
L'univers est-il un dodécaèdre de Poincaré ?
(``·\ powaaaaaaaaa ! #love#