Решение на Четвърта задача от Николай Хубанов

Обратно към всички решения

Към профила на Николай Хубанов

Резултати

  • 0 точки от тестове
  • 0 бонус точки
  • 0 точки общо
  • 0 успешни тест(а)
  • 0 неуспешни тест(а)

Код

REPOSITORY = 'http://github.com/nhubanov/ruby-retrospective-1'
# 1. "Monkey patching"-ът не е добър похват като цяло и трябва да се използва само в краен случай.
# 2. Не е задължително да се пише self за да се обръщаме към instance променливите на даден клас.
# 3. Не е задължително да се визма блок, подаден на метод, в променлива.
# 4. По-добре е да се използва map вместо each, когато искаме да съпоставим на всеки елемент от дадена колекция нещо друго.
# 5. for не е предпочитан оператор в Ruby. Предпочитат се each, map и други вгадени методи, които в огромна част покриват функционалността му.
# 6. Ruby има много голям набор от стандартни методи, които не са толкова "стандартни" за повечето езици(напр.: each_cons, slice и др).
# 7. Може списък от променливи да се инициализират чрез масив(напр.: a, b, c = array[0..2]).
# 8. По-разбираемо е да се използва map, отколкото each и деструктивен метод.
# 9. Извикването на map, select и т.н. с прости ламбди може да стане с &символ, което предизвиква изпълнението на съответната ламбда.
#10. Препоръчително е изпозлването на all?, none? и т.н., тъй като правят кодa по-лесно разбираем.
#11. Трябва да се избягват повторенията на един и същ (или много подобен) код - преодолява се чрез изнасянето му във функция, изпозлване на функционалността на езика (напр. меотда send) или др.
#12. obj.nil? е за предпочитане пред obj == nil, като и !obj пред obj == false.
#13. Употребата на case води до по-четим код.
#14. Null object pattern
#15. Всеки клас е добре да отговаря само за едно действие/състояние.
#16. Класовете не трябва да зависят пряко от имплементацията на останалите.
#17. Single Responsibility Principle
#18. Използванетона inject е препоръчилтено, когато акумулираме резултат от елементите на някоя колекция.
#19. Съществува предикат nonzero?
#20. Трябва да се вземе предвид до каква степен ще се добавят нови функционалности при дизайна на решението
#като цяло
# Tрябва да се използват в максимална степен възможностите на езика - модулът Enumerable, вградени предикати и др вградени методи.
# Трябва да се следват конвенциите и кодът да е консистентен - именоване на обектите, whitespace-и и т.н.
# Кодът трябва да е максимално ясен и да бъде лесен за поддръжка.
# В Ruby излишният код не се толерира - излишни then-ове, скоби и т.н.

История (1 версия и 0 коментара)

Николай обнови решението на 14.11.2011 15:51 (преди над 12 години)

+REPOSITORY = 'http://github.com/nhubanov/ruby-retrospective-1'
+
+# 1. "Monkey patching"-ът не е добър похват като цяло и трябва да се използва само в краен случай.
+# 2. Не е задължително да се пише self за да се обръщаме към instance променливите на даден клас.
+# 3. Не е задължително да се визма блок, подаден на метод, в променлива.
+# 4. По-добре е да се използва map вместо each, когато искаме да съпоставим на всеки елемент от дадена колекция нещо друго.
+# 5. for не е предпочитан оператор в Ruby. Предпочитат се each, map и други вгадени методи, които в огромна част покриват функционалността му.
+# 6. Ruby има много голям набор от стандартни методи, които не са толкова "стандартни" за повечето езици(напр.: each_cons, slice и др).
+
+# 7. Може списък от променливи да се инициализират чрез масив(напр.: a, b, c = array[0..2]).
+# 8. По-разбираемо е да се използва map, отколкото each и деструктивен метод.
+# 9. Извикването на map, select и т.н. с прости ламбди може да стане с &символ, което предизвиква изпълнението на съответната ламбда.
+#10. Препоръчително е изпозлването на all?, none? и т.н., тъй като правят кодa по-лесно разбираем.
+#11. Трябва да се избягват повторенията на един и същ (или много подобен) код - преодолява се чрез изнасянето му във функция, изпозлване на функционалността на езика (напр. меотда send) или др.
+#12. obj.nil? е за предпочитане пред obj == nil, като и !obj пред obj == false.
+
+#13. Употребата на case води до по-четим код.
+#14. Null object pattern
+#15. Всеки клас е добре да отговаря само за едно действие/състояние.
+#16. Класовете не трябва да зависят пряко от имплементацията на останалите.
+#17. Single Responsibility Principle
+#18. Използванетона inject е препоръчилтено, когато акумулираме резултат от елементите на някоя колекция.
+#19. Съществува предикат nonzero?
+#20. Трябва да се вземе предвид до каква степен ще се добавят нови функционалности при дизайна на решението
+
+#като цяло
+# Tрябва да се използват в максимална степен възможностите на езика - модулът Enumerable, вградени предикати и др вградени методи.
+# Трябва да се следват конвенциите и кодът да е консистентен - именоване на обектите, whitespace-и и т.н.
+# Кодът трябва да е максимално ясен и да бъде лесен за поддръжка.
+# В Ruby излишният код не се толерира - излишни then-ове, скоби и т.н.