Discussion :

[Emmanuel Colomb]

Bon je crois que tout est dis, alors je vais juste me mettre dans la peau des différents intervenants (enseignant - débuant - confirmé)

Du point de vue de l'enseignant
Je préfère leur apprendre la POO, les design patterns, les STL, etc
plutôt que la notion de type de base, de mémoire, d'algorithme de base ...

+++ Dans le premier cas je me sens comme un maître de conférence
--- Dans le second cas je me sens comme un instituteur de 'petite' classe

Pour l'apprentissage basique du langage ils n'ont qu'à se référer aux bouquins !!!

Du point de vue de l'élève
Je préfère apprendre la POO, les design patterns, les STL, etc
C'est beaucoup plus valorisant,
et puis une fois que je maîtrise ces notions 'de haut niveau', je peux les appliquer à n'importe quel langage !
Pour l'apprentissage d'un langage spécifique, je le ferais 'sur le tas'.

Du point de vue du développeur confirmé
Ah, des débutants, va falloir que je les forme sur les bonnes techniques de développement

Mais cette formation va se heurter à des problèmes
2 cas de figure pour un projet :
I. Soit le projet de dev consiste à écrire 'from scratch' le code source
II. Soit le projet de dev consiste à modifier un code source pour améliorer/modifier/ajouter des fonctionnalités.

Dans le cas I, idéalement, il faudrait que le dév confirmé revoit quotidiennement le code de chaque débutant, lui explique ce qui ne va pas, et comment corriger.
Autant vous dire que l'idéal est très loin de la réalité et en pratique le dév confirmé se borne à 'éteindre les incendies' car lui aussi est chargé d'une partie du dév (et généralement une grosse partie).
Bref au final 80% du code d'un projet de type I est de qualité médiocre, sauf si l'équipe est majoritairement constituée de dév confirmés (confirmés qui avaient été correctement formés...).

Dans le cas II, idéalement, le code source est bien écrit, le dév confirmé peut s'y référer pour former les dév débutants qui le prendront 'en exemple'.

Mais comme le cas II découle d'un projet de type I, le code source avec lesquels se forment les débutants a été... souvent réalisé par des débutants, donc est globalement pourri !

Ah là là, pas facile pour un confirmé de former un débutant !

Du point de vue du développeur débutant

Le débutant sera frustré, malheureux, voir inquiet de n'avoir par été correctement formé au cours de ses premiers projets.

Bon ok j'ai forcé un peu le trait, mais tout ça pour souligner que personne n'est à blâmer dans ce long et difficile processus d'apprentissage.

[transgohan]

Tu as un peu beaucoup forcé le trait même je dirai...
J'espère sérieusement que tu ne penses pas tout ce que tu as rédigé.

Si on n'apprend plus les bases à l'école mais où va-t-on !
Faut pas croire que tout le monde a internet et un ordinateur chez eux...
C'est pas pour rien qu'il est obligatoire à toute école d'informatique de mettre à disposition des salles libres services pour leurs étudiants.
J'en ai connu moi des étudiants qui restaient en salles TP jusqu'à 20h le soir pour faire leur travail, ils n'avaient pas d'autres choix.
Et quand à dire qu'ils ont qu'à apprendre par eux même les bases... Mais bien sûr... Et on va faire pareil avec les gamins de primaire, les additions et compagnie ils se démerderont à les apprendre tout seul moi j'dis ! Ainsi le professeur pourra directement mettre en application les problèmes plutôt que les méthodes de résolution.

[BenoitM]

Du point de vue de l'enseignant
...
Du point de vue de l'élève
...

Tu es prof?

Parce que perso dans mon cursus scolaire j'ai eu des profs très compétent et surtout fan de ce qu'ils enseignaient et d'autre pas du tout et ca ne dépendait pas de la matière.
Bon élève, je suppose que tu l'as été, mais moi j'ai trouvé beaucoup plus gratifiant d'apprendre les bases de la programation en c et de faire ma premiere liste chainées (surtout qu'on m'avait dit que les pointeurs étaient compliqué) que faire de la POO et j'ai nettement préféré mon prof de c que mon prof de Visual C++ qui ne faisait que lire son livre.
J'étais convaincu (et le suis toujours) que la liste chainée et balanced trient ne m'ont pas servi à grand chose part contre j'y ai eu plus de plaisir a la programmer que de faire une application en Winform. J' ai éprouvé plus de challenge, sans parler de l'amusement où en C on m'avait demandé de faire un pendu, une "espece de master mind", une communication réseau avec une imprimante alors qu'en visual c++ j'ai du faire qu'une application qui enregistrait une liste de personne dans une BD

