youp,
 
 
je voulais savoir comment bien programmer.
 
J'ai un peu apris la programmation à l'école, mais j'ai jamais fait de projets "sérieux".
 
 
Donc, si vous pouviez me dire ce qu'il faut faire pour par exemple :
 
-la gestion des erreurs
-optimiser (j'ai lu je sais plus dans quel topic qu'il y avait des programmes qui faisaient ca (???))
-... (tout conseil sera le bienvenu )
 
 
 
merci

->se trouver une convention d'ecriture de code et s'y tenir
->choisir un mecanisme de gestion d'erreur, et s'y tenir
->ne pas optimiser trop tot
 
 

a propos d'optimisation:
pensez vousqu'il vaut mieux avoir une approche      globale
d'un projet puis affiner au fur et a mesure ou au contraire
plancher en detail partie par partiedes le debut?

L'optimisation, ca se fait a la fin!
Sinon, on ne s'en sort plus...
Je pense donc qu'il vaut mieux avoir une approche globale, pour répondre a ta question.

En C, éviter d'utiliser les types intégrés (int, char, long...). Il vaut mieux se créer ses propres types "logiques" (typedef). Par exemple on n'écrira pas "int id1;" mais "id_t id1". Le type doit indiquer ce qu'est la variable (un id), pas comment elle est stockée (dans un int). Ca permet aussi d'éviter d'accumuler les "*" devant les noms de variables : on écrira "client_t client1" plutôt que "struct client *client1".
 
Ne jamais utiliser dans le code de constantes numériques. Se faire plutôt un #define (enfin sauf pour 0 et 1, suivant le contexte : pour le compteur d'une boucle on peut évidemment écrire 0, mais si ce 0 a une signification précise, par exemple le nombre minimal de threads en attente dans un pool, là il faut un #define).
 
Faire des fonctions courtes. Si une fonction dépasse la centaine de lignes, c'est sans doute qu'il faut en créer une nouvelle. Evidemment ça dépend aussi de la complexité de la fonction : si tu a un très long switch avec à chaque fois des opérations élémentaires, personne ne t'en voudra si elle fait 800 lignes. Une indicateur simple de la complexité d'une fonction pourrait être le niveau maximum d'indentation. Si du code est indenté plus de mettons 4 fois, ça devient trop compliqué.
 
Eclater le code dans plusieurs fichiers. Les fichiers ne devraient jamais être très longs. Deux fonctions qui rendent des services tout à fait différents (coeur de l'algo et affichage par exemple) n'on rien à faire dans le même fichier.
 
Et mettre beaucoup de commentaires. En-tête au dessus de chaque fonction avec un petit commentaire sur ce qu'elle fait, les arguments qu'elle attend, ce qu'elle renvoie, les variables globales qu'elle utilise, les variables globales qu'elle modifie. Plus plein de commentaires dans le code, mais des commentaires utiles (pas de "/* i <- 2 */" ). Et aérer le code.  
 
Pour la présentation du code c'est suivant tes préférences, mais il y a quelques règles à respecter. Essayer de tenir dans 80 colonnes. Tabulation à 8 caractères (l'argument "mais après ça déborde" ne tient pas, cf. plus haut). Type de la valeur de retour d'une fonction sur une ligne à part (ça permet de coller le nom de la fonction à gauche, ce qui facilite les grep). Par exemple :

tabulation à 8  
moi j'en mets 3, et je mets des espaces au lieu des tabs
(habitude du Pascal, où on ne met même que deux caractères)

Ah et puisqu'on parle d'optimisatio plus haut, attention. L'optimisation du code c'est avant tout l'algo. Après c'est l'ordre des instructions pour éviter de casser le pipeline, et pour permettre la vectorisation.
 
Par contre toutes les "optimisations" du genre "je fait << 2 plutôt que * 4", c'est à éviter absolument. Ca rend le code moins lisible, et de toute façon le compilo génerera exatement le même code dans les deux cas (avec un décalage de bits). De même, dans une expression arithmétique, ne pas hésiter à laisser les calculs intermédiaires sur les constantes, si ils permettent de mieux comprendre le calcul : on ne gagne rien en écrivant "x * 192" plutôt que "x * (128 + 64)". Les calculs sur les constantes seront fait au moment de la compilation, le code généré sera le même.
 
Et un conseil : ne perd pas de temps à optimiser à fond toutes tes fonctions. Utilise un profiler pour voir où le temps est perdu, et concentre toi sur ces endroit : ne perd pas une journée à optimiser une fonction qui prend 1% du temps. Un profiler c'est fait pour ça, et on est parfois surpris du résultat.

antp : si tu utilise des espaces pour indenter le code, tu peux mettre la largeur que tu veux, pas de problèmes (par contre moi je l'indiquerait en en-tête du fichier quand même). Mais si tu utilises les tabulations, alors elles doivent faire 8 caractères, point. L'usage veut qu'il en soit ainsi, et toute autre valeur donera un code mal aligné chez 90% des développeurs.

antp a écrit a écrit : tabulation à 8   moi j'en mets 3, et je mets des espaces au lieu des tabs (habitude du Pascal, où on ne met même que deux caractères)

 
heuh, ouais, 8 ca fait quand meme bpc

De toutes façon, chez moi, la touche tab donne : "insère moi (ou supprime) le bon nombre d'espaces pour avoir un code correctement indenté"

 
dans l'absolu je preconise putot l'emploi d'espace que de tabs (question de formatage). D'ailleurs VC (et surement bpc d'autre) permettent de remplacer les tabs par des espaces. C pas mis par defaut, mais cocher le titi n'est pas une mauvaise idée

Pourquoi les espaces a la place des tabulations? Je trouve les tabulations plus pratiques, moi! Qu'est-ce que j'ai loupé pour penser ca?

Parce que les tabs, c'est paramétrable dans la plupart des éditeurs.

 
ben le pb c le melange espace/tab qui survient assez souvent
 
si jamais toi tes tabs sont a 5 (exemple inside) et que tu passes chez un type chez qui c a 3, ca risque de devenir un gros foutoir (truc mal indenté tout partout)
 
avec les espaces, rien de cela

moi je mets 2 espaces comme indentation  

ok merci
 
 
 
c'est quoi un profiler exactement ? (je veux des noms aussi !!! (pour c++))
 
et aussi, que conseillez vous comme debugger ?
 
 
merci

 
ca te fait tourner ton programme pendant un certain temps
puis ca te dit dans quelle fonction ton programme a passe
le plus de temps.
Certains profilers avances te donnent aussi des informations
plus precises comme le nombre de stall en attente de l'OS, d'une ressource partagee, d'un cache miss, du CPU (quand il s'agit d'un GPU) etc.. Tres utile en cours de developpement
pour voir qu'on va dans le mur et qu'il faut changer son fusil
d'epaule. Ou en fin de developpement pour gagner quelques cycles
sur une execution.
 
Il y en a un integre dans Visual C++ 6 et ulterieur.
Le plus utilise sur plateforme intel est VTune produit
par Intel lui meme.
 

 
Utilise celui de ton environnement de developpement. S'il ne te convient pas ou si tu ne trouves pas de doc convenable dessus songe a changer d'environnement de developpement.
 
LeGreg

art_dupond a écrit a écrit : youp,     je voulais savoir comment bien programmer.   J'ai un peu apris la programmation à l'école, mais j'ai jamais fait de projets "sérieux".     Donc, si vous pouviez me dire ce qu'il faut faire pour par exemple :   -la gestion des erreurs -optimiser (j'ai lu je sais plus dans quel topic qu'il y avait des programmes qui faisaient ca (???)) -... (tout conseil sera le bienvenu )       merci

 
lis des livres sur le génie logiciel, t'aura de très bonne base ainsi

Copier/coller de la rubrique bibliolinks C++ (anglais requis):
Teach Yourself Programming in Ten Years
The seven secrets of successful programmers
How To Write Unmaintainable Code
Optimization: Your Worst Enemy
 
Comment Poser Les Questions De Manière Intelligente
How to Report Bugs Effectively
I need help with my homework!
 
Interface Hall of Fame/Shame
 
Recommended C Style and Coding Standards.
C++ Coding Standard
The Ten Commandments for C Programmers (Annotated Edition)
 

C'est énormément une question de préférence.
Il me semble que plus un programmeur a tapé de code, plus il a tendance à raccourcir.
 

Pareil...
Ça fait plusieurs fois que j'entends recommender les espaces au lieu de tabulations, et je n'y prétais pas trop attention tellement les tabulations coulent de source pour moi.
A un point tel que je n'envisageais même pas d'expliquer pourquoi.
Il semble qu'il va bien falloir pourtant...
 

Justement, cela permet à celui qui visionne le code de paramétrer l'indentation qu'il préfères.
 

Je crois que voilà le coeur de problème: Il ne faut pas les confondre.
La tabulation sert uniquement pour l'indentation correspondant à l'imbrication logique du programme.
Les espaces servent uniquement pour les alignements manuels esthétiques.
 
L'alignement par espaces sert à grouper, mettre en évidence et rendre plus lisible les éléments similaires.
Il ne faut pas aligner des choses n'ayant pas la même imbrication, elle n'ont rien à faire ensemble.
 
Exemple:

Ainsi mis en forme, du code survit à un changement de taille de tabulation.
Et je rajoute que d'indenter avec des tabulations à l'avantage de ne pas permettre des demi-indentations par erreur.