Coder rapidement ?

Faire les choses correctement du premier coup, ca gagne enormement de temps!

Le C est une ecole de rigueur. Il est parfaitement possible d'ecrire un
programme qui marche du premier coup, ca reclame juste un peu de
concentration.

En fait, paradoxalement, pour 'aller plus vite', il suffit de prendre son
temps!
- ca va t'apprendre a etre plus zen
- ca va te donner confiance en toi

N'hesite pas a faire des dessins et a noter des trucs annexes sur une
feuille.

Pense a la bonne vieille technique du "je fais tourner le programme dans
ma tete sur des cas simples", ca permet d'eviter tous les bugs triviaux.
C'est bien plus facile de corriger un oubli si on essaie de faire les choses
a la main plutot que d'attendre d'etre oblige de passer par le debugguer.




Apres, en terme d'efficacite, ecrire plus vite, "cabler" les constructions
classiques dans les doigts... et savoir changer de niveau d'abstraction
(faire idiomatique): c'est normalement pas necessaire de decortiquer toutes
les boucles, parce qu'il y a certaines constructions qui sont quasiment
"de tete". Construis-toi des idiomes tout terrain, et tu peux les appliquer
sans trop reflechir ;-)

On 12/19/2014 01:54 PM, Marc Espie wrote:

Faire les choses correctement du premier coup, ca gagne enormement de temps!

Et écrire du code propre, c'est aussi bien segmenter en petites fonctions élémentaires (ie. élémentaires à débugger)
Et ne pas hésiter a user et abuser des assert(), plutôt que de passer des heures à débugger (et laisser les assert activées si elles ne sont pas trop coûteuses en mode "finale")

(Exemple imaginaire:
static int get_my_int(struct my_struct *s, int index) {
/* index shall be a positive number strictly lower than array size */
assert(index >= 0 && index < s->size);
return s->array[index];
}
...)

Le 19-12-2014, Pascal06 <toto@toto.fr> a écrit :

Seulement, même si je comprend très bien ce que nous faisons en cours,
lors des DS c'est la cata ! Je perds tout mes moyens, ou alors, je met
un temps fou à coder...
Mon prof d'info me dit que le seul moyen pour arriver à être efficace en
situation de stress, c'est de s'entrainer à coder dans un environnement
bruyant, et s'imposer un temps limité pour accomplir une tâche...

Il y a deux questions distinctes: comment être efficace en C,
et comment se concentrer en situation de stress.

Pour apprendre à gérer votre stress, je vous invite à demander
conseil à un psychologue plutôt qu'à un informaticien (qui au
mieux vous expliquera la technique qui lui sert, à lui, à gérer
son stress, à lui).

Ensuite, pour coder efficacement en C, au niveau débutant
(ie pas un énorme projet, ou la conception globale prime)
je conseille
1) découper en fonction simples, avec un nom signifiant,
des paramètres idem, et des pre/post condition instrumentées
par assert
2) compiler avec le niveau de Warning maximal (un débutant n'a
aucune raison de laisser couiner le compilo)
3) dès qu'il y a de l'allocation mémoire, faire des dessins

A part l'expérience, y a t il des méthodes pour être plus efficaces ?

Lire, demander des conseils, c-à-d profiter de l'expérience
des autres ;-)

Marc Boyer
--
"On est tout surpris, un beau soir, de trouver la satiété où
l'on cherchait le bonheur", [Beaumarchais, Mar. de Figaro, V, 7]

In article <m71ask$vut$1@news.httrack.net>,
Xavier Roche <xroche@free.fr.NOSPAM.invalid> wrote:

On 12/19/2014 01:54 PM, Marc Espie wrote:

Faire les choses correctement du premier coup, ca gagne enormement de temps!

Et écrire du code propre, c'est aussi bien segmenter en petites
fonctions élémentaires (ie. élémentaires à débugger)
Et ne pas hésiter a user et abuser des assert(), plutôt que de passer
des heures à débugger (et laisser les assert activées si elles ne
sont pas trop coûteuses en mode "finale")

