Списъци от символи с %i( foo bar baz )

Програмиране с Ruby

Курс във Факултета по Математика и Информатика към СУ

Решение на Пета задача от Снежана Спасова

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

Към профила на Снежана Спасова

Резултати

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

Код

REPOSITORY = 'https://github.com/snejy/ruby-retrospective-4/'
# Двадесет неща, които научих:
#
# От първа задача :
#
#1. Понякога е по-добре да напишем нещо по-дълго, но по-четимо отколкото нещо кратко и трудно разбираемо особено когато решението е просто.
#2. По-добре е да използваме прости структури на езика за по-добра четимост, отколкото нещо сложно, което не сме сигурни как точно работи и задачата не налага използването му.
#3. Хубаво е да помислим дали не можем да напишем нещата по-лесно с една функция, отколкото да се втурнем веднага да пишем различни функции за всяка една възможна ситуация.
#4. Четимостта на тернарните оператори е доста по-трудна от проста if-then-else или switch/case/ конструкция.
#
# От втора задача :
#
#5. Научих, че е хубаво добре да разгледаме какви вградени функции има и след това да си изберем тази, която най-много ни помага в случая и се чете по-лесно Пример: вместо number.class == Integer е много по-четимо number.is_a? Integer.
#6. По-хубаво е да избираме име, според това какво съдържа дадена променлива отколкото просто какво представлява Пример: numbers е по-добро име за масив, в който пазим числа, отколкото container, защото от numbers се разбира какво точно има там, а от container - не.
#7. Хубаво е да избягваме скобите при всеки възможен случай, особено когато не пречи на четимостта на кода.
#8. Винаги има какво да промениш по кода си, за да го направиш по-четим, дори и това да е просто преименуване на класовете, методите или променливите.
#
# От трета задача :
#
# 9. String#split приема като втори аргумент число(граница), което указва на колко части да се раздели низа.
# 10. Може да вземем стойност от метод чрез интерполация ( не само на променливи ).
# 11. Ако извикаме String#to_f на низ от цяло число, то метода превръща числото в тип Integer, a не Float.
# 12. Следствие от предния извод: понякога има неща, които не ги пише и в документацията, а човек ги открива чрез тестване, затова е хубаво винаги да експериментираме с вградените фунцкии, които ползваме и да се опитваме да предвидим всеки възможен случай (exception или не).
# 13. Можем да използваме case конструкция директно при assign-ване на стойност на променлива и дори е доста по-четимо, ако го правим така, а не отделно във фунцкия.
# 14. Хубаво е да избягваме self, където не ни трябва. ( Препоръчва се и според Ruby-Style-Guide-а)
# 15. Когато в модул създаваме обекти от клас, дефиниран в даденият модул, не е нужно да го извикваме с името на модула. Тоест вместо RBFS::Directory.new е по-добре да напишем Directory.new.
# 16. Много по-лесно е да изнесем някаква логика в отделен клас (като Parser например) вместо да се мъчим да дефинираме всичко в различни ирелевантни методи за класа, който го използва.
# 17. Когато имаме хетерогенен контейнер с два вида обекти вътре е много по-лесно да ги разделим в два контейнера, отколкото да се мъчим да ги филтрираме по някакъв наш измислен начин.
# 18. Когато метода прави само едно нещо и то е особено очевидно (например превръща низ в обект от тип boolean) не е нужно да изнасяме конвертирането в друг метод #to_bool, когато можем директно да използваме начина на конвертиране (string_boolean == 'true') и няма нужда да търсим къде е дефиниран този метод и какво прави.
#
# От четвърта задача :
#
# 19. Преди да започнем да решаваме дадена задача е по-добре да прочетем цялото условие няколко пъти ( ОСОБЕНО КОГАТО то е доста дълго ), отколкото да започнем да я пишем и да се оплетем в грешна логика още от самото начало.
# 20. Много по-лесно и четимо е да разделим многото функционалности на една задача в различни помощни класове, отколкото да се опитваме да ги дефинираме в един или два класа.

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