Du point de vue du développeur confirmé
I. Soit le projet de dev consiste à écrire 'from scratch' le code source
II. Soit le projet de dev consiste à modifier un code source pour améliorer/modifier/ajouter des fonctionnalités.

Parce que c'est du procédurale, tu n'as pas a vérifier le code d'un débutant?
J'ai peur des progammes que tu laisses écrire par des "débutants"
Cas 2 : Oula c'est sur que c'est parce que tu vois ton chef faire un gateau que tu es patisier...

[I_believe_in_code]

Il fait ensuite du lisp, caml et autres langages d'apprentissage sans objets.

Euh... Common Lisp et Ocaml (au moins eux) ont tout ce qu'il faut pour faire de la programmation objet. CLOS est même un excellent choix pédagogique pour enseigner les concepts de la POO à des élèves : plus puissant que Python (j'ai toujours trouvé que Python c'était un centième de Lisp en pourri), moins bizarre que C++ (avec ses fonctions amies et autres tares) et surtout moins bête que le "tout objet" Java qui oblige à créer une classe juste pour écrire un main, ce qui n'a bien évidemment même pas de sens.

[BenoitM]

Euh... Common Lisp et Ocaml (au moins eux) ont tout ce qu'il faut pour faire de la programmation objet. CLOS est même un excellent choix pédagogique pour enseigner les concepts de la POO à des élèves : plus puissant que Python (j'ai toujours trouvé que Python c'était un centième de Lisp en pourri), moins bizarre que C++ (avec ses fonctions amies et autres tares) et surtout moins bête que le "tout objet" Java qui oblige à créer une classe juste pour écrire un main, ce qui n'a bien évidemment même pas de sens.

Java ne vous oblige a rien part contre c'est vrai qu'en POO il est mieux de créer une main plutot que de devoir passer à chacune de vous méthodes 5 doigts, et de vous rendre compte ensuite qu'il fallait donner les 5 doigts et 3 phalanges respectives
On dirait que personne n'a eu le cas où il devait passer à la méthode X l'arguement Y,et de devoir changer 3 fonctions pour pouvoir passer cet argument la fonction X et donc changer tout les appels de ces 3 fonctions

[Bousk]

Pourquoi assimiler l'objet au C++ et le dégager du C ?
On peut faire du code objet en C, avec de simples structures et des méthodes qui prennent ces structures en paramètres.
Et c'est ce que j'essaye de transmettre pour ma part en "cours de C", avec des exemples simples : on a le choix entre une fonction à 4 paramètres pour représenter une personne (par son nom, prenom, age, sexe) ou une structure qu'on appelera Personne qui contiendra toutes ces informations. Généralement ils ne voient pas l'intérêt de prime abord. On décide de rajouter 1 paramètre et ils le voient déjà mieux. On leur inclut une erreur qui utilise l'age de Personne 2 au lieu de la Personne 1 en paramètre et ils y voient plus clair encore.

La plupart des étudiants qui disent "ne rien comprendre à l'objet" en ont même déjà utilisé : FILE*.

Le problème que je vois pour ma part, c'est le même que souvent : un à priori qui fait qu'ils se braquent et ne font pas l'effort d'apprentissage.

Après oui, quand on va plus en avant on voit les mot-clé virtual, héritage etc, mais ce n'est qu'après. Et après on se rend compte qu'ils sont bien pratiques également .
Mais on ne va bien entendu pas commencer un cours de programmation objet en C++ par un cas d'héritage en diamant..

[BenoitM]

Pourquoi assimiler l'objet au C++ et le dégager du C ?
On peut faire du code objet en C, avec de simples structures et des méthodes qui prennent ces structures en paramètres.
Et c'est ce que j'essaye de transmettre pour ma part en "cours de C", avec des exemples simples : on a le choix entre une fonction à 4 paramètres pour représenter une personne (par son nom, prenom, age, sexe) ou une structure qu'on appelera Personne qui contiendra toutes ces informations. Généralement ils ne voient pas l'intérêt de prime abord. On décide de rajouter 1 paramètre et ils le voient déjà mieux. On leur inclut une erreur qui utilise l'age de Personne 2 au lieu de la Personne 1 en paramètre et ils y voient plus clair encore.

