Zephyr (./86) :
"n'existe pas" ? qu'est-ce que tu as voulu dire par là ?
Sinon puisqu'il semble utile de l'expliquer, je pense (comme Thibaut a priori) que l'astérisque a sa place à coté du "int" puisqu'elle fait partie du type de la variable (la variable a est bien de type int*)
la variable ne s'appelle pas *a
Zephyr (./78) :
du coup je déclare jamais plusieurs variables sur une ligne
int maVariableTruc, maVariableChose, maVariableBidule;Quand les noms sont plus longs et/ou qu'il y a des assignations. (avec une tabulation, peu importe la taille, juste pour marquer que c'est la suite de la déclaration du dessus)
Nil (./89) :
Sinon, l'inconvénient de ne pas commenter le code en comptant sur sa "lisibilité", c'est quand on doit faire un debug rapide et qu'on n'a pas le temps de prendre du recul pour "voir ce que ça fait".
Avec souvent des références à l'algo en cours, c'est utile pour débugguer 
(genre donner la correspondance de chaque ligne de code avec chaque ligne de l'algo théorique)
def on_action_export_triggered(self):
file_name = KFileDialog.getSaveFileName(KUrl(), "*.png", self)
if not file_name.isNull():
file = QFile(file_name)
file.open(QIODevice.WriteOnly)
self.image.save(file, "PNG")
def on_action_color_triggered(self):
color = QColorDialog.getColor(self.pen.color(), self)
if color.isValid():
self.pen.setColor(color)
def on_action_pen_thin_triggered(self):
self.pen.setWidth(1)
def on_action_pen_normal_triggered(self):
self.pen.setWidth(2)
void Game_play(Game *this, Joypad *joypad, Graphics *graphics)
{
unsigned short current_level = 0;
Hero hero;
Hero_init(&hero, 5);
do
{
Level_init(&(this->memory->level), FileGame_getLevelData(this->file_game, current_level), &(this->memory->level_memory));
Level_play(&(this->memory->level), &hero, graphics, joypad);
if(!hero.character.alive)
hero.nb_lives--, hero.character.alive = true;
else if(!joypad->keys.quit)
current_level++;
}while(!joypad->keys.quit && current_level < this->file_game->nb_level && hero.nb_lives > 0);
}
void Level_play(Level *this, Hero *hero, Graphics *graphics, Joypad *joypad)
{
this->hero = hero;
Hero_initLevel(hero, &(this->hero_start_pos));
// On attend que le joueur soit prêt.
Joypad_waitNoKey(joypad);
unsigned short clignote = 0;
do
{
hero->visible = (clignote <= 3);
clignote = (clignote + 1) & 0x07;
Level_draw(this, graphics);
}while(!Joypad_isKeyPressed(joypad));
hero->visible = true;
// Boucle principale
do
{
Level_update(this, joypad);
Level_draw(this, graphics);
} while(hero->character.alive && !hero->escaped && !joypad->keys.quit);
}
void Level_update(Level *this, Joypad *joypad)
{
// Joypad
Joypad_update(joypad);
// Hero
Hero_update(this->hero, joypad, this);
// Holes
unsigned short i = 0;
while(i < List_count(&(this->holes)))
{
Hole *hole = List_get(&(this->holes), i);
Hole_update(hole, this);
if(hole->state == Hole_FREE)
List_remove(&(this->holes), i); // On vire le trou
else
i++;
}
// Enemies
Iterator it;
Iterator_init(&it, &(this->enemies));
while(Iterator_hasElement(&it))
{
Enemy_update(Iterator_get(&it), this, this->hero);
Iterator_next(&it);
}
}
Zephyr (./97) :
./94 : tu n'as rien prouvé ni expliqué, je reste sur les raisons données en ./86 ^^
Zephyr (./86) :
int *a; n'a pas tellement de sens
Jyaif (./105) :
faudrait faire une fonction dont le code contient une illustration de toutes les nuances d'indentation possible, à la "The quick brown fox jumps over the lazy dog".
On pourrait filer ce bout de code à un indenteur pour qu'il l'indente suivant le même style.
dualmoo (./106) :Zephyr (./86) :
int *a; n'a pas tellement de sens
Je ne comprends pas ce qui te gêne dans le fait de dire que "*a est un entier" (ou encore : "la case mémoire vers laquelle a pointe contient un entier").
For instance, as just one random illustrative example, you might need to return 2 values from a function in Java (a language with no direct support for multiple return values). Should you model it as a MyFunctionCallResult class with named ValueOne and ValueTwo fields (presumably with actual names appropriate to the problem at hand)? Or should you just return a 2-element array (possibly of mixed types) and have the caller unpack it?
Pen^2 (./108) :dualmoo (./106) :Zephyr (./86) :
int *a; n'a pas tellement de sens
Je ne comprends pas ce qui te gêne dans le fait de dire que "*a est un entier" (ou encore : "la case mémoire vers laquelle a pointe contient un entier").
Je suppose qu'il veut dire que le type, c'est "pointeur d'entier" et la variable c'est "a".
dualmoo (./111) :Pen^2 (./108) :dualmoo (./106) :Zephyr (./86) :
int *a; n'a pas tellement de sens
Je ne comprends pas ce qui te gêne dans le fait de dire que "*a est un entier" (ou encore : "la case mémoire vers laquelle a pointe contient un entier").
Je suppose qu'il veut dire que le type, c'est "pointeur d'entier" et la variable c'est "a".
Ben c'est une façon de le voir, mais l'autre façon est compréhensible aussi, non ?
dualmoo (./111) :Vaguement, oui, mais c'est moins cohérent... Je comprends ce que tu veux dire, à savoir qu'après cette déclaration, « *a » aura toujours le type entier, mais la variable que tu déclares c'est a, pas *a ; ce dernier c'est le résultat d'une opération. Alors il se trouve que c'est pas n'importe quelle opération et que si tu connais le type de *a tu peux en déduire le type de a, mais déclarer que « la case mémoire vers où pointe a contient un entier » est un peu bizarre dans la mesure où a ne pointe pas toujours vers la même case mémoire (et au moment de la déclaration ne pointe vers rien du tout). L'effet de la déclaration est bien de dire que « a contient l'adresse d'un entier », pas autre chose.
Ben c'est une façon de le voir, mais l'autre façon est compréhensible aussi, non ?
)
BiHi (./109) :For instance, as just one random illustrative example, you might need to return 2 values from a function in Java (a language with no direct support for multiple return values). Should you model it as a MyFunctionCallResult class with named ValueOne and ValueTwo fields (presumably with actual names appropriate to the problem at hand)? Or should you just return a 2-element array (possibly of mixed types) and have the caller unpack it?
Sally (./114) :
Vaguement, oui, mais c'est moins cohérent... Je comprends ce que tu veux dire, à savoir qu'après cette déclaration, « *a » aura toujours le type entier, mais la variable que tu déclares c'est a, pas *a ; ce dernier c'est le résultat d'une opération. Alors il se trouve que c'est pas n'importe quelle opération et que si tu connais le type de *a tu peux en déduire le type de a, mais déclarer que « la case mémoire vers où pointe a contient un entier » est un peu bizarre dans la mesure où a ne pointe pas toujours vers la même case mémoire (et au moment de la déclaration ne pointe vers rien du tout). L'effet de la déclaration est bien de dire que « a contient l'adresse d'un entier », pas autre chose.
Kevin Kofler (./43) :
C'est l'accolade à part qui est, sauf pour les fonctions:
void foo(void) { ... } comme prévu par K&R.
Zephyr (./61) :
L'indentation en espaces sux ^^
Lionel Debroux (./70) :
C'est une source d'ennuis, les blocs if/else, for, while sans accolades...
Kevin Kofler (./79) :
int *a; est correct, int* n'existe pas en C, la preuve, comme déjà soulevé par Zephyr, int* a, b; ne va pas faire ce que vous attendez, c'est int *a, *b; qu'il faut mettre.
Ximoon (./95) :
(c'est moche de déclarer plusieurs variables sur une même ligne)
Sasume (./103) :
Iterator it; Iterator_init(&it, &(this->enemies));
squalyl (./118) :
toutafé. C'est une perte de temps d'appuyer 8 fois sur espace quand on veut naviguer vite au clavier dans son code
typedef int* int_p;
int_p a,b;
typedef int* int_p; int_p a,b;
