Je me pose des grosses questions existentielles sur le commentaire dans le code.
Aujourd'hui, dans ma boite la politique est de ne pas commenter le code, à part les headers de fonctions et de propriétés publiques et internes car c'est obligatoire à cause d'une règle de check-in, mais ça donne ce genre de commentaire:

/// <summary>
/// Gets or sets the first name
/// </summary>
public string FirstName { get; set; }

/// <summary>
/// Does the stuff
/// </summary>
public void DoStuff() { ... }

Et aucun autre commentaire au milieu du code.
L'idée derrière est d'avoir des standards de nommage et de code tellement "limpide" que le commentaire en devient inutile, donc des méthodes qui ne dépassent pas 1 page de code, des propriétés avec des noms à rallonge, des noms de fonctions pareil avec des noms à rallonges.

Et si il reste des commentaires dans le code, c'est uniquement à cause de spécificité métier ou bug, genre:
// Problem with framework, this sucks but is mandatory
Et rien d'autre.

Toi Guyguy qui est censé enseigné ça à la fac, tu en dis quoi ?

Autant en tant que développeur ça me fait chier d'écrire du commentaire, de l'autre côté, de temps en temps c'est nécessaire, et parfois je trouve mes collègues archi trop fainéants et se reposant trop sur le générateur de code.

On donne toujours comme instructions de bien documenter le code, que ça soit l'interface publique ou même le contenu du code. On a quelques guidelines (que je n'ai pas écrites, et je ne suis pas toujours d'accord) mais elles sont rarement respectées dans les projets des étudiants, et on se retrouve bien souvent avec une documentation qui est incomplète (ne couvre aucun cas particulier, aucune exception, etc.) ou inintéressante ("Do the stuff"-like ).

Pour ma part, je suis déjà content quand les étudiants arrivent à faire de la "belle" POO et évite de faire du 100% procédural en Java, ou encore quand ils arrivent à nommer leurs méthodes/attributs correctement (parce que bon, un getFinished au lieu de isFinished, ou des machins du genre, ça me saoule un peu ^^). Heureusement que Java est typé statiquement, sinon leur code serait bien souvent incompréhensible...

A coté de ça, en tant que fervent supporter de Python (et ayant fortement contribuer à introduire le langage dès la 1ere année du cursus), je suis beaucoup plus strict pour les projets codés en Python. Premièrement, j'impose une documentation (docstring) respectant les conventions, avec détails des différents arguments (vu que ce n'est pas typé statiquement, c'est souvent indispensable, ou presque, pour comprendre ce que fait la fonction/classe !) et j'impose souvent aux étudiants d'employer doctest, un module Python qui exécute les exemples de code que l'on met dans la docstring sous forme de tests unités. C'est une façon pour moi de leur imposer de faire quelques tests unités, et de ne pas bâcler la documentation.

Par contre, pour tout ce qui concerne les commentaires "inline", c'est laissé à l'appréciation. En général, on a les deux extrêmes : le gars qui ne commente absolument rien, alors que ce sont loin d'être des experts en code et qu'ils font du code horrible, et horrible à lire. Et de l'autre, le gars qui va commenter absolument chaque ligne, jusqu'à mettre des trucs du genre "J'affecte x à y" quoi... C'est rare d'avoir le juste milieu.

À titre perso, je tâche de toujours commenter, dans tous les cas où il peut y avoir le moindre doute. Je préfère "perdre" 2 minutes à indiquer à quoi sert ce test ou dans quelle situation ce bout de code est utilisé que de devoir dans 2 mois, dans 6 mois, dans 5 ans, m'arracher les cheveux pendant une heure à comprendre c'est quoi ce machin et à quoi ça peut bien servir.

C'est une assurance sur le futur, en fait ! Faire le code une fois, c'est bien, mais je sais que la maintenance du bouzin, et son évolution pour faire un truc qui pas prévu dans les specs, ce sera pour Bibi. Et Bibi du présent a fini par songer à Bibi du futur, et à lui commenter les chausse-trappes ou la raison du pourquoi de ce comportement illogique demandé par le client, parce qu'il sait qu'une fois le projet "fini", toutes ces petites particularités seront oubliées, parce qu'il y aura un autre projet auquel penser, puis un autre, puis ...

C'est après des sessions de debug dans du code qui date de plus de 15 ans que tu comprends l'importance du code bien documenté/commenté.

Donc l'idée est bien de documenter les fonctions publiques/internes pour savoir ce qu'elles font (mais la documentation commence avec le bon nommage de la dite fonction), éventuellement de s'aider des tests unitaires pour documenter la fonction, et évidement de mettre du commentaire éventuellement inline pour une spécificité du frameword ou voulue par le client, un comportement "anormal".

Après le nommage d'une fonction, ça peut être un sacré casse-tête.

J'ai pris l'habitude de projets entièrement en anglais, vous codez aussi en anglais?

Parce que sur le principe, un
public bool EstTerminé()
ou un
public bool IsFinished()
c'est pareil

Je ne code qu'en anglais et je documente souvent en anglais également, par cohérence, mais surtout parce que beaucoup de termes n'ont pas vraiment d'équivalents français "répandus", parce que pratiquement toutes les API sont en anglais (et ça fait bizarre d'écrire x = obtenirFlux().getStreamContent()) et surtout parce que peu de langage autorise autre chose que de l'ascii pour le nommage (Python 3 autorise UTF-8 !), et donc on se retrouve avec "estTermine" au lieu de "estTerminé" pour reprendre ton exemple, ce qui n'est pas pareil

Idem, dans ma précédente boite en France, on codait en anglais, par contre, le commentaire était en français.
Note que VisualStudio s'en fout de l'encoding des caractères et que tu peux théoriquement avoir des variables, des fonctions, des interfaces avec des lettres accentuées sans problème de manière officielle.

Avec l'intellisense, tu t'en fous, c'est complété automatiquement quand tu as trouvé la fonction que tu veux, quelque soit les lettres accentuées

PetitCalgonNote que VisualStudio s'en fout de l'encoding des caractères et que tu peux théoriquement avoir des variables, des fonctions, des interfaces avec des lettres accentuées sans problème de manière officielle.

Ca dépend du langage, et à ma connaissance, ils sont bien peu nombreux à proposer ça en standard... Après, c'est sûr, si ta boîte a envie, elle peut simplement modifier la grammaire du langage et enjoy.

PetitCalgonAvec l'intellisense, tu t'en fous, c'est complété automatiquement quand tu as trouvé la fonction que tu veux, quelque soit les lettres accentuées

Oui mais non. Tu ne peux pas te reposer sur un outil pour justifier d'utiliser une langue qui, en dehors de ça, pose des soucis Par ailleurs, c'est dangereux, car tu peux alors mélanger des estTermine avec des estTerminé, etc. ce qui peut rendre le code encore plus difficile à lire/comprendre (et je suis sûr qu'on peut facilement trouver un exemple legit de mots français, traductions d'un terme usuel dans un code anglais, qui est ambigu et pourtant "nécessaire" dans le code).

Prochaines questions :
* camelCase, snake_case, jeanairien_a_Foutre_Case ? :D
* Espace vs tabs, et leur espacement

Pour répondre à anglais-français : majoritairement en anglais au niveau des variables et fonctions. Par contre, j'ai quelques exceptions dans les noms de variables principalement. Pourquoi des exceptions : ¡ no sé ! Mais jamais d'accents dedans, rien qu'à voir ton EstTerminé() je saigne des yeux !

Pour répondre à tes questions :
- La casse dépend de la convention proposée/imposée par le langage. C'est aussi une histoire de lisibilité : si tu respectes la casse, en un coup d'oeil, un lecteur comprendra la nature de l'identifiant. Pour ma part, sauf contre-indication du langage, c'est toujours camelCase pour les méthodes, snake_case pour les fonctions et pour les identifiants (variables, etc.). En Python, c'est "un peu plus délicat" vu que tout est objet, et que n'importe quel identifiant peut contenir à peu près n'importe quoi (méthode, fonction, objet, classe, ...). Ce qui fait qu'en "statique" dans le code, je respecte les conventions, et dès que j'introduis un identifiant, c'est snake_case.
- Espace, pardi ! On n'est pas à quelques caractères près au niveau du stockage du code, et c'est BEAUCOUP plus pratique, notamment quand tu changes d'éditeur ou que tu travailles en groupe sur le code. Et si VRAIMENT quelqu'un veut utiliser des tabulations, c'est un tab = 4 espaces, et pas 8 ! (A nouveau, c'est surtout parce que je travaille en Python et comme l'indentation est obligatoire pour délimiter les structures de contrôle, t'as pas envie de te retrouver à 80 caractères juste parce que t'es dans 10 structures de contrôle ^^).