Снежана обнови решението на 19.01.2015 14:21 (преди около 9 години)

+REPOSITORY = 'https://github.com/snejy/ruby-retrospective-4/'
+
+# Двадесет неща, които научих:
+#
+# От първа задача :
+#
+#1. Понякога е по-добре да напишем нещо по-дълго, но по-четимо отколкото нещо кратко и трудно разбираемо особено когато решението е просто.
+#2. По-добре е да използваме прости структури на езика за по-добра четимост, отколкото нещо сложно, което не сме сигурни как точно работи и задачата не налага използването му.
+#3. Хубаво е да помислим дали не можем да напишем нещата по-лесно с една функция, отколкото да се втурнем веднага да пишем различни функции за всяка една възможна ситуация.
+#4. Четимостта на тернарните оператори е доста по-трудна от проста if-then-else или switch/case/ конструкция.
+#
+# От втора задача :
+#
+#5. Научих, че е хубаво добре да разгледаме какви вградени функции има и след това да си изберем тази, която най-много ни помага в случая и се чете по-лесно Пример: вместо number.class == Integer е много по-четимо number.is_a? Integer.
+#6. По-хубаво е да избираме име, според това какво съдържа дадена променлива отколкото просто какво представлява Пример: numbers е по-добро име за масив, в който пазим числа, отколкото container, защото от numbers се разбира какво точно има там, а от container - не.
+#7. Хубаво е да избягваме скобите при всеки възможен случай, особено когато не пречи на четимостта на кода.
+#8. Винаги има какво да промениш по кода си, за да го направиш по-четим, дори и това да е просто преименуване на класовете, методите или променливите.
+#
+# От трета задача :
+#
+# 9. String#split приема като втори аргумент число(граница), което указва на колко части да се раздели низа.
+# 10. Може да вземем стойност от метод чрез интерполация ( не само на променливи ).
+# 11. Ако извикаме String#to_f на низ от цяло число, то метода превръща числото в тип Integer, a не Float.
+# 12. Следствие от предния извод: понякога има неща, които не ги пише и в документацията, а човек ги открива чрез тестване, затова е хубаво винаги да експериментираме с вградените фунцкии, които ползваме и да се опитваме да предвидим всеки възможен случай (exception или не).
+# 13. Можем да използваме case конструкция директно при assign-ване на стойност на променлива и дори е доста по-четимо, ако го правим така, а не отделно във фунцкия.
+# 14. Хубаво е да избягваме self, където не ни трябва. ( Препоръчва се и според Ruby-Style-Guide-а)
+# 15. Когато в модул създаваме обекти от клас, дефиниран в даденият модул, не е нужно да го извикваме с името на модула. Тоест вместо RBFS::Directory.new е по-добре да напишем Directory.new.
+# 16. Много по-лесно е да изнесем някаква логика в отделен клас (като Parser например) вместо да се мъчим да дефинираме всичко в различни ирелевантни методи за класа, който го използва.
+# 17. Когато имаме хетерогенен контейнер с два вида обекти вътре е много по-лесно да ги разделим в два контейнера, отколкото да се мъчим да ги филтрираме по някакъв наш измислен начин.
+# 18. Когато метода прави само едно нещо и то е особено очевидно (например превръща низ в обект от тип boolean) не е нужно да изнасяме конвертирането в друг метод #to_bool, когато можем директно да използваме начина на конвертиране (string_boolean == 'true') и няма нужда да търсим къде е дефиниран този метод и какво прави.
+#
+# От четвърта задача :
+#
+# 19. Преди да започнем да решаваме дадена задача е по-добре да прочетем цялото условие няколко пъти ( ОСОБЕНО КОГАТО то е доста дълго ), отколкото да започнем да я пишем и да се оплетем в грешна логика още от самото начало.
+# 20. Много по-лесно и четимо е да разделим многото функционалности на една задача в различни помощни класове, отколкото да се опитваме да ги дефинираме в един или два класа.