Je présume que j'aurais du mettre dans un nouveau paragraphe ma dernière ligne pour en faire l'emphase. Dans mon idée, il n'y a pas de règles absolue en programmation, il y a des règles que l'on choisi de suivre ou pas et une règle que l'on choisi de suivre, on peut aussi la violer si on a une bonne raison de le faire. Tout ça pour dire que oui des cas particuliers il y en a pleins, ils sont peut être même pas particulier et peut être que c'est le cas général. J'ai dis que je me posais las question. Grosso modo quand je vois un commentaire qui fait plusieurs lignes, je me pose la question d'envoyer le code qui suit dans une fonction.
Pour ta description en 3 points ça ne veux pas dire grand chose à peu près tout algorithme peut se décrire en quelques points. Ça dépend uniquement du niveau de précision que tu souhaite (et je t'avoue que je n'ai que peut d'idée de la complexité ou non d'un carrousel. Je suis tout de même surpris qu'il n'y ais pas de composant de haut niveau pour faire ça et que tu te retrouve à travailler sur des rectangles, mais c'est peut être une question de performance.
En parlant de performance quand tu dis que les fonctions consomment des performances, je trouve ça bien dommage, je ne sais pas si c'est un problème du compilateur ou de ton usage de celui-ci, mais l'inlining n'a rien de nouveau et si (dans les langages qui le permettent, je ne sais pas si c'est le cas de l'objective-C) on donne assez d'informations au compilateur, il devrait être capable d'inliner une méthode. Ce qui est dommage c'est que tu te retrouve à viser les performances très (trop à mon avis) tôt dans le développement. Que l'architecture soit pensée pour produire une performance voulue c'est une chose, se poser la question de créer une variable ou devoir inliner à la main (c'est un comble après 60 ans d'avancée dans le domaine de la programmation), c'est à mon avis dommage.
Bref tu as sans aucun doute raison de faire comme tu fais (je n'en sais rien). Ce que je pense sais qu'avoir des pavés de commentaires au sein d'une fonction indique à minima qu'il y a des blocs de code au quels il faut faire particulièrement attention, ils sont complexes (suffisamment pour mériter d'avoir un bloc de commentaire) et pas testé unitairement (c'est l'ensemble qui l'est). Ce qui implique d'avoir des batteries de tests plus importantes et dont la granularité est plus large.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: /* commentaire ou documentation inline ? */
Posté par barmic . En réponse au journal To comment or not to comment. That is the question.. Évalué à 7.
Je présume que j'aurais du mettre dans un nouveau paragraphe ma dernière ligne pour en faire l'emphase. Dans mon idée, il n'y a pas de règles absolue en programmation, il y a des règles que l'on choisi de suivre ou pas et une règle que l'on choisi de suivre, on peut aussi la violer si on a une bonne raison de le faire. Tout ça pour dire que oui des cas particuliers il y en a pleins, ils sont peut être même pas particulier et peut être que c'est le cas général. J'ai dis que je me posais las question. Grosso modo quand je vois un commentaire qui fait plusieurs lignes, je me pose la question d'envoyer le code qui suit dans une fonction.
Pour ta description en 3 points ça ne veux pas dire grand chose à peu près tout algorithme peut se décrire en quelques points. Ça dépend uniquement du niveau de précision que tu souhaite (et je t'avoue que je n'ai que peut d'idée de la complexité ou non d'un carrousel. Je suis tout de même surpris qu'il n'y ais pas de composant de haut niveau pour faire ça et que tu te retrouve à travailler sur des rectangles, mais c'est peut être une question de performance.
En parlant de performance quand tu dis que les fonctions consomment des performances, je trouve ça bien dommage, je ne sais pas si c'est un problème du compilateur ou de ton usage de celui-ci, mais l'inlining n'a rien de nouveau et si (dans les langages qui le permettent, je ne sais pas si c'est le cas de l'objective-C) on donne assez d'informations au compilateur, il devrait être capable d'inliner une méthode. Ce qui est dommage c'est que tu te retrouve à viser les performances très (trop à mon avis) tôt dans le développement. Que l'architecture soit pensée pour produire une performance voulue c'est une chose, se poser la question de créer une variable ou devoir inliner à la main (c'est un comble après 60 ans d'avancée dans le domaine de la programmation), c'est à mon avis dommage.
Bref tu as sans aucun doute raison de faire comme tu fais (je n'en sais rien). Ce que je pense sais qu'avoir des pavés de commentaires au sein d'une fonction indique à minima qu'il y a des blocs de code au quels il faut faire particulièrement attention, ils sont complexes (suffisamment pour mériter d'avoir un bloc de commentaire) et pas testé unitairement (c'est l'ensemble qui l'est). Ce qui implique d'avoir des batteries de tests plus importantes et dont la granularité est plus large.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)