Langage C : Débutant

Bonsoir à tous,

J'apprends depuis peu le langage C dans les études supérieures et j'ai remarqué que je mettais beaucoup de temps à réfléchir et que j'avais du mal en fait à trouver l'ensemble, l'idée dans laquelle s'orienter pour un programme dit !

J'aurais aimé connaître vos avis là-dessus, faites parler votre expérience pourrait-on dire ..

On a pas mal d'exercices à faire en TP par exemple, et, à chaque fois j'ai beaucoup de difficultés à savoir comment faire ...

Si une ou plusieurs personnes ici sont disponibles pour éventuellement parler programmation en C etc ... ce ne serait pas de refus ! :)

Merci,

Citation:

---

Envoyé par rromain

Bonsoir à tous,

J'apprends depuis peu le langage C dans les études supérieures et j'ai remarqué que je mettais beaucoup de temps à réfléchir et que j'avais du mal en fait à trouver l'ensemble, l'idée dans laquelle s'orienter pour un programme dit !

J'aurais aimé connaître vos avis là-dessus, faites parler votre expérience pourrait-on dire ..

On a pas mal d'exercices à faire en TP par exemple, et, à chaque fois j'ai beaucoup de difficultés à savoir comment faire ...

---

Arf, domaine très vaste. Qui n'est pas forcément lié au C mais qui porte un nom bien à lui: algorithmie => art de convertir un problème (ou sa solution) en instructions élémentaires compréhensibles par la machine.

Il y a des cours qui existent... mais l'algorithmie passe quand-même par une phase personnelle qui ne peut pas s'apprendre. On "sent" le truc (ou on ne le sent pas).

Et cette sensation déborde d'ailleurs bien au delà de l'informatique. Par exemple, mon prof de piano, quand il se lâche, part sur une partition puis il rajoute des notes à lui. Par exemple d'un coup sur un accord (comme sol majeur => sol, si, ré) lui il rajoute une sixième (mi). Moi, je regarde ses mains et je demande "mais pourquoi là une sixième". Il me répond "ben je le sentais". Et ça tombe super bien. Et quand moi je me lance sur la tablature et que je décide d'enrichir un accord avec une sixième, ben moi ça tombe à coté et ça sonne dégueu.

Donc tout ça pour t'expliquer qu'au delà des mathématiques qui sous-tendent un algorithme, il y a aussi une part intuitive (qui pourrait même s'apparenter à une espèce d'art). Par exemple tu as un TP (j'aimerais bien que tu nous en donnes un qu'on puisse développer). Ben il faut que tu arrives à "voir" dans ta tête les datas telles qu'elles sont. Ainsi tu pourras imaginer comment t'organiser pour aller choper la bonne. Ensuite tu convertis ton image en instructions. Mais comme je l'ai dit, c'est un coté un peu "personnel" qu'on ne peut pas ni expliquer, ni apprendre...

Je rejoins ce que Sve@r à dit. Programmer, concevoir un programme, etc... s'apparente à de l'art et pour moi s'en ai pas moins, c'est véritablement un art.

Bien sûr, certaines facultés peuvent se développer avec le temps et surtout l'expérience dans la programmation, surtout du point de vue de la conception. Si les TP proposés sont pile dans les choses que tu as appris en cours, lorsqu'on te poses un problème pose toi certaines questions :

• Y a-t-il besoin d'entrées utilisateur ? Si oui tu peux devoir entrevoir une ou plusieurs fonctions de traitement de saisie, ca nous fait déjà un premier module
• Si l'exercice est par exemple (restons très simple), de faire un programme qui tri une liste de noms. Tu sais déjà qu'il te faut une liste, hop ca te fait un second module qui va gérer ta liste. Il te faudra également des fonctions de tri par rapport au problème posé, ca peux éventuellement te faire un troisième module.
• Pour rester dans l'exemple précédent, la liste est-elle fournie par le biais d'un fichier ou d'une saisie utilisateur, si c'est un fichier bin hop un module qui va charger tout ca dans ta liste en lisant le fichier ligne par ligne par exemple et tout va rejoindre tes modules précédents

Ceci n'est qu'un simple exemple pour te montrer qu'il faut que tu visualises non pas directement comment faire le programme mais déjà comment il va fonctionner, il faut que tu arrives à voir le produit fini, comme un cuistot ou un plombier, ils ne commencent rien sans savoir par avance où il vont aller et comment ce sera une fois fini !

Une fois que tu visualise le programme et son fonctionnement, essaye de penser comme je l'ai décrit plus haut, il faut décortiquer le programme en plusieurs modules (unités de compilation) pour qu'il soit plus simple à maintenir et surtout à lire. Une fois que as ces différentes parties tu peux commencer par écrire les fonctions primaires dont tu as besoins et que les autres fonctions auront également besoin, faut commencer au plus bas et au plus simple.

Si on reprend l'exemple précédent, disons que tu maîtrise les saisies, commence par ce côté, tu auras plus vite terminé et tu auras plus de temps pour te concentrer sur le réel problème posé qui est le tri qu'une liste, la saisie qui te permettra en outre à tester par la suite le reste du programme en entrant le nom du fichier à charger dans la liste pour la trier. Rien qu'en lisant ce que doit faire le programme, tu peux déjà voir une hiérarchie, il faut visualiser et organiser de façon hiérarchique !


Je vais arrêter là sinon faudra plusieurs pages :aie: Si tu as d'autres questions n'hésite pas mais ne t'inquiète pas, ca viendra avec le temps et l'expérience aussi, même si c'est aussi un peu une question de feeling :mouarf:

Bonjour,
Tout à fait d'accord avec les 2 réponses précédentes.
Autrefois, il n'était pas question d'écrire un programme sans avoir fait un organigramme.
Chaque étape est dessiné dans une boite de forme conventionnelle. La première boite contient le mot Début, celle tout en bas de la feuille, contient Fin. Cette méthode a l'avantage de permettre de voir d'un seul coup d'œil la totalité du programme. J'ai vu de tels organigrammes de 2 mètres de long qu'il fallait naturellement accrocher à un mur.
Il est bon aussi d'écrire, en fançais, la suite des opérations à réaliser, si c'est assez linéaire.
Il ne faut jamais oublier que le codage, c'est à dire la programmation, doit ne dépendre que du langage utilisé, et non de la logique de développement. Cela veut dire que lorsque l'analyse est faite, on peut (ou on pourrait) confier le codage à un spécialiste du langage utilisé. Mais il est bien évident que "coder" fait partie de l'expérience nécessaire.