Je commence à me dire que c'est qu'il faut redécouper la fonction. Je suis pour les commentaires dans les fonctions, mais de plus en plus souvent je me dis que quand tu as un commentaire qui doit décrire une sous partie de ta fonction, c'est que ça doit en être une nouvelle
Mouais, ca depend beaucoup de ce que tu fais. Je bouffe taquet d'ios ces jours (grande nouvelle), c'est pour l'essentiel 90% d'UI, 9% d'appel REST, et 1% de trucs d'informaticien couillu qui ont de la barbe, avec des contraintes de performance assez forte: ca doit etre fluide et leger sur le cpu, meme sur un 3gs d'antan.
L'ui, pour que ca soit a la fois joli, elegant et rapide, ya pas: c'est long et verbeux. Typiquement, j'ai une classe "Carousel" (le truc ou tu swipes les photos une par une), avec le coeur du machin qui est du layout avec flyweight. Comme on dit par chez moi, ya pas a tortiller du cul pour chier droit, si tu veux faire ca, faut:
1) prendre l'offset de la scroll view, regarder si t'as deja une tile a cette endroit
2) si non, en demander une nouvelle, la stocker localement et repartir a 1)
3) si oui, prendre l'offset de fin, et faire la meme chose que 2, mais a reculons
Tu tournes le code comme tu veux, ca prend 150 lignes avec commentaires. Une centaine sans. L'essentiel, c'est des calculs de rectangles, sur la stack, et tu vas pas te faire chier a creer des fonctions parce que ca serait decouper just pour le plaisir de decouper, et en pratique ca eloigne juste le code de la ou il devrait etre (sans compter l'overhead de performance sur une fonction qui est appele tres souvent, ca scrolle tres vite une scroll view UIKit. Et oui, j'ai mesure l'impact, il est pas négligeable).
Et pour etre passer derriere et avoir debugge ce truc, pour finir par "aaaw, fuck it, je vais reprendre tout le code et passer un jour ou deux a tout commenter/documenter", ce qui l'a fait doubler de taille, croit moi t'es tres tres tres content de trouver des commentaires qui expliquent que si ce rectangle la, il a un origin.x qui est inferieur a machin, alors ca veut dire que machin, et que donc tu peux zapper cette tile parce que blabla.
Et au passage, ca m'a fait corriger qq bugs ( 2-3 edge cases et un de performance ou une collection etait iteree en permanence).
Des exemples comme ca, j'en ai plein mon code: dimensionnement dynamique + layout avec animations par ci, REST client qui envoye des payload avec 25 champs sur l'objet envoye. J'y peux rien, la nature de la fonction est de faire 150 lignes. Je peux la decouper artificiellement et repasser les parametres calcules aux dites fonctions, mais:
1) c'est debile
2) ca rend la comprehension du code vachement plus dur (-doSomething1: (id) param; -doSomething2: (id) param withOtherParam: (id) paramCalculeDansdoSomething1)
[^] # Re: /* commentaire ou documentation inline ? */
Posté par groumly . En réponse au journal To comment or not to comment. That is the question.. Évalué à 5.
Mouais, ca depend beaucoup de ce que tu fais. Je bouffe taquet d'ios ces jours (grande nouvelle), c'est pour l'essentiel 90% d'UI, 9% d'appel REST, et 1% de trucs d'informaticien couillu qui ont de la barbe, avec des contraintes de performance assez forte: ca doit etre fluide et leger sur le cpu, meme sur un 3gs d'antan.
L'ui, pour que ca soit a la fois joli, elegant et rapide, ya pas: c'est long et verbeux. Typiquement, j'ai une classe "Carousel" (le truc ou tu swipes les photos une par une), avec le coeur du machin qui est du layout avec flyweight. Comme on dit par chez moi, ya pas a tortiller du cul pour chier droit, si tu veux faire ca, faut:
1) prendre l'offset de la scroll view, regarder si t'as deja une tile a cette endroit
2) si non, en demander une nouvelle, la stocker localement et repartir a 1)
3) si oui, prendre l'offset de fin, et faire la meme chose que 2, mais a reculons
Tu tournes le code comme tu veux, ca prend 150 lignes avec commentaires. Une centaine sans. L'essentiel, c'est des calculs de rectangles, sur la stack, et tu vas pas te faire chier a creer des fonctions parce que ca serait decouper just pour le plaisir de decouper, et en pratique ca eloigne juste le code de la ou il devrait etre (sans compter l'overhead de performance sur une fonction qui est appele tres souvent, ca scrolle tres vite une scroll view UIKit. Et oui, j'ai mesure l'impact, il est pas négligeable).
Et pour etre passer derriere et avoir debugge ce truc, pour finir par "aaaw, fuck it, je vais reprendre tout le code et passer un jour ou deux a tout commenter/documenter", ce qui l'a fait doubler de taille, croit moi t'es tres tres tres content de trouver des commentaires qui expliquent que si ce rectangle la, il a un origin.x qui est inferieur a machin, alors ca veut dire que machin, et que donc tu peux zapper cette tile parce que blabla.
Et au passage, ca m'a fait corriger qq bugs ( 2-3 edge cases et un de performance ou une collection etait iteree en permanence).
Des exemples comme ca, j'en ai plein mon code: dimensionnement dynamique + layout avec animations par ci, REST client qui envoye des payload avec 25 champs sur l'objet envoye. J'y peux rien, la nature de la fonction est de faire 150 lignes. Je peux la decouper artificiellement et repasser les parametres calcules aux dites fonctions, mais:
1) c'est debile
2) ca rend la comprehension du code vachement plus dur (-doSomething1: (id) param; -doSomething2: (id) param withOtherParam: (id) paramCalculeDansdoSomething1)