(Exemple imaginaire:
static int get_my_int(struct my_struct *s, int index) {
/* index shall be a positive number strictly lower than array size */
assert(index >= 0 && index < s->size);
return s->array[index];
}

C'est un des cas ou je passe direct sur size_t, perso :)

Je vais re-insister sur l'approche "zero defaut".
La premiere fois qu'on m'en a parle, j'etais sceptique, puis j'ai essaye,
et je suis convaincu.

Au lieu d'ecrire vite, et de laisser le compilo gerer les erreurs de syntaxe
(puis le debuggueur les erreurs plus profondes), si on passe un peu plus
de temps a faire gaffe a ses ; et ses (), et a la structure logique du code,
on regagne le temps en question x10 apres.

On peut meme a nouveau se permettre de faire quelques erreurs, mais le taux
d'erreur en premiere compile est divise par (au bas mot) un facteur 10.

Faire ce genre de choses en dehors des DS peut aussi etre excellent pour
booster ta confiance en soi, et du coup faire diminuer fortement le stress...

Le 19/12/2014 13:31, Pascal06 a écrit :

Seulement, même si je comprend très bien ce que nous faisons en cours,
lors des DS c'est la cata ! Je perds tout mes moyens, ou alors, je met
un temps fou à coder...

Comment se passe un DS ? Est-ce sur écran face à l'environnement de
développement dans lequel tu as tes marques, ou est-ce sur copie, c'est
à dire un endroit complètement étranger à ce que tu pratiques au
quotidien ?

Par ailleurs, quelles sont la nature des question ? Est-ce de
l’algorithmique ou de la conception de structure de données ou autre ?

Si c'est sur une page blanche loin d'un écran, peut-être faudrait tu que
dans diverses occasions (bus, train, etc), tu t’entraine à réfléchir à
un problème informatique et que tu t'amuse à le résoudre sur papier loin
du clavier. Cet exercice purement virtuel te permettra peut-être d'etre
plus familier avec ce mode de travail dans lequel on ne fonce pas comme
un bourrin directement sur le clavier pour coder et résoudre le problème
en même temps. 1) on le résout sur papier 2) on le code rapidement 3) on
test et on a plus que des bugs mineurs à régler qui n'existent pas quand
on imagine l'algo sur le papier.

voila, c'était mes 2centimes

a+

sam.

Le 20/12/2014 18:20, Samuel DEVULDER a écrit :

Comment se passe un DS ? Est-ce sur écran face à l'environnement de
développement dans lequel tu as tes marques, ou est-ce sur copie, c'est
à dire un endroit complètement étranger à ce que tu pratiques au
quotidien ?

Par ailleurs, quelles sont la nature des question ? Est-ce de
l’algorithmique ou de la conception de structure de données ou autre ?

Bonjour Sam,
Bonjour à tous, merci pour vos précieux conseils.
Effectivement j'aurais du vous préciser la nature des DS.

Nous développons sur une machine virtuelle Linux, avec Gcc et GEdit.
Lors des DS, nous avons droit à nos cours, nos notes, et même nos
programmes perso.

La difficulté demandée est pas énorme, c'est vrai...

Lors du dernier DS, j'ai lu le sujet, et j'ai commencé par écrire les
prototypes des différentes fonctions, défini la structure employée,
déclarer les différentes variables... Rien que ça, ça m'a pris peut être
1H !

Au final, au bout des 3H, je n'avais fait que la 1ère partie du DS (il y
avait 3 parties).

Pour avoir une idée, j'ai scanné le sujet:
http://www.2plz.fr/temp/201412220951_0001.pdf
(vous noterez les touches d'humour du prof ;) )

Nous avons une phase de rattrapage en Janvier...

In article <5497e2cf$0$5134$426a34cc@news.free.fr>,
Pascal06 <toto@toto.fr> wrote:

Le 20/12/2014 18:20, Samuel DEVULDER a écrit :

Comment se passe un DS ? Est-ce sur écran face à l'environnement de
développement dans lequel tu as tes marques, ou est-ce sur copie, c'est
à dire un endroit complètement étranger à ce que tu pratiques au
quotidien ?

Par ailleurs, quelles sont la nature des question ? Est-ce de
l’algorithmique ou de la conception de structure de données ou autre ?

Bonjour Sam,
Bonjour à tous, merci pour vos précieux conseils.
Effectivement j'aurais du vous préciser la nature des DS.

Nous développons sur une machine virtuelle Linux, avec Gcc et GEdit.
Lors des DS, nous avons droit à nos cours, nos notes, et même nos
programmes perso.

La difficulté demandée est pas énorme, c'est vrai...

Lors du dernier DS, j'ai lu le sujet, et j'ai commencé par écrire les
prototypes des différentes fonctions, défini la structure employée,
déclarer les différentes variables... Rien que ça, ça m'a pris peut être
1H !

Au final, au bout des 3H, je n'avais fait que la 1ère partie du DS (il y
avait 3 parties).

