CREATION D'EMAILS
xstyled
Messages postés
38
Date d'inscription
jeudi 18 mai 2006
Statut
Membre
Dernière intervention
17 février 2009
-
17 févr. 2009 à 14:43
cs_exar Messages postés 286 Date d'inscription vendredi 5 décembre 2003 Statut Membre Dernière intervention 22 avril 2012 - 23 févr. 2009 à 14:10
cs_exar Messages postés 286 Date d'inscription vendredi 5 décembre 2003 Statut Membre Dernière intervention 22 avril 2012 - 23 févr. 2009 à 14:10
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/49286-creation-d-emails
https://codes-sources.commentcamarche.net/source/49286-creation-d-emails
23 févr. 2009 à 14:10
J'avais mal compris... J'avais interprété cela comme "compile en créant un exécutable plus rapide"...
Mea culpa...
23 févr. 2009 à 12:07
Votre remarque ne m'étonne pas et je l'attendais !
Elle prouve déjà que vous avez tout lu et cette seule remarque est tout à fait
justifiée car, si beaucoup de gens utilisent des compilateurs, peu ont eu l'occasion d'en écrire un.
Dans un compilateur, la première phase importante est l'analyse du texte pour en
extraire les mots et déterminer ensuite s'il s'agit d'un nom de variable, d'un
littéral ou d'une instruction.
L'analyse lexicale nécessite de traiter les caractères un par un pour isoler
chaque mot. De ce fait, la présence d'un espace (sauf à l'intérieur d'un littéral)
marque la fin d'un mot, lequel sera alors traité par une autre fonction qui va tester
s'il s'agit d'une instruction ou non.
C'est pour cette raison qu'un nom tel que "fin de page" doit être écrit
"fin_de_page" pour ne pas provoquer une erreur.
Un programme de 1000 lignes peut donc comporter plus de 10000 mots (un simple
signe tel que '<' en est un pour l'analyseur) et, si on économise ne serait-ce qu'une
microseconde par mot, c'est toujours cela de gagné !
Certes, vous allez me dire que, avec les machines modernes, cela ne sert à rien,
comme je l'ai souvent entendu dire par mes élèves (et même par d'autres professeurs !).
C'est vrai que les machines modernes sont de plus en plus puissantes mais cela
n'est pas une raison pour écrire n'importe comment.
Si vous devez un jour programmer pour un microcontrôleur qui tourne à 4MHz, vous
verrez que chaque microseconde gagnée est importante.
C'est un peu la même chose en Formule1 ou chaque gramme gagné peut donner la
victoire !
Vous avez le droit de ne pas être de cet avis (et ne serez pas le seul) mais je
pense que, quand on écrit des programmes et que, en plus, on ose les proposer à une
communauté de programmeurs, il est mieux de bien écrire, pour soi même d'abord, et
pour ceux qui liront votre contribution.
Cordialement,
JPR
23 févr. 2009 à 11:11
"au lieu de: for (i=0,j=0;i<100;i++) préférer: for (i 0,j 0;i < 100; i++)
c'est la même chose mais cela se lit mieux et se compile plus vite ! "
Compile plus vite ??? Peux-tu en dire plus ? Le compilateur tient maintenant compte des espaces ????????
23 févr. 2009 à 11:06
L'idée est sans doute bonne mais l'écriture rend le programme illisible !
Pourquoi toutes ces lignes blanches, ces tabulations anarchiques, les accolades illisibles car mal placées, etc ?
Un tel programme sera difficile à maintenir, surtout par celui qui ne l'aura pas écrit.
L'administrateur a raison de dire que ce programme ne sera pas conservé car ce n'est pas un exemple à suivre.
Quand je vois un programme qui commence, en ligne 1, par un #include, c'est déjà un mauvais signe car c'est tellement
mieux quand on trouve un commentaire qui explique clairemet (et sans fautes d'orthographe, SVP !) ce que fait le
programme.
Quand vous reprendrez ce "programme" dans 6 mois, vous aurez du mal à vous y retrouver.
Et encore, je n'insiste pas sur les instructions inutiles ou mal choisies (par exemple, un "switch" au lieu d'un
troupeau de "if" !
Quant aux tests (instructions "if", entre autres), il est souhaitable d'écrire les instructions conditionnées
sur d'autres lignes avec un certain retrait (tabulation) qui montre que ces instructions ne sont pas systématiques.
Malheureusement, je constate que les programmes présentés sont, la plupart du temps, mal écrits et je finirai par
envoyer un jour un exemple de programme, copieusement commenté, pour donner quelques idées à tous ceux qui voudraient
écrire des programmes (qui fonctionnent, bien sûr) agréables à lire.
Un bon programmeur doit être un peu fénéant afin de ne pas écrire 36 fois la même chose !
Par exemple, pourquoi tous ces "printf" avec le même contenu alors qu'il suffit de définir une variable avec ce
contenu (exemple dans le menu) ?
Un lecteur parle aussi des noms de variables mal choisis et il a raison !
Sans aller jusqu'à la mode "Windows" (noms de variables de 30 caractères !), il est assez facile de donner des noms
plus clairs que 'j', 'k', etc...
Enfin, si le programme doit être facile à lire pour une personne, il est bien de faciliter aussi le travail du
compilateur en ne collant pas bêtement tous les mots, ce qui donne un paquet de chiffres et de lettres difficile à
lire:
au lieu de: for (i=0,j=0;i<100;i++)
préférer: for (i 0,j 0;i < 100; i++)
c'est la même chose mais cela se lit mieux et se compile plus vite !
Pour les accolades, il est judicieux de mettre celle qui ferme avec le même décalage que celle qui ouvre aulieu
de les mettre toutes à la même position !
Cela facilite la recherche des erreurs et facilite la lecture ... et l'écriture !
Paul Valéry a dit: "La liberté nait de la plus grande rigueur",
ce qui devrait concerner tous ceux qui pratiquent l'informatique, aussi bien en tant qu'utilisateur ou en tant que
programmeur !
Bon courage !
23 févr. 2009 à 09:03
Vous pouvez détaillez cette méthode pour éviter d'utiliser tant de printf, ça m'interesse beaucoup.
18 févr. 2009 à 23:52
18 févr. 2009 à 11:15
Quelques petites remarques:
* pense à utiliser des noms "parlants" pour tes variables et paramètres de
fonctions (pour moi c, cc, i, j, k, tr, tr1, ... c'est du message codé: à quoi
sert tout ça ?)
* au lieu d'effectuer des tests "if" en série sur une même variable, pense au
switch()
* commente un peu plus ton code, parce qu'il y a des tests partout, mais on ne
sait pas ce qu'ils vérifient vraiment
Bonne continuationn !
17 févr. 2009 à 15:03
17 févr. 2009 à 14:56
17 févr. 2009 à 14:48
17 févr. 2009 à 14:43