Bonjour !
Je code maintenant depuis des années tel un apprenti sorcier sans vraiment me soucier des détails Mais la je me suis lancé dans un projet un peu plus gros que d'habitude (Qui plus est avec un langage qui ne m'est pas familier) et je me rend compte que mon code n'est pas propre et manque d'ordre/ de méthode. D'où ma question, auriez vous des tutos à me conseiller pour bien organiser son code et faire des choses propre ? Et est-ce que l'organisation d'un code est liée au langage ?
Je précise quelques trucs quand même : je suis actuellement en licence informatique et j'ai déjà appris à coder bien avant. Donc le code et l'algorithmie ne me posent pas de problème. Ce que je code actuellement marche, mais j'aimerais juste avoir un code plus propre (Savoir où mettre des constantes, comment regrouper mes fonctions etc.). Car mon projet est assez gros et des amis à moi aimeraient m'aider mais j'ose pas leur donner un code dégueu de un, et mieux je m'y retrouve dans mon code, mieux c'est non ?
Bref, merci d'avance à ceux qui prendront le temps de me répondre !

Les principes d'organisation ne sont pas directement liés aux langages mais plutôt aux fonctionnalités des langages (qui sont souvent communes).
Il y a des règles de base (faire un fichier pour les constantes, faire des classes séparées dans des fichiers (pas 2 classes dans le même fichier) ), séparer les déclarations et les définitions des fonctions.
Généralement il faut bien anticiper un projet et toutes ses évolutions possibles parce que le code sale vient souvent d'un ajout de plein de petits modules qui n'ont pas été anticipé et qui font qu'un code est sale à terme.
Il y a une analogie appelée "grande boule de boue" : https://fr.wikipedia.org/wiki/Grande_boule_de_boue
Limiter les effets de bords, la programmation spaghetti et tous ces principes font aussi qu'un code devient plus lisible.
Mettre des commentaires évidemment, pour chaque code non trivial et en entête de fonction pour dire ce qu'elle fait.
Et faire des fonctions génériques qui opèrent sur le moins de données possibles en prenant le moins de paramètre possible:
Pas faire:

ResoudrePb
- code1
- code2
     - code2b
- code3

mais plutot:

ResoudrePb
- Resoudre pb1
- Resoudre pb2
- Resoudre pb3

ResoudrePb1
- code1

ResoudrePb2
- code2
   -code2b

ResoudrePb3
- code3

Evidemment c'est subjectif puisqu'il faut réussir à identifier les sous-problèmes.

Déjà ça m'aide pas mal Mais tu parle de tout prévoir au début ... et j'avoue que vu que je ne sais pas du tout ou je vais dans mon projet, je suis un peu perplexe sur cette idée de prévoir ...
Sinon, un truc qui me choque un peu dans ce que tu dis, c'est une classe par fichier. Donc si par exemple je fais un projet disons un jeu vidéo (pour être original tiens ...), alors je devrais créer un fichier pour la classe personnage, un pour la classe ennemi, etc ... ? Car de mon point de vue j'ai toujours pensé que l'on devait regrouper ce qui allait ensemble. Par exemple toutes les entités de type PNJ et le joueur serait regroupé dans un même fichier.

En tout cas merci pour ton aide !

Bah tu es exactement dans la problématique d'anticipation.
Si comme tu le dis tu fais un jeux vidéo, tu vas réfléchir aux concepts qui peuvent se généraliser par une classe et à ceux qui ne le peuvent pas.
Un ennemi et un joueur ont des points communs (une barre de vie, ils peuvent attaquer, se défendre, ils sont représentés par un modèle graphique (2d/3d) etc...), donc ces similitudes vont dans une seule classe, qui aura ses déclarations de méthode dans un fichier (en c++ ce serait un header (.h)) et ses définitions dans une autre méthode (.cpp), disons la classe "Personnage"

Tu peux déjà poser ce modèle sur le papier si il te va, mais après tu vas vouloir rajouter des cailloux dans ton jeux, des arbres, des décors (la classe "Decor"), qui n'ont pas de point de vie, donc ce serait une autre classe, mais ils ont encore un modèle graphique et une hitbox donc tu serais tenté de faire de l'héritage (Une classe "EntitéPhysique" ?) etc....

Tout ça ça se pose sur le papier avant de le programmer.
Là avec cet exemple tu entres vite dans une problématique d'un gros arbre d'héritage donc on te conseillera de regarder des design pattern (je te conseille d'en apprendre un maximum), et on te dira qu'ici il faut plus faire de la composition, ou un certain type d'héritage, ou de faire l'architecture de ton programme avec l'Entity-Component-System. Le livre de référence c'est celui de Gamma, Vissides etc.. : "Design Patterns: Elements of Reusable Object-Oriented...."

Ce que je fais là, c'est penser le programme AVANT de le programmer, et c'est grâce à ça qu'on évite du code sale.

Architecture MVC + UML ? avec des héritages bien respectés, le nom des variables bien clair au premier coup d'oeil ainsi que les fonctions, class, etc... Je travail avec des petits programmes qui ne sont pas finis mais je me rend compte que quand ont sait codé, 60% du temps d'un projet sera de faire l'UML du projet de façon à ce que le tous soit bien structuré. beuh...

j'aime bien l'approche par "composant" style angular pour la vision "macro" du programme

Ce que je fais là, c'est penser le programme AVANT de le programmer, et c'est grâce à ça qu'on évite du code sale.

je suis bien d'accord, mais avec des méthodes agiles par exemple style scrum, on ne voit pas trop le projet dans sa totalité et la conception est à revoir régulièrement je trouve... ou alors c'est parce que je ne suis pas encore assez à l'aise avec la méthode