Apprendre correctement le C++

Bonjour, Bonsoir

Avant toute chose je tiens à préciser que je suis nouveau sur ce site (qu'au passage je trouve excellent), je m'en remet donc à votre clémence si je fais une bourde, du genre poster dans la mauvaise section.

Si je poste ce message aujourd'hui, c'est pour recueillir l'avis de programmeurs sur la question "Comment apprendre à bien programmer?". Réponse évidente me direz-vous? Pas tant que ça. Je m'explique:

Cela-fait un an que j'apprend le C++ (à comprendre, un an depuis le premier Hello World). Etant encore au lycée, j'ai débuté mon apprentissage à l'aide du tutoriel du feu siteduzero. Une fois celui-ci terminé, j'ai continué à progresser grâce à d'autres sites (je pense notamment à developpez.com, stackoverflow…). Bref, au petit bonheur la chance.

Et c'est bien ça le problème. Il existe tant de références, de blogs, de sites proposant des tutoriels de programmation que je ne sais plus vers quoi me tourner. Entre les différents standards du langage (C++98 / C++11), les différents points de vue sur les bonnes pratiques, dur de s'y retrouver..

De fait, j'ai souvent l'impression de mal programmer. Loin de moi l'envie de cracher sur mes codes, mais quand j'entend parler d'architecture, de design ou de conception et que je vois mes codes à côté, cela me trouble.

C'est pour ça que j'ouvre cette discussion, pour pouvoir en parler avec des gens plus expérimentés que moi sur ces questions (assez théoriques il faut bien le dire ), des gens qui s'y connaissent.

• La formation autodidacte en programmation est elle selon vous une bonne idée?
• Si oui, comment vous y prendriez-vous, s'il vous était nécessaire de reprendre l'apprentissage de la programmation?
• Quelle(s) bibliothèque(s) conseillez vous pour compléter la STL?
• De manière concrète, qu'est ce qu'un programme avec une bonne architecture?
• Y'a t'il des pratiques mauvaises quel que soit le programme? Exemple : "Il ne faut jamais utiliser de pointeurs nus." Vrai ou Faux?
• Au contraire, y'a t'il de bonnes habitudes à prendre pour programmer 'correctement'?
• (bonus) Ai-je le droit de vous poser plus de questions?

Je suis conscient que la manière de programmer est propre à chacun, mais je préfère éliminer les fausses bonnes idées une bonne fois pour toutes!

Je remercie par avance ceux & celles qui prendront le temps de me répondre

Deathekirl'

Le post d'Alex est très bon, mais il y a une mésentente sur "pointeur nul" ou "pointeur nu". Si par le second tu parles de *T par opposition à blabla_ptr<T> (les "smart pointers"), alors la réponse est différente. Je ne connais pas bien C++ mais il me semble que se forcer à utiliser les smart pointers a l'avantage de te forcer à réfléchir à qui possède la mémoire, et que c'est donc une bonne discipline de s'y tenir. Une fois que tu as l'habitude (pour éviter les coûts de shared_ptr), ou pour communiquer avec des bibliothèques qui ne les utilisent pas, tu peux retourner aux pointeurs nus, mais c'est difficile à faire sans se planter quand on ne sait pas déjà raisonner sur la possession mémoire.

(Les gens qui font du C diront que ce n'est pas nécessaire, mais c'est subtil: soit ils savent déjà les utiliser (consciemment ou non), et c'est entre autres pour cela qu'ils font du C correctement, soit ils ne savent pas s'en servir et ils font du C incorrect.)

J'appuie sur la pratique : il faut coder, montrer ce que tu as fait sur des forums, et laisser les gens le critiquer. Ou alors (c'est complémentaire) regarder ce que font les autres, se demander pourquoi on trouve ça moche, et apprendre à critiquer – de façon constructive. Avec un peu d'habitude tu sauras critiquer ton code tout seul, c'est ça la "conception".

Evidemment qu'il est presque impossible d'apprendre en ne faisant que lire de la théorie!

Depuis le début de mon apprentissage, j'ai dû réaliser une trentaine de projets différents, surtout pour m'initier puis m'améliorer dans l'utilisation d'une bibliothèque (Qt, SDL, SFML…) et quelques applications concrètes.

C'est justement à force d'accumuler ce genre de projets que je me suis rendu compte que je partais droit dans le mur: le projet qui devient inmaintenable rapidement, les bugs qui s'enchaînent, les problèmes de conception qui apparaissent en évidence.

plutôt que de lire des blogs, cours ou tutoriels en s'attendant à ce qu'ils te fournissent une réponse pré-mâchée à toutes tes questions. L'outil réellement indispensable c'est bien sûr les documentations des langages et bibliothèques que tu utilises, et qu'il est très important de savoir lire correctement.

Je suis conscient du côté formateur de la pratique, et du fait qu'il n'existe pas de formule magique pour tout connaître. Le problème ne vient pas de la compréhension des notions & du langage, mais plutôt de leur utilisation au sein d'un gros projet.

J'appuie sur la pratique : il faut coder, montrer ce que tu as fait sur des forums, et laisser les gens le critiquer. Ou alors (c'est complémentaire) regarder ce que font les autres, se demander pourquoi on trouve ça moche, et apprendre à critiquer – de façon constructive. Avec un peu d'habitude tu sauras critiquer ton code tout seul, c'est ça la "conception".

Je suis un peu mal à l'aise à l'idée de poster un projet entier sur un forum. Même si, comme tu le dis (et je pense comme toi) c'est un bon moyen d'obtenir des critiques & d'avoir d'autres regards sur sa conception, les forums me semblent plutôt faits pour répondre à des problèmes isolés, non pour analyser des codes sources entiers. Me trompe-je?

EDIT: J'ai à peine le temps de poster que de nouvelles réponses arrivent… Vous êtes formidables, merci

Le principal est de pratiquer, de préférence dans une équipe, avec des développeurs seniors qui review ton code.

J'aimerais bien! Actuellement, je suis le seul qui lit mes codes, et je n'ai donc pas d'avis de "senior". Mais il me semble difficile d'en avoir un sans faire partie d'une équipe, et difficile de faire partie d'une équipe quand on est débutant (sauf cas IRL, mais les lycéens programmeurs ne sont pas monnaie courante ^^)

Dans ce cas j'aurais tendance à te conseiller d'aller sur un bouquin (même pré C++11/C++14) dès que tu as des bases, même fébriles. Lire le livre que j'ai cité Egalement "Professional C++" et bien d'autres (cf Sélection de livres)

Ça tombe bien, j'adore lire :-P.

Faire de l'intégration continue (gestionnaire de versions, tests unitaires, automatiser les tâches, etc)

Qu'est ce que l'intégration continue (et les tests unitaires, pendant qu'on y est)?

En tout cas, ces problématiques de conception sont des choses que j'essaie d'intégrer dans le cours de C++ que je suis entrain de rédiger (si ça t'intéresse : C++ moderne)

J'irait jeter un oeil, ça m'a l'air super intéressant ;).

C'est surtout qu'en C, il n'y a pas d'exceptions comme en C++ et qu'un code correcte en C ne l'ai pas en C++. Cela fait justement parti des risques d'erreurs que l'on ne voit pas directement

Je suis un peu mal à l'aise à l'idée de poster un projet entier sur un forum. Même si, comme tu le dis (et je pense comme toi) c'est un bon moyen d'obtenir des critiques & d'avoir d'autres regards sur sa conception, les forums me semblent plutôt faits pour répondre à des problèmes isolés, non pour analyser des codes sources entiers. Me trompe-je?

Oui. Tu ne peux pas poster un projet complet sur le forum. Mais si tu mets ton projet sur github (par exemple) et il y a des forums pour présenter ses projets (sur ZdS, sur SdZ, sur Dvp, etc)

Ah oui tiens, je n'avais pas vu cette section du forum de Zds!

Le but de présenter un projet est d'avoir des avis dessus

Je coinche, personne n'est assez fou pour utiliser les exceptions en C++.

(troll ou remarque sérieuse ?)

Oui enfin c'est bien comme idée mais en pratique, comme le sous-entend Freedom, il y a plein de situations où on a besoin de partager la possession des données. unique_ptr n'est utilisable que dans certains cas, ou alors on fait tout en passage par valeur, et adieu les performances.

Il reste les référence et/ou les weak_ptr. De toute façon je ne suis pas sur qu'un déréférencement de temps en temps soit si coûteux que ça pour 99% des applications. Ce qui me gène surtout avec les shared_ptr c'est pas tant le surcoût que la propriété de la ressource qui est indéfinie.

Ok. Je me permet de faire une petite synthèse de vos réponses (hormis en ce qui concerne les pointeurs, je n'y comprend pas grand chose ):

• De nos jours, il est plus judicieux d'apprendre et d'utiliser le C++ moderne (C++11)
• STL + Boost permettent de couvrir la plupart des besoins tant qu'ils ne sont pas trop spécifiques (réseau, gui…)
• Il faut de la pratique, de la pratique et encore de la pratique
• Montrer ses codes pour obtenir des avis de seniors dessus est bénéfique pour à la longue éviter de refaire les mêmes erreurs
• Il n'existe pas d'architecture parfaite & universelle, chaque projet est différent et a donc la sienne, la pratique permet de prendre du recul et d'arriver plus facilement à distinguer une bonne conception

Je voudrais tout de même modérer un point sur l'auto-didacte. Il est vrai que la qualité des cours sur le C++ dans le milieu de l'enseignement n'est pas souvent à la hauteur des documents qu'on peut retrouver sur internet. En cela, il est plus intéressant de se tourner vers cette source que celle de l'enseignement.

Cependant, il y a quelque chose dans l'enseignement que tu retrouveras difficilement sur internet, c'est le mec derrière qui te note. En effet, il est AMHA nécessaire d'avoir une personne qui puisse critiquer ton code (dire que ceci est une convention, qu'on essaye d'éviter d'utiliser cela, qu'il est préférable d'architecturer ton code de cette manière, etc.). Ce point n'est pas incompatible avec l'auto-didacte puisque ici même, tu peux partager ton code et avoir des retours mais c'est cependant un aspect qu'on n'inclut pas souvent dans l'auto-didacte.

Face à toi même, tu auras du mal à avoir un esprit critique sur ce que tu viens de faire. Et considérer qu'il n'est pas nécessaire de poster ton code pour recevoir des critiques peut t'amener à avoir de mauvais automatismes. La structure du langage C++ à elle seule ne suffit pas à devenir un bon programmeur C++, il s'agit aussi d'acquérir de l'expérience par le biais des autres ! Voilà.

Pas "indéfinie", mais "partagée". Même si unique_ptr force à réfléchir à qui possède la responsabilité d'un pointeur, on peut faire du n'importe quoi sur la gestion des responsabilités. 0 l'inverse, on peut avoir un politique très forte de gestion des responsabilités et utiliser shared_ptr (ou un pointeur nu)

C++ moderne (C++11)

Le C++ "moderne" est plus une façon de penser la conception des applications, cela ne se limite pas à une syntaxe spécifique du C++. Mais le C++11 (et le C++1y) aide à mieux penser cette conception

Cependant, il y a quelque chose dans l'enseignement que tu retrouveras difficilement sur internet, c'est le mec derrière qui te note. En effet, il est AMHA nécessaire d'avoir une personne qui puisse critiquer ton code (dire que ceci est une convention, qu'on essaye d'éviter d'utiliser cela, qu'il est préférable d'architecturer ton code de cette manière, etc.). Ce point n'est pas incompatible avec l'auto-didacte puisque ici même, tu peux partager ton code et avoir des retours mais c'est cependant un aspect qu'on n'inclut pas souvent dans l'auto-didacte.

Dans l'absolu, je suis d'accord. Pour apprendre, il faut aussi évaluer si on a correctement appris

Par contre, ce qui me gène, c'est que si le cours est mauvais, l'évaluation le sera probablement aussi. Quelqu'un qui n'a pas mis à jour ses connaissances aura de mauvaises pratiques et la transmettra à ses étudiants. Et si l'enseignant est un universitaire, il pourra (peut être) avoir une vision très académique du code, ce qui est parfois très différent des critères utilisés en entreprise.

Dans ce sens, partager son code permet d'avoir des avis de personnes différentes (universitaires, entreprises, etc). Les discussions entre experts sur des points techniques particuliers permettent d'avoir une vision plus large des problèmes et solutions

Bonsoir,

Je tiens à tous vous remercier pour vos réponses Vous avez répondu à toutes mes interrogations, et maintenant je sais ce qu'il me reste à faire!

Sujet résolu, à bientôt

Malheureusement trop sont encore assez fous pour croire faire mieux sans les exceptions. Avec des ifs, quand on veut écrire un programme robuste (et pas un programme qui vit au pays magique où les erreurs n'existent pas), il faut faire remonter à la main toutes les erreurs possibles sur tous les chemins d'exécution. Si on n'en oublie pas (et ça, ce n'est pas trivial dans un langage qui descend du C qui n'impose pas de rattraper toute valeur retournée), on voit tout. Mais le problème est justement que l'on voit tout : le code nominal est noyé au milieu du code de traitement des cas exceptionnels.

Certains qui critiquaient en aveugles attaquaient aussi les perfs. C'était valable sur les anciennes générations de compilateurs, ou sur certaines plateformes (PS3, IIRC) qui avaient une gestion bugguée des exceptions. Bref, vu qu'un code robuste en C++ n'a pas à avoir un if toutes les deux lignes sur 10 niveaux de profondeur pour traiter les cas exceptionnels, les exceptions ont de bonnes chances d'offrir des programmes (robustes) plus rapides. (J'insiste sur le côté robuste, il est idiot de comparer les perfs d'un code employant des exceptions avec celles d'une code écrit au pays magique où les erreurs n'existent pas).

Bref. Il faut apprendre à manipuler le C++ moderne pour commencer. Un fois le RAII acquis, le passage aux exceptions se fera sans soucis.

Le sujet semble résolu si l'on en croit l'OP, mais je voudrais tout de même apporter mes deux centimes et évoquer quelque chose à côté duquel mes voisins du dessus (même si leurs contributions contiennent d'excellent conseils) sont passés, ou plutôt quelque chose qui a affleuré sans éclore : la pertinence de bosser dans un projet qui n'est pas le sien, sous la houlette de quelqu'un de meilleur que soi.

Je m'explique, et ça rejoint l'idée de Dinosaure de "quelqu'un derrière toi qui te note", tout en étant plus proche de l'autodidaxie. Mon parcours en informatique a été pour le moins hiératique ; il a commencé il y a environ 6 ans dans le domaine du web (PHP et consorts, qui ont bien évolué depuis) pendant quelques années au terme desquelles je pressentais à peine l'importance de bonnes pratiques, d'une architecture et d'une réelle conception d'un code. Tout ce qu'on pourrait qualifier de philosophie, d'esthétique de la programmation (ouais, carrément) m'était à peu près étranger, même si je commençais à avoir des idées en la matière. Et là, j'ai intégré un projet monstrueusement massif (en gros, un MMORPG, et qui a abouti, réellement), mené par un mec incroyablement plus talentueux que moi. Sous sa direction, j'ai appris Python et surtout, surtout, j'ai énormément progressé en capacités de réflexion sur ce que je produisais au niveau code.

D'ailleurs, j'ai lu ça y'a pas longtemps dans un papier que j'ai la flemme de retrouver, qui parle justement de "comment apprendre à programmer". L'auteur y mentionne l'utilité de participer à un projet véritable, et je ne saurais trop être d'accord avec lui. Grâce à ce gros projet que j'ai mentionné, j'ai acquis des réflexes de conception, de convention, de programmation en général qui me servent à chaque fois que je code. Bon, évidemment, c'est pas évident d'intégrer un projet et on peut trouver sur la toile pas mal de daubes qui recrutent et ne t'apprendront pas grand-chose… Mais il n'empêche que si tu en as l'occasion, ça me semble vraiment un des meilleurs moyens de progresser en programmation. (En fait, ça répond plus ou moins à tes points 1, 4, 5 et 6. )

Ce que tu décris rejoint une partie de ce (vieux) document célèbre: How To Become A Hacker d'Eric Raymond. C'est avec des forums que j'ai beaucoup appris pour ma part: on suit des forums techniques ; arrive un moment où l'on essaie de répondre ; si notre réponse à des erreurs ; des gens plus compétents viennent la corriger ; Parfois ils complètent et pinaillent, ce qui est tout aussi instructif ; et puis on passe de l'autre côté : celui de ceux qui corrigent/complètent/pinaillent.