Pour avoir une idée, j'ai scanné le sujet:
http://www.2plz.fr/temp/201412220951_0001.pdf
(vous noterez les touches d'humour du prof ;) )

C'est largement faisable en 3h... il y a deux/trois trucs que je n'aime
pas trop dans le sujet. L'utilisation de typedef, inutile dans ce cas.
Les noms de variables qui sont pas trop idiomatique dans mon idee. Les
accents dans les commentaires (mais c'est vrai que ces jours-ci ca marche).
Ah, et il y a une typo sur un des proto "in ttc" -> "int tc".

Je ne sais pas si c'est volontaire de specifier que int ajouteCommandeTableau
renvoie -1 quand c'est plein... et on sait pas quoi sinon.

(et je n'appelerais JAMAIS cette fonction comme ca. Elle est censee
s'appeler "ajouteCommande", le fait que ca soit dans un *tableau* est
un detail d'implementation).

Cote style, melanger du "saisieCommande" et "ajouteCommande" est aussi tres
tres bof (verbe vs nom).

Ca manque de const dans les char *, mais peut-etre que vous ne les avez
pas encore vues ?

Perso, je n'abregerai ni Emetteur, ni Destinataire.

Les fonctions sont, de facon generale, extremement mal nommees.

On ne nomme *jamais* une fonction "calculMachin", on l'appelle "Machin"
(la encore, ce sujet melange details d'implementation et fonctionnalites,
c'est a croire que ton prof n'a jamais vraiment appris a programmer
structure).

Il devrait donc y avoir une fonction "montantTotal".

Et la fonction "commandesParEm" s'appelerait sans doute
"afficheCommandesParEmetteur" chez moi.

D'ailleurs j'aurais plutot un
"afficheCommandes"
avec un parametre "filtre" qui sera sans doute un objet contenant un pointeur
de fonctions et des parametres, mais bon, ca c'est moi.

Et je ne vois pas trop l'interet de lui faire renvoyer un float... ou alors
on fait des fonctions valise. Si on affiche des trucs, autant lui faire
afficher le total egalement.

Le 22/12/2014 11:28, Marc Espie a écrit :

C'est largement faisable en 3h...

Je trouve aussi. C'est assez direct, avec aucune algorithmique complexe,
sauf à la limite le II.10 avec un tri sélection, mais qui se fait
facilement à partir des fonctions précédemment écrites.

il y a deux/trois trucs que je n'aime pas trop dans le sujet.

Tsss.. quand on est élève on a pas le droit de critiquer la façon de
coder du prof.. Toi tu peux le faire, tu es de l'autre coté de la
barrière :p

Et je ne vois pas trop l'interet de lui faire renvoyer un float...

Et d'ailleurs pourquoi un float ? Le type flottant standard en C est
double et pas float. Le float est encore plus imprécis que le double, or
quand on fait de la compta il ne faut pas faire d'erreur de décimale et
chacun sait que 0.10 ne se représente pas bien exactement en flottant
binaire.

http://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/

Pour le coup, il aurait mieux valu travailler en centimes d'euros et
stocker les prix sur un entier. Avec des entiers non signés 32bits, on
serait limité à un total des cadeaux de noël un peu inférieur à
43Miliards par clients. Ca doit être suffisant pour l'exercice. Sinon
passer à 128bits en codant des primitives d'addition et d'affichage
d'entier 128bits à partir d'entier 32bits :D

a+

sam.

In article <54989a52$0$2128$426a34cc@news.free.fr>,
Samuel DEVULDER <samuel-dot-devulder-at-laposte-dot-net> wrote:

Le 22/12/2014 11:28, Marc Espie a écrit :

Et je ne vois pas trop l'interet de lui faire renvoyer un float...

Et d'ailleurs pourquoi un float ? Le type flottant standard en C est
double et pas float. Le float est encore plus imprécis que le double, or
quand on fait de la compta il ne faut pas faire d'erreur de décimale et
chacun sait que 0.10 ne se représente pas bien exactement en flottant
binaire.

Ouais. float vs double est sujet a legere controverse. C'est moins le cas
depuis... la norme ISO, donc 89. Evidemment, on est des vieux, donc on a
connu avant. Mais l'arithmetique "float" existe, et tu peux tomber sur
des environnements qui la gerent "comme un type standard a part entiere".

Pour le coup, il aurait mieux valu travailler en centimes d'euros et
stocker les prix sur un entier. Avec des entiers non signés 32bits, on
serait limité à un total des cadeaux de noël un peu inférieur à
43Miliards par clients. Ca doit être suffisant pour l'exercice. Sinon
passer à 128bits en codant des primitives d'addition et d'affichage
d'entier 128bits à partir d'entier 32bits :D

Ca par contre, tu peux effectivement bosser en entier. Et il n'y a rien
a coder. Tu peux decemment refuser de compiler sur une machine qui n'a pas
de type int64_t, voire int32_t.

Sauf si tu prends le pere Noel comme emetteur, ca va passer sans souci
avec int32_t, et ca passera toujours avec int64_t.

(mais bon, ca c'est des remarques qui correspondent a des points un peu
specifiques au C... alors que typiquement, mes remarques sur les noms
de fonctions sont des trucs de base, et ne pas apprendre tres vite a
ecrire des proto const correct me semble une aberration totale aujourd'hui)