Красимир обнови решението на 11.10.2012 11:02 (преди над 13 години)
- Слагай малко повече нови редове, така кодът ще стане по-четим. Особено седми ред е...
- Имена на променливи от типа
a,e,f,xи подобни, особено на един ред, е лош стил. Измисли им хубави, смислени имена. Макар и по-дълги, ще стане много по-ясно какво се случва. -
hashе по-добро име отh.grouped_values,grouped(или сродни) е по-добре отhash. И така...
Иначе нещата изглеждат добре. Занимавал ли си се с Ruby преди курса? :)
За това с имената съм съгласен - то е валидно за всички езици. Просто не можах да устоя да напиша първата част като one-liner :)
(седми ред е точно 80 символа - бях го докарал до към 70, ама беше грозно...), а оттам нататък, за консистентност... :) Специално за a и e прочетох в style-guide-а (accumulator / element) - семантично ги използвам като такива, въпреки че не и с reduce.
Това за a и e е едно от нещата, които не подкрепяме в този style guide и трябва да бъде променено :)
Тематично: http://37signals.com/svn/posts/3250-clarity-over-brevity-in-variable-and-method-names
Позволено ти е да пробваш веднъж как стават нещата на един ред, но го избягвай като принцип :)
@ pull
- Ако имаш толкова сложен
eachкато този вprime_divisor, направи го на няколко реда. -
fizzbuzz-а ти е сложен. Вместо да конструираш низове, далеч по просто е да имаш условие с четири разклонения. - Допълнително, това че
xеnilтам е твърде магическо, за да очакваш някой да го разбере. -
(h[v] ||= []) << kе супер гадно. По-добре го направи на два реда. -
self.е излишно.
Иначе, браво че си го направил толкова кратко. Щях да ти дам бонус точки, ако (1) беше оправил имената и (2) кода ти беше по-ясен. Оптимизирал си за компактност една идея повече, отколкото трябва.