Euh simplement parce que la POO ce n'est pas des structure
La POO c'est aussi qu'une classe contient des méthodes contrairement aux structures
Que vu que ces méthodes sont liées aux objets il y a la notion d'héritage, vu la notion d'héritage on a fait la notion d'interface. Que la notion d'objet et de méthode liées aux objets on a crée des méthodes statiques.
Qu'on a créer la protection des membres de structures (private public protected) bref oui en C tu as des structures mais C ce n'est pas de la POO
(Certes si tu connais la POO , tu feras en general mieux tes découpes en C mais ca n'a rien avoir avec de la POO)

Pour conduire une moto il me faut le code de la route, si je conduis une voiture je connais le code de la route (entk normalement) ce n'est pas pour ca que je sais conduire une moto (et vice-versa c'est pas parce que je suis un bon programmeur en POO que je serai un bon programmeur en C (même si ca va m'aider))

[MiaowZedong]

Euh... Common Lisp et Ocaml (au moins eux) ont tout ce qu'il faut pour faire de la programmation objet. CLOS est même un excellent choix pédagogique pour enseigner les concepts de la POO à des élèves : plus puissant que Python (j'ai toujours trouvé que Python c'était un centième de Lisp en pourri), moins bizarre que C++ (avec ses fonctions amies et autres tares) et surtout moins bête que le "tout objet" Java qui oblige à créer une classe juste pour écrire un main, ce qui n'a bien évidemment même pas de sens.

Sans compter que la programmation fonctionelle a débouché sur un certain nombre de projets très réussis, comme—par exemple—l'algo MapReduce de Google et le système DARTS de l'armée Américaine. Juste parce que ce n'est pas conforme aux buzzwords actuels, ça ne veut pas dire que ça ne sert à rien

P.S. on peut très bien implémenter les concepts objets en C, il existe d'ailleurs des frameworks objet en C pour éviter de devoir réinventer la roue.

[BenoitM]

Sans compter que la programmation fonctionelle a débouché sur un certain nombre de projets très réussis, comme—par exemple—l'algo MapReduce de Google et le système DARTS de l'armée Américaine. Juste parce que ce n'est pas conforme aux buzzwords actuels, ça ne veut pas dire que ça ne sert à rien

P.S. on peut très bien implémenter les concepts objets en C, il existe d'ailleurs des frameworks objet en C pour éviter de devoir réinventer la roue.

Vu que je me suis surement pris le -1 part vous pouvez-vous me reiseigneur sur ces framework? Qu'on puisse tenter d'implémenter des concepts objets à un langage procédure, je le conçois qu'on puisse transformer un langage procedure en language objet j'ai un doute (surtout via un framework)

De plus si via des framework on s'amuse a mettre des éléments de POO dans un langage procédurale, ca doit bien signifier que la POO peut apporter un plus :p

[MiaowZedong]

Vu que je me suis surement pris le -1 part vous pouvez-vous me reiseigneur sur ces framework? Qu'on puisse tenter d'implémenter des concepts objets à un langage procédure, je le conçois qu'on puisse transformer un langage procedure en language objet j'ai un doute (surtout via un framework)

De plus si via des framework on s'amuse a mettre des éléments de POO dans un langage procédurale, ca doit bien signifier que la POO peut apporter un plus :p

Le plus connu est sans doute GObject utilisé par le projet GNOME Mais vois aussi par exemple http://daifukkat.su/wiki/index.php/SOO qui est un système beaucoup plus basique.

N'oublions pas non plus que la quasi-totalité des languages objets sont implementés avec des compilateurs écrits en C

La POO n'est bien sûr pas sans intérêt, mais c'est une façon de coder qui n'est pas adaptée à tout et ne doit pas remplacer dans l'enseignement les bases que sont l'algorithmique, les types, les pointeurs....

P.S. le vote -1, en fait, ce n'est pas moi

[psykokarl]

Qu'on puisse tenter d'implémenter des concepts objets à un langage procédure, je le conçois qu'on puisse transformer un langage procedure en language objet j'ai un doute (surtout via un framework)

De plus si via des framework on s'amuse a mettre des éléments de POO dans un langage procédurale, ca doit bien signifier que la POO peut apporter un plus :p

Une structure peut stocker tout type de donnés dont... des adresses de fonctions. Moyennant un jeux de déclaration et d'affectation de base tu peux avoir une notation du type:

maStructure->maMethode(/*parametre*/);

Mais c'est une façon de représenter le code. si on crée une fonction qui prend une structure de données en paramètre on a:

maMethode(maStructure, /*parametre*/);

Des exemples foisonnent sur le net...
En fait la POO est un sous ensemble des concepts mis au point avec des langages procéduraux. C'est plus une manière d'organiser le code parmi d'autres.

Le cœur du métier reste de de savoir comment faire fonctionner le code et non comment l'organiser. La POO est utile dans la mesure ou l'on dispose d'un modèle d'organisation efficace sans avoir à gérer structures et pointeurs.
En revanche dès que l'on commence triturer l'esprit pour savoir comment rendre son code performant et/ou plus lisible avec de l'objet, les perd les bénéfices les bénéfices qu'apportent la POO.

[unknow0]

N'oublions pas non plus que la quasi-totalité des languages objets sont implementés avec des compilateurs écrits en C

je ne sais pas pour les autre mais gcc/g++ passe au c++ ^^
je pence que les autre font/ferons le meme choix pour des raison similaire (maintenabiliter)

La POO n'est bien sûr pas sans intérêt, mais c'est une façon de coder qui n'est pas adaptée à tout et ne doit pas remplacer dans l'enseignement les bases que sont l'algorithmique, les types, les pointeurs....

gros +1 la dessus

a construire sur du sable sa fini toujours pas s'ecrouler

[BenoitM]

N'oublions pas non plus que la quasi-totalité des languages objets sont implementés avec des compilateurs écrits en C

Qui eux même sont écrit en assembleur, vive l'assembleur :p

La POO n'est bien sûr pas sans intérêt, mais c'est une façon de coder qui n'est pas adaptée à tout et ne doit pas remplacer dans l'enseignement les bases que sont l'algorithmique, les types, les pointeurs..

Là je suis d'accord mais même en POO, tu as des pointeurs. Certes une partie des pointeurs en POO est caché mais si tu ne sais pas ce qu'est un pointeur tu ne comprendra pas le passage par référence.

Pour l'algo, bon là, ca a une utilité, de la a dire que c'est toujours indispensable, perso depuis que je fais du .Net, Java j'ai pas du recreer des liste chainé et je suppose qu'en C tu peux trouvé des framework et les alogirthme de trie plus complexe, j'ai étudié mais je suis pas sur de pouvoir les recréer sans trouver la doc sur le net

En fait la POO est un sous ensemble des concepts mis au point avec des langages procéduraux. C'est plus une manière d'organiser le code parmi d'autres.

Effectivement je pense qu'une grande partie a été devellopper en POO sur base des problème rencontrer en procédurale et ses techniques ont été simplifié pour rendre l'écriture plus lisible.
Un objet de POO est en "gros" couper un programme procédurale en plusieurs fichier.
Mais en général on apprendre cette organisation en POO. Mainetant on pourrait faire une partie de celle-ci en procedurale mais il me semble plus facile de les apprendre en POO et de les appliquer en Procédurale mais bon ca c'est peut-être du à la manière d'apprentissage.
En POO tu es obliger de découper tes fonctions en objets et donc ensuite en procédurale ca devient naturelle de le faire

a construire sur du sable sa fini toujours pas s'ecrouler

Mouais , je suis sur que c'est ce qu'on a dit au developpeur de C qui ne connaissait pas l'assembleurs et je suppose que c'est ce qu'on dira au developpeurs qui ne connnaitront pas le C

[MiaowZedong]

Pour l'algo, bon là, ca a une utilité, de la a dire que c'est toujours indispensable, perso depuis que je fais du .Net, Java j'ai pas du recreer des liste chainé et je suppose qu'en C tu peux trouvé des framework et les alogirthme de trie plus complexe, j'ai étudié mais je suis pas sur de pouvoir les recréer sans trouver la doc sur le net
[...]
Mouais , je suis sur que c'est ce qu'on a dit au developpeur de C qui ne connaissait pas l'assembleurs et je suppose que c'est ce qu'on dira au developpeurs qui ne connnaitront pas le C

En fait, c'est la différence entre être charpentier et menuisier....sans charpente, la maison ne tient pas, sans menuiserie elle est juste un peu vide. Ce ne sont pas les mêmes enjeux.

Il est impossible de créer un language objet sans maîtriser le bas niveau. Il est impossible de créer les bibliothèques de ce language sans en maîtriser les bases ainsi que les bases de la programmation elle-même (algorithmique, etc). À vouloir enseigner ce que demande majoritairement les entreprises (la POO) aux dépens des bases, on risque de former des devs-consommateurs qui n'ont pas un savoir-faire pourtant indispensable au developpement d'ensemble des programmes.

Il est impossible de faire de l'informatique sans prog système, sans compilateurs, sans libs. De plus, l'informatique de pointe, comme peuvent faire Google ou Microsoft, et où se trouve la plus forte valeur ajoutée (il n'y a qu'à voir la croissance phénoménale de Google), se fait forcément sans frameworks...

Edit: quant à l'assembleur, heureusement que certains le connaissent encore! Sinon, nous serions bien coincés: pas de possibilité de décompiler des virus, par exemple.

[Emmanuel Colomb]

Pourquoi assimiler l'objet au C++ et le dégager du C ?
On peut faire du code objet en C, avec de simples structures et des méthodes qui prennent ces structures en paramètres.
Et c'est ce que j'essaye de transmettre pour ma part en "cours de C", avec des exemples simples : on a le choix entre une fonction à 4 paramètres pour représenter une personne (par son nom, prenom, age, sexe) ou une structure qu'on appelera Personne qui contiendra toutes ces informations. Généralement ils ne voient pas l'intérêt de prime abord. On décide de rajouter 1 paramètre et ils le voient déjà mieux. On leur inclut une erreur qui utilise l'age de Personne 2 au lieu de la Personne 1 en paramètre et ils y voient plus clair encore.

La plupart des étudiants qui disent "ne rien comprendre à l'objet" en ont même déjà utilisé : FILE*.

Le problème que je vois pour ma part, c'est le même que souvent : un à priori qui fait qu'ils se braquent et ne font pas l'effort d'apprentissage.

Après oui, quand on va plus en avant on voit les mot-clé virtual, héritage etc, mais ce n'est qu'après. Et après on se rend compte qu'ils sont bien pratiques également .
Mais on ne va bien entendu pas commencer un cours de programmation objet en C++ par un cas d'héritage en diamant..

Ah j'adore ce type d'enseignement :
- commencer par présenter un cas simple... qui fonctionne car il est simple (fonction avec 4 paramètres)
- puis faire comprendre que ça ne peut pas fonctionner correctement dans un cas plus complexe (6, 7... 100 paramètres ?)
- et d'introduire une nouvelle notion qui apporte une solution (utilisation de structure... voir même de structure de structure)

Je pense que c'est le meilleur moyen de faire prendre conscience petit à petit de l'intérêt de finalement passer du tout procédural et non structuré, à de la POO; et puis ensuite de faire comprendre tout l'intérêt d'utiliser le C++ plutôt que le C.

Un gros +1 !

Une 'bonne' POO en C++ apporte des gains énormes par rapport à une bonne PP en C (ne serait-ce que pour les exceptions). Et bien souvent un programmeur débutant devra directement construire ou maintenir des programmes de type POO.
Pour comprendre tout l'intérêt de la POO, il faut avoir appris, mieux avoir pratiqué, la PP.
Pour éviter tous les pièges de la POO, c'est une autre histoire

[Aldian]

Quand j'étais en collège/lycée, j'ai appris le basic, ça m'a plutot bien réussit, car après quelques usines à gaz j'ai appris à faire preuve de rigueur en codant.

Ensuite en école j'ai d'abord appris le C puis le java, et je trouve que c'est très bien comme ça, tout simplement parce que le C permet d'apprendre ce qui se passe vraiment dans l'ordinateur, et le jour où l'on va créer un logiciel destiné à subir une forte charge, on n'est pas supris d'être limité par les accès disque, les dépassement de pile, les pools qui se remplissent trop vite ou tout autre effet lié aux limites physiques des systèmes parce qu'on a les outils pour imaginer comment ça se traduit au niveau du système.

C'est pour cette raison que je pense pour ma part qu'il ne faut pas apprendre l'objet aux débutants, à moins d'être certain qu'ils ne seront jamais confrontés à la problématique que je viens d'évoquer. D'autant plus que l'objet que l'on apprend au débutant est souvent extrêmement dépouillé, il leur faut beaucoup de temps pour prendre la mesure de tous les mécanismes et avoir assez de recul.

Avec le temps, lorsqu'ils commenceront à élaborer des logiciels suffisamment gros pour qu'ils éprouvent le besoin de structurer le code en regroupant les fonctions traitant d'un même type de structure, la nécessité d'apprendre l'objet s'imposera d'elle même, et ils en comprendront bien mieux l'intérêt que des gens qui n'ont jamais codé et à qui cette philosophie de pensée peut paraitre tordue si on leur fait prendre trop de raccourcis.

[gl]

pouvez-vous me reiseigneur sur ces framework? Qu'on puisse tenter d'implémenter des concepts objets à un langage procédure, je le conçois qu'on puisse transformer un langage procedure en language objet j'ai un doute (surtout via un framework)

COS

[psykokarl]

Qui eux même sont écrit en assembleur, vive l'assembleur :p

L'assembleur qui est le langage impératif par excellence !
Le C par rapport à l'assembleur fournit déjà une couche d'abstraction appréciable qui facilite grandement la lisibilité. Cela dit, même si je ne touche plus à de l'assembleur depuis un petit moment, ce que m'a apprit ce langage
me sert quotidiennement.
Je sais par exemple que déclarer une fonction n'est pas anodin. Même si je ne l'ai jamais codé et que je n'en coderai jamais j'ai une vague idée de ce que ça implique en sauvegarde d'adresses, en saut et en création de pile d'environnement dans le cas d'appel récursif.
Je ne vais surement pas dire qu'un dev en assembleur ne sait pas coder de façon structurée et lisible parce que j'utilise un langage qui me pré-mâche des outils d'abstraction.

Mais en général on apprendre cette organisation en POO. Mainetant on pourrait faire une partie de celle-ci en procedurale mais il me semble plus facile de les apprendre en POO et de les appliquer en Procédurale mais bon ca c'est peut-être du à la manière d'apprentissage.

Il y a en effet des "feedback". On peut appliquer des techniques auquel on a été familiariser avec d'autres paradigme en programmation procédurale. Le plus important est de comprendre intuitivement comment s'opère la POO en procédural parce que c'est le procédural qui gère le cout et la fiabilité d'un algorithme.

En POO tu es obliger de découper tes fonctions en objets et donc ensuite en procédurale ca devient naturelle de le faire

C'est un exemple de la distraction que provoque l'OO, quoique cela vienne d'avantage de la manière dont est enseigné l'OO plus que de sa nature.

On est pas obligé de "découper les fonctions en objets" en POO. Si une méthode fonctionne bien, qu'elle est compréhensible et qu'on a pas besoin de la découper en dépit de sa taille, pourquoi le faire ?
La POO (ou tout autre paradigme) découle du besoin de rendre le code lisible
la lisibilité ne découle pas du besoin de faire de la POO.
Il faut se poser la question de l'utilité d'une refacto avant de la faire.

[Paul TOTH]

moi je dis qu'il faut arrêter de distraire les développeurs débutants avec des débats sans fin sur OO ou PP

l'important c'est de commencer, et de garder l'esprit ouvert vers toutes les solutions, que ce soit par goût, par contrainte technique ou par obligatoire commerciale ou administrative.

[BenoitM]

On est pas obligé de "découper les fonctions en objets" en POO. Si une méthode fonctionne bien, qu'elle est compréhensible et qu'on a pas besoin de la découper en dépit de sa taille, pourquoi le faire ?
La POO (ou tout autre paradigme) découle du besoin de rendre le code lisible
la lisibilité ne découle pas du besoin de faire de la POO.
Il faut se poser la question de l'utilité d'une refacto avant de la faire.

Le lien entre objet et fonction évite d'avoir à lire toute les fonctions mais qui n'ont rien avoir. Quand je veux Sauvegarder l'objet/structure Eleve , c'est une perte de temps de devoir lire SaveProf, SaveClasse, LoadClasse,LoadProf,... c'est quand même plus pratique d'avoir tout mis dans le fichier Eleve.c que d'avoir MaLib.c avec 500 méthodes dedans

la découper en dépit de sa taille, pourquoi le faire ?

1) Pour une plus grand clarté et lisibilité.
Perso quand je tombe sur des fonctions de 1000 lignes et que je dois parcourir tout pour essayer de trouver le bug, je préferent nettement quand ces 1000 lignes soit découpés sans compter que je dois essayer de déchivrer les requetes SQL pour savoir ce qu'elle font