Discussion :

[patxy]

Si tu avais définis des symboles comme (pour reprendre la liste de ton code)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
INTERNAL_OCILLATOR_FUNCTION_ON
USE_DIRECTLY_OSCILLIATOR
PRIMARY_CLOCK_ENABLED
FAIL_SAFE_CLOCK_MONITOR_ENABLED
POWER_UP_TIMER_ENABLED
BROWN_ON_RESETE_ENABLED
WATCH_DOC_TIMER_ENABLED
SINGLE_SUPPLY_ICSP_ENABLED
/* désolé, je ne vois pas à quoi correspondent les deux derniers */

quitte à les définir comme étant le symbole correspondant requis pour ton pragma, tu n'aurais absolument pas eu besoin des commentaires, et je peux t'assurer que ni ta machine de compilation ni ton binaire final n'aurait souffert d'avoir des symboles de 30 caractères

Oui, mais au final, l"utilisation des commentaires est largement plus logique...

Je suis d'accord avec toi que dans 90% des cas, l'utilisation des commentaires est due à un nommage tout pourri, ou à un code pas "bien" écrit. Mais tu ne peux etre aussi catégorique est t'amuser à augmenter la complexité du code pour te donner raison...



Et sinon, il n'y a pas que sur des langages bas niveau qu'il faut des commentaires. Petit exemple en c# :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
            if (tableNames.Contains(tableToQuery))                                  //To prevent from sql injection
            {
                try
                {
                    Command myCommand = new Command(string.Format("SELECT * FROM {0}", tableToQuery));
                    myContent = dbConnect.GetDataSet(myCommand).Tables[0];
                }
                catch (Exception)
                {
                    throw;
                }
            }

Quand tu travailles en équipe, mettre ce genre de justification pour éviter que quelqu'un, qui trouve le "if" inutile ne décide un jour de le bypasser.

[sekaijin]

un petit exemple rencontré il y a peu.

dans un dev utilisant un framework ou les règles de l'art prone une certaine conception, je suis tombé sur un code qui allait totalement à l'encontre de tout ce que je pensais être correct.

1) cette conception ne respectait pas le B.A.BA. du dev Objet. disont qu'un developpeur ayant des connaissance en POO aurait pour première réaction de dire "mais ce truc est pourit mieux faire comme ci ou comme ça..."

2) en se référant aux Standard du dit framework, là encore le code parait abérant contre productif mal structuré difficile à maintenir et a faire évoluer.

et point important même si le nom des méthodes est clair. la lecture du code ne permet pas simplement de comprendre ce qu'il fait.

en cherchant un peux auprès de l'équipe qui à pondu le truc. cette portion de code abérante en apparence et issue d'une modification murement réfléchie suite à une longue camapgne de test.

il se trouve que le contexte dans lequel est utilisé le produit n'est pas celui dans lequel le framework a été pensé. le choix reste pertinant mais la monté en charge à (très) grande échelle a révélé de petit pb. il s'agit de java. et si aucune fuite memoire n'a été trouvée. la combinaison du framework associé à son environnement d'exécution et à la conception dite standard lorsque la plateforme ateignait des charge très élevé impliquait une croissance minime mais continue du nombre de classes chargées dans la JVM.

une abération comment, alors qu'aucun code suplémentaire n'est déployé que tous les objets sont libérés, le nombre de classe peut augmenter ?

finalement le problème à été trouvé et le correctif est ce code étrange.

les doc de conceptions ont été revu et mis à jour. Mais le code lui n'avait aucun commentaires.

à y regarder de près ce code n'est pas mal écrit. nous avons juste tous appris dans nos formations à ne surtout pas le concevoir ainsi.

J'ai fais ajouter à ce code un pavé de commentaire avec des référence au dossier de conception et au cahier de test de charge.

c'est un code bien écrit, bien conçu par rapport au contexte et au besoin, mais totalement non conforme aux habitudes ou précos.
et je pense qu'il a effectivement besoin de commentaires.

A+JYT

[Matthieu Vergne]

De la même manière que quand tu parles de quelque chose de complexe en langage naturel il te faut expliquer ce que tu veux dire par là : l'objectif étant de parler de cette chose complexe tu ne peux pas passer à côté de la complexité, les "commentaires" deviennent donc nécessaire pour la compréhension.

D'où mon avis que les optimisations sont les seules à nécessiter du commentaire, car c'est là que tu mets en avant les perfs et non la lisibilité du code (donc tu exploites les subtilité du langage, pas ses évidences). Jusqu'à maintenant c'est le seul genre de cas que j'ai vu où les commentaires sont nécessaires pour comprendre (toujours sans parler de tutos ni de cartouche). Et c'est aussi ce qui justifierait de faire un code abscons parce qu'on fait de la programmation sur microcontrôleur avec des contraintes des perfs fortes (bien qu'aujourd'hui les noms, a priori, peuvent être plus explicites que de simples acronymes).

