PS: oui je fais partie de ces vieux cons qui font de la résistance et qui utilisent encore la syntaxe ":foo => bar" au lieu de "foo: bar" =)
Le 16 juin 2012 00:13, Florian Dutey <[email protected]> a écrit : > Le multi-lignes sur le create ne me choque pas du tout, bien au contraire. > Mais bon, je suis un super maniaque de la présentation du code (j'aligne > tout :p) > > Ceci dit, ton bout de code, écrit différemment et tout aussi lisible à mon > gout, ne dépasse pas 61 chars la ligne > https://gist.github.com/2938865 > Dans ton cas, travailler avec des factories (ou des fixtures? :/) serait > surement beaucoup plus pratique. > > Pour revenir au sujet initial, 80 caractères, c'est quand même short, > surtout en ruby ou on n'a pas peur d'avoir de longs noms de méthodes / > variables. > Vu que j'aligne tout, il m'arrive d'atteindre les 90 chars, en particulier > dans mes validations ActiveModel. > Cependant, avoir des exigences à ce niveau est plutot une bonne chose: > > * avoir des lignes de 300 caractères dans un projet, c'est pénible, > surtout pour la relecture, et ca peut révéler certaines choses (sauf regexp > de ouf) > * avoir des lignes trop longues et/ou des méthodes de plus de X lignes (on > dit 25 / 30 en général), c'est souvent révélateur de méthodes qui font trop > de boulot et qu'il faut factoriser > > Ne rien spécifier, c'est souvent aussi coder sans norme. > Or, coder sans norme tout seul, c'est parfois prendre trop de temps sur la > manière de présenter ton code ou ne pas être capable de te relire par la > suite. > Et coder sans norme en équipe, c'est la foire. On a du code qui commence > d'une manière, qui finit d'une autre. C'est dur pour lire le code des > autres et encore plus affreux de lire un même code écrit par plusieurs > personnes différentes. > > Cdlt =) > > Le 15 juin 2012 23:26, lucas di cioccio <[email protected]> a > écrit : > > Réponse inline: >> >> Le 15 juin 2012 15:43, Guirec Corbel <[email protected]> a écrit : >> >> Bonjour, >>> >>> Régulièrement, je me trouve confronté avec des problèmes de taille de >>> lignes. Selon certains conventions, une ligne ne devrait pas faire plus de >>> 80 caractères, comme indiqué ici : >>> http://www.caliban.org/ruby/rubyguide.shtml#linelen . J’essaie donc de >>> respecter cette convention sans être toujours très regardant. Pour être >>> honnête, cette règle me fait ch... et j'ai toujours de la difficulté à m'y >>> tenir. De plus, ça me donne parfois des trucs que je ne trouve pas beau. >>> J’essaie de suivre des conventions mais je n'en ai pas trouvé sur internet. >>> >>> Exemple : >>> >>> describe :note_for do >>> it 'give notes for the project' do >>> >>> >>> >>> CategoryProject.create(project: project, >>> category: category, >>> description: 'test') >>> >>> >>> >>> Note.create(project: project, category: category, value: 8) >>> >>> >>> >>> Note.create(project: project, category: category, value: 3) >>> >>> >>> >>> Note.create(project: project, category: category, value: 3) >>> >>> >>> >>> project.note_for(category).should == 4.7 >>> end >>> end >>> >>> Je trouve pas ça super gracieux. En plus de ça, j'ai vu que rails ne se >>> limite pas à 80 caractères mais plutôt à 120? Exemple : >>> https://github.com/rails/rails/blob/master/actionmailer/lib/action_mailer/base.rb >>> . >>> >>> >>> Vu qu'il y a des variables locales en Ruby, pourquoi ne pas les utiliser? >> >> params = {blablabla} >> Note.create params >> >> qui rend facile le refactoring en >> >> def note(params) >> Note.create params >> end >> >> Ce qui n'a pas forcément du sens dans du code, mais peut aérer une série >> de tests ou déboucher sur un module DSL pour une librairie. >> >> Enfin le multiline a aussi des avantages, comme de pouvoir commenter une >> ligne pour désactiver quelquechose. >> >> params = { >> foo:'bar', >> #baz:123 >> } >> >> A utiliser avec parcimonie car ça rajoute plein de scrolling vertical et >> ça encourage à laisser traîner des '#' de commentaires dont on oublie >> l'utilité. >> >> De même j'utilise des lignes longues, pour des messages d'erreurs/de log >> inline. Genre raise ArgumentError, "une explication trop longue à tenir sur >> 80chars". Le backslash en fin de ligne peut aider pour ce cas mais je ne >> trouve pas ça esthétique. >> >>> Bref, voici donc ma question : Qu'utilisez vous comme normes? >>> >>> >>> Celle du projet que je touche. Ou bien le bon sens. Quand j'ai beaucoup >> de paramètres parfois je fais une classe dont la responsabilité est de >> paramétrer les autres objets :o, ça me donne l'impression de maîtriser le >> JavaSyndromeFactoryBuilder. >> >> --Lucas >> >>> >>> Merci encore pour tout vos bons conseils! >>> >>> -- >>> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" >>> de Google Groups. >>> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse >>> [email protected] >>> Pour résilier votre abonnement envoyez un e-mail à l'adresse >>> [email protected] >> >> >> -- >> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" >> de Google Groups. >> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse >> [email protected] >> Pour résilier votre abonnement envoyez un e-mail à l'adresse >> [email protected] >> > > -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected]
