Discussion :

[lastrecrue]

je voudrais apprendre a programmé en C.
j'ai déjà des connaissance de base, mais je cherche quelque conseil qui me permettent de mieux avancé, alors si on veut avoir un bon programmé en C, quel sont les chose nécessaire a faire et ne pas faire.

[PRomu@ld]

e voudrais apprendre a programmé en C.

Qu'appele tu programment en C ? Le langage C est un outil, un bon programmeur doit savoir bien programmer et bien programmer, c'est connaitre et savoir utiliser à bon escient des algos, ensuite le langage Utilisé n'est là que pour transcrire les algos ...

j'ai déjà des connaissance de base

Ou t'es tu arrêté ?

quel sont les chose nécessaire a faire et ne pas faire.

Connaître ses limites est une bonne chose ! Ne pas essayer de bidouiller le code et savoir exactement ce que l'on fait est une bonne chose, ensuite, il y a des règles à bien suivre : bien nommer ses variables, effectuer des tests à chaque appel système, bien séparer les programmes en modules indépendants, éviter les "trucs" de hackers qui font gagner un cycle d'horloge sur dix minutes de calculs et produire du code le plus simple possible (plus c'est simple plus c'est facile à maintenir)

[gnto]

salut,

Je crois que l'algorithmie est très importante.
Connaitre les structures avancées c'est pas mal par exemple pourquoi utiliser une liste plutot qu'un tableau ?

Et a part certains points l'echelle du goret me semble un bon indicateur
echelle du goret
C'est très exhaustif !!

[lastrecrue]

j'ai regarder votre echelle de goret je n'ai pas compris ces points:
que signifie cette phrase "Utilisation d'expressions C non idiomatiques ".
quand on a pas le choix"Plus d'un return par fonction ".

ma question n'était pas la, je me pose la question si je vais faire un long programme, comment puise je etre sur que je ne vais pas devoir tous refaire après que je dépasse une centaine de ligne, quand je doit utiliser une macro, quand faire une fonction, comment découpé mon programme en plusieurs fonction sans perdre de son efficacité, est ce que une fonction qui appelle plusieurs fonction est une mauvaise chose, quand je doit faire pus d'un fichier, voila ce genre de question.

[PRomu@ld]

'ai regarder votre echelle de goret je n'ai pas compris ces points:
que signifie cette phrase "Utilisation d'expressions C non idiomatiques ".
quand on a pas le choix"Plus d'un return par fonction ".

On en a parlé il n'y a pas si longtemps que cela et il en était ressorti que cette échelle était issue d'expérience purement personnelle et que certain points étaient presque discutables . D'ailleurs, j'ai l'occasion quelque fois de coder comme un goret en programmation système. (Emmanuel, je ne veux pas relancer la discution ... )

Je ne pense pas que c'est un document qui peut t'aider. En revanche, les notes sont très utiles :

http://emmanuel-delahaye.developpez.com/notes.htm

Ensuite les conventions de codage sont tout aussi importantes (même si tu n'es pas obligé de respecter scrupuleusement tout ceci, ça reste indicatif)

http://emmanuel-delahaye.developpez.com/codage.htm

Pour finir avec les liens sur le site d'Emmanuel, je te recommande aussi ceci :

http://emmanuel-delahaye.developpez.com/complog.htm

je me pose la question si je vais faire un long programme, comment puise je etre sur que je ne vais pas devoir tous refaire après que je dépasse une centaine de ligne

En fait qu'appelle tu tout refaire ? En fait, ça n'est pas à cause du langage que tu devra tout refaire, c'est de la conception, et ça, ça ne se fait pas devant un clavier et un écran, c'est avec un papier et un crayon. Il faut absolument que lorsque tu code, ça ne soit que la dernière étape. Que tu n'ai pas à réfléchir sur l'agencement entre les modules. Parce que si cette reflexion se fait pendant que tu codes, tu es quasiment sur de faire n'importe quoi et produire du code qui ne sera pas bon.

quand je doit utiliser une macro, quand faire une fonction

Pour répondre à ces questions, il faut comprendre que les macros sont des éléments du préprocesseur et donc d'un simple analyseur de texte. Les fonctions appartiennent au langage. c'est le code qui sera compilé. Alors quand choisir entre l'un et l'autre ? Bonne question ! En fait, une macro c'est pour regrouper une ou deux instructions assez simple (MIN, MAX, ...), ou alors des instruction assez répétitives (allocations mémoire et vérification). Ensuite, il y a les personnes qui ne font que des macros ... ( même en cours, on a eu l'occasion de faire une liste chainée générique entierement avec les macros ...) mais, ça n'est pas une bonne chose parce que c'est long à écrire et mon lisible quavec des fonctions. Comme je te l'ai dis au premier post, privilégie la simplicité. Si tu dois passer une heure à écrire une macro, vérifier les effets de bords éventuels, c'est trop long (sauf si tu en vois une utilité primordiale pour ton programme).

comment découpé mon programme en plusieurs fonction sans perdre de son efficacité

Le cout d'un appel de fonction est on va dire assez dérisoire et il existe des mécanismes pour les éviter (inline et compagnie). Ca rejoint ce que je t'ai dis au premier post : si c'est pour gagner quelques cycles d'horloge sur un temps d'éxécution significativement plus long, ça n'est pas la peine. En revanche, si ta fonction est très courte, là utilise une macro.

Tout est une question de conception de tes programmes, il faut regrouper dans une fonction des instructions permettant d'effecuer une action bien définie (par exemple tu regroupes toutes les insttructions pour calculer une racine carrée dans une fonction racine).

De plus, tu as l'air d'avoir toujours en tête des problèmes de performance. Il faut savoir que l'optimisation est une des dernières phases du développement : tu fais quelque chose de fonctionnel dans un premier temps, tu utilise un profiler pour savoir quels sont les fonctions qui prennent le plus de temps et tu regarde ensuite comment les optimiser. Si tu commences par l'optimisation en premier, tu ne sauras pas quel est la partie qui ne fonctionne pas ; ton programme de base ou ton optimisation.

Mais n'oublie pas, l'optimisation par le langage de programmation ne représente qu'une infime partie de ton optimisation. La majeure partie de l'optimisataion concerne le choix des algos. Un tri par tas non optimisé (optimisations compilateur et langage) sera plus rapide qu'un tris par insertion optimisé sur un jeu de donnée assez conséquent.

est ce que une fonction qui appelle plusieurs fonction est une mauvaise chose

Non pas du tout, le langage C est un langage de fonction, alors utilises les ! Quand tu dois effecter des E/S sur un fichier, tu ouvres le fichier, tu écrit ou tu lis dedans, et tu finis par le fermer, tout est fait avec des appels de fonction ...

quand je doit faire pus d'un fichier,

Un fichier par module indépendant. Tu ne fais pas un fichier par fonction. Tu regroupes sous un même fichier des fonctions qui ont la même utilité : fonctions mathématiques, fonction d'E/S. Pour ceci inspire toi de ce qui est fait dans la bibliothèque standard.

[skip78]

si je vais faire un long programme, comment puise je etre sur que je ne vais pas devoir tous refaire après que je dépasse une centaine de ligne

Non sinon pour être à l'aise en programmation, un seul mot d'ordre : l'expérience

Si tu as le courage de te pencher sur un tuto, tu lis les bases et tu code toi même tous les programmes exemples.
Une fois que tu as toutes les bases, entraine toi à creer toi même tes petits programmes, puis quand tu seras fin prêt, étudie une API quelconque, par exemple pour developper un petit jeu, et si tu te fait plaisir, tu prendra la main

[millie]

Il m'est déjà arrivée de coder un gros programme assez salement, puis qq mois (ou même pas), le recommencer complétement avec une nouvelle vision (plus pratique, plus performante, plus PROPRE). C'est vraiment qqch qui m'a bien permis de progresser. Pour des gros programmes, au début, c'est pas toujours facile de toujours prévoir tout d'avance, on fait des erreurs, on corrige assez salement, et au final, ça marche mais ce n'est pas terrible. Mais on peut analyser après coup toutes les erreurs qu'on a fait pour ne plus les faire la fois d'après.

Donc, l'expérience...