[souviron34]

Je me permet de poster un petit commentaire ()

J'avoue ne pas très bien saisir l'intérêt de cette nouvelle discussion alors qu'il existe plusieurs (dont certains longs, et/ou dans les Best-Of) débats sur le forum Débats spécialsé sur ce sujet :

Faut-il commenter son code-source pour le rendre plus lisible et maintenable ?

De l'intérêt des commentaires

Un code bien commenté remplace-t-il une documentation (+ gestion doc entreprise)

Projets informatiques : les bonnes pratiques



ça sert à rien, d'avoir déjà des sujets où on s'est exprimé longuement ??
On va pas recommencer à chaque fois...

[Matthieu Vergne]

Laisse la place à ceux qui ne se sont pas encore exprimé sur le sujet {^_^}.

[souviron34]

ben voui, mais ils pourraient lire ce que d'autres ont posté, et y répondre ou s'en enrichir, non ??

C'est bien le but d'un forum, non ???


Si c'est pour tout recommencer à partir de zéro à chaque fois...

[Matthieu Vergne]

Tout le monde n'a pas la patience de lire des centaines de messages, surtout quand ça a tendance à devenir répétitif et bordelique. Et le fait que ça a déjà été dit n'est pas une bonne raison pour ne pas le redire. Justement parce que tout le monde ne lit pas tout, mais aussi parce que c'est pas comme ça qu'on apprends {^_^}.

DRY c'est bien pour la productivité, pas pour l'apprentissage. Faut pas hésiter à répéter, reformuler, reconfronter pour se faire vraiment sa propre idée. C'est pas juste en lisant qu'on apprend.

[souviron34]

Moi je veux bien, hein ...

M'enfin, ya kan même un p'tit bouton :



Vu la section de ce thread, on n'est pas dans la section "Actualités", donc ça devrait peut-être être utilisé, non ??

'fin bon, j'dis ça...

Mais je trouve que avoir plusieurs threads qui parlent de la même chose, où des gens ont pris la peine de s'exprimer et de s'expliquer, dans la même section, et qui en plus se dénomme "The Best Of", ça le fait pas, c'est tout..

[Matthieu Vergne]

Perso, je vois l'utilité de la recherche et relecture dans le cas où tu as effectivement des problème précis à régler. Mais là c'est vraiment de la philo, parce qu'en pratique chacun s'adapte à ce qu'il a sous la main. Par contre c'est vrai qu'un seul sujet serait peut-être plus adapté. Mais ça pourrait être un débat à part entière {^o^}.

[Matthieu Vergne]

Peut-être de quoi relancer le sujet :
http://fr.wikipedia.org/wiki/Programmation_lettr%C3%A9e

NB : Je n'ai pas (encore) testé.

[sekaijin]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
with myForm
put the value of field "user" into the field "login" of object "connection" of object "myEchange";

connect "myEchange" with password the field "pass";

J'ai adoré programmé ainsi. après un roman de 10 pages pour faire hello word
on a vite fait de revenir aux bons vieux langages.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
myExchange.connection.login = myForm.user;
myEchange.connect(myFrom.pass);

[souviron34]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
with myForm
put the value of field "user" into the field "login" of object "connection" of object "myEchange";

connect "myEchange" with password the field "pass";

Je trouve qu'en fait ceci est à peu de choses près ce qui s'appelle de la "conception préliminaire" dans le cycle en V..

Sauf que justement, absolument tous les exemples et expériences que l'on peut avoir avec la conception préliminaire indiquent que la réalisation ne PEUT pas suivre.... justement à cause des machines, contraintes, ré-utilisations, etc etc..

[Matthieu Vergne]

Moi je vois ça comme une fusion de la conception + implémentation, ce qui permet au moins de s'assurer que ces deux là restent alignés. Si on étant ça au cahier des charges, ça fait un tout cohérent. Après oui il faut aimer lire, mais après la structure du doc est là pour aider a priori.

Pour moi coder et documenter, même combat, y'a que le langage qui change. Donc à ce titre je trouve que c'est pas une mauvaise idée. Mais si tu cherches à distribuer les tâches, c'est peut-être plus chaud j'en conviens. Encore que ça reste discutable je pense : dans une équipe, tu peux aussi distribuer la rédaction d'un même doc.

Un Hello World tu le fais pour découvrir le langage de prog, tu fais pas une conception pour ça. La conception c'est toujours assez lourd, faut l'utiliser là où ça vaut le coup. Le Hello World me semble pas être un très bon exemple {'^_^}.

[AdmChiMay]

Les commentaires du code, c'est une chose. Mais le code n'est en principe pas tout seul. Par exemple, chez "nous", il y a une tripotée de documents qui devraient exister, parlant de rapports d'opportunité, de faisabilité, de définition du besoin, de conception générale, de conception détaillée, et encore d'autres sur l'installation et la mise en production.

Je ne rentrerai pas dans les détails, en particuliers pour savoir si tous ces documents sont systématiquement produits, ou abr(é|o)gés.

Bref, si celui sur la conception détaillée, qui doit permettre de rentrer dans les détails (de la demande du client qui a été acceptée) avant de lire le code, est correct, à quel niveau doit-on commenter le code ? Est-ce selon l'existence ou non de règles de codage locales ?

Sinon, il y a …hum…un certain temps… un copain disait : 6 mois de stage = 5 mois de réflexions et d'algorithmes, et 1 mois de codage une fois tous les commentaires faits. À l'expérience, ça se tient. Ce n'est que mon avis.

[andry.aime]

ça m'a fait rappeler à cette discussion:

<A> Tu sais, d'habitude, tu commences tu as un code super propre, nickel, plein de commentaires.
<B> En théorie, oui...
<A> Et puis après, tu rajoutes plein d'options, tu développes, tu bidouilles, tu mets un peu de scotch dans un coin pour que ça fonctionne, tu fous des variables avec des noms stupides, et tu t'y retrouves plus dans ton code.
<B> Ca me parle plus comme façon de coder oui !
<A> Bin là, je viens de faire le contraire... J'ai super bien pensé mon code au début, je l'ai bien commenté comme il faut dans tout les sens. J'ai prototypé toutes mes fonctions. J'ai fait un truc nickel. Même à la fin, quand tout fonctionnait, je me retrouvais dans la moindre parcelle de code...
<B> Et... ?
<A> Mon client m'a fait enlever toutes les options. L'une après l'autre. Et j'ai du me débrouiller comme je pouvais pour tout ajuster. Du coup, maintenant j'ai un truc super simple, avec deux fonctionnalités et quart, que j'ai passé 5 jours à coder, et je m'y retrouve plus nul part dans le code...

[GPPro]

ça m'a fait rappeler à cette discussion:

Ok c'est une blague, mais s'il avait réellement bien pensé son code enlever des fonctionnalités ne devrait pas avoir d'impact sur le reste. My 2 cents.

[Matthieu Vergne]

Sauf si son "bien pensé" veut dire avoir exploité au mieux les dépendances entre ses différents concepts, et non avoir exploité au mieux les indépendances. Dans ce cas j'imagine que ça devait être particulièrement difficile à découpler {'^_^}. Cela dit je suis un peu du même avis : quitte à enlever des options, il s'agit juste de leur donner des valeurs par défaut, et non de les enlever à proprement parler.

[souviron34]

quitte à enlever des options, il s'agit juste de leur donner des valeurs par défaut, et non de les enlever à proprement parler.

bah c'est même encore plus simple : tu enlèves les élements correspondants dans les menus, et c'est fini...

Et si c'est bien fait, c'est juste éditer un fichier texte... (au pire xml)

[el_slapper]

bah c'est même encore plus simple : tu enlèves les élements correspondants dans les menus, et c'est fini...

Et si c'est bien fait, c'est juste éditer un fichier texte... (au pire xml)

Tu penses en transactionnel. En batch, ça peut ne pas être aussi bateau. Si tu as une chaine complète qui fait plein d'opérations qui se suivent, en désactiver une peut avoir un impact sur la suivante. Juste oter l'étape du script peut avoir pas mal d'effets de bords, suivant les cas.

[koala01]

Tu penses en transactionnel. En batch, ça peut ne pas être aussi bateau. Si tu as une chaine complète qui fait plein d'opérations qui se suivent, en désactiver une peut avoir un impact sur la suivante. Juste oter l'étape du script peut avoir pas mal d'effets de bords, suivant les cas.

Attention, il parle ici d'éléments optionnels

C'est donc typiquement des étapes pour lesquelles on laisse le choix à l'utilisateur de fournir des valeurs qui lui sont propres

Il ne s'agit donc pas de retirer une étape nécessaire à l'exécution, il s'agit de "cacher" la possibilité à l'utilisateur d'introduire une valeur qui sera utilisée par cette étape, et ca, même en batch, il suffit généralement de fournir une valeur par défaut et de supprimer la ligne d'aide qui est associée à cette valeur