Хешове и keyword аргументи на блокове

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

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

Решение на Девета задача от Никола Терзиев

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

Към профила на Никола Терзиев

Резултати

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

Код

REPOSITORY = 'http://github.com/VazovTheGreat/ruby-retrospective-2015-1'
# What did I learn
#
# 1. Ключовете в хешовете могат да бъдат литерали без кавички, в този случай те
# биват интерпретирани като символи.
# 2. Хубаво е да проверяваш какво става в първата седмица от началото на новата
# сесия(тогава е било дадено първото домашно, което изпуснах).
# 3. Разбрах каква е разликата между поведението на clone и dup.
# 4. #drop и #take са много експресивни функции, чрез които по-ясно може да
# предадеш намеренията си (за разлика от shift).
# 5. Multiple Assignment е много подходящ за комплектоване на подобни променливи.
# 6. Разбиването на проверки (както на 2 зад. obstacle_ahead?) на под-проверки
# повишава изключително много четимостта на кода - наместо сгъчкани 5,6 предиката
# може да групираме проверки от типа на wall_ahead? или body_ahead?.
# 7. По добре е да използваме стринг интерполация, наместо конкатенация
# 8. В руби, ключовата дума return не е задължителна, даже не е препоръчителна
# (забелязват патърни, които ненужно използват return)
# 9. Синтаксисът със символ наместо блок, може значително да подобри четимостта
# 10. Разликата между .. и ... (the horror).. +- 1 число, who knows? :)
# 11. Има разлика между `Integer * String` и `String * Integer`
# 12. Разликата в синтаксиса на глобални променливи, константи, обикновенни променливи,
# атрибути на клас, променливи на клас и т.н.
# 13. Сложните решения довеждат до огромни главоболия при рефакториране
# 14. Предаването на функции като параметри(които ще се извикат чрез send или call),
# в 99% от случаите е code smell, който може да се направи по по-добър начин
# 15. Използването на ?-ия символ е по-добър начин за отделяне на фунции, връщащи
# boolean, отколкото използването на представка/наставка _is|is_
# 16. Ако искам да маркирам, че няма да използвам дадена промемнлива, използването
# на символа _ е добър подход.
# 17. Използването на Struct значително симплифицира кода и премахва boilerplate-a(win, win)
# 18. Многоредови блокове стават по-четими, използвайки do end синтаксиса
# 19. Създавайки метод, неприемащ аргументи, можем да изпуснем кръглите скоби
# 20. Създаването на правилна йерархия от класове прави кода много по-лесен за надграждане
# 21. Използването на Mixins е чудесен начин да композираш кода

Лог от изпълнението

From https://github.com/fmi/ruby-retrospective-2015-1
 * branch            master     -> FETCH_HEAD
HEAD is now at 767dd8d Update the task name in the readme for clarity
Cloning into 'submission'...
HEAD is now at cea14f8 Improve solution 03
From /tmp/ruby-retrospective-2015-1/checker
 * branch            master     -> FETCH_HEAD
 * [new branch]      master     -> upstream/master

Changes URL:
http://github.com/VazovTheGreat/ruby-retrospective-2015-1/compare/767dd8dfe46...cea14f890be

‘solutions/04.rb’ -> ‘/tmp/ruby-retrospective-2015-1/checker/solutions/04.rb’
‘solutions/02.rb’ -> ‘/tmp/ruby-retrospective-2015-1/checker/solutions/02.rb’
‘solutions/03.rb’ -> ‘/tmp/ruby-retrospective-2015-1/checker/solutions/03.rb’
‘solutions/01.rb’ -> ‘/tmp/ruby-retrospective-2015-1/checker/solutions/01.rb’
OK
........

Finished in 0.02537 seconds
8 examples, 0 failures
OK
....................

Finished in 0.01103 seconds
20 examples, 0 failures
OK
....................

Finished in 0.17089 seconds
20 examples, 0 failures
OK
.........................................................

Finished in 0.02747 seconds
57 examples, 0 failures
From https://github.com/fmi/ruby-homework
 * branch            master     -> FETCH_HEAD
HEAD is now at 9dd040c Modify a test in task 8 to not include empty cells
.

Finished in 0.00159 seconds
1 example, 0 failures

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

Никола обнови решението на 24.01.2016 19:14 (преди над 9 години)

+REPOSITORY = 'https://github.com/VazovTheGreat/ruby-retrospective-2015-1'
+
+# What did I learn
+#
+# 1. Ключовете в хешовете могат да бъдат литерали без кавички, в този случай те
+# биват интерпретирани като символи.
+# 2. Хубаво е да проверяваш какво става в първата седмица от началото на новата
+# сесия(тогава е било дадено първото домашно, което изпуснах).
+# 3. Разбрах каква е разликата между поведението на clone и dup.
+# 4. #drop и #take са много експресивни функции, чрез които по-ясно може да
+# предадеш намеренията си (за разлика от shift).
+# 5. Multiple Assignment е много подходящ за комплектоване на подобни променливи.
+# 6. Разбиването на проверки (както на 2 зад. obstacle_ahead?) на под-проверки
+# повишава изключително много четимостта на кода - наместо сгъчкани 5,6 предиката
+# може да групираме проверки от типа на wall_ahead? или body_ahead?.
+# 7. По добре е да използваме стринг интерполация, наместо конкатенация
+# 8. В руби, ключовата дума return не е задължителна, даже не е препоръчителна
+# (забелязват патърни, които ненужно използват return)
+# 9. Синтаксисът със символ наместо блок, може значително да подобри четимостта
+# 10. Разликата между .. и ... (the horror).. +- 1 число, who knows? :)
+# 11. Има разлика между `Integer * String` и `String * Integer`
+# 12. Разликата в синтаксиса на глобални променливи, константи, обикновенни променливи,
+# атрибути на клас, променливи на клас и т.н.
+# 13. Сложните решения довеждат до огромни главоболия при рефакториране
+# 14. Предаването на функции като параметри(които ще се извикат чрез send или call),
+# в 99% от случаите е code smell, който може да се направи по по-добър начин
+# 15. Използването на ?-ия символ е по-добър начин за отделяне на фунции, връщащи
+# boolean, отколкото използването на представка/наставка _is|is_
+# 16. Ако искам да маркирам, че няма да използвам дадена промемнлива, използването
+# на символа _ е добър подход.
+# 17. Използването на Struct значително симплифицира кода и премахва boilerplate-a(win, win)
+# 18. Многоредови блокове стават по-четими, използвайки do end синтаксиса
+# 19. Създавайки метод, неприемащ аргументи, можем да изпуснем кръглите скоби
+# 20. Създаването на правилна йерархия от класове прави кода много по-лесен за надграждане
+# 21. Използването на Mixins е чудесен начин да композираш кода

Никола обнови решението на 24.01.2016 19:21 (преди над 9 години)

-REPOSITORY = 'https://github.com/VazovTheGreat/ruby-retrospective-2015-1'
+REPOSITORY = 'http://github.com/VazovTheGreat/ruby-retrospective-2015-1'
# What did I learn
#
# 1. Ключовете в хешовете могат да бъдат литерали без кавички, в този случай те
# биват интерпретирани като символи.
# 2. Хубаво е да проверяваш какво става в първата седмица от началото на новата
# сесия(тогава е било дадено първото домашно, което изпуснах).
# 3. Разбрах каква е разликата между поведението на clone и dup.
# 4. #drop и #take са много експресивни функции, чрез които по-ясно може да
# предадеш намеренията си (за разлика от shift).
# 5. Multiple Assignment е много подходящ за комплектоване на подобни променливи.
# 6. Разбиването на проверки (както на 2 зад. obstacle_ahead?) на под-проверки
# повишава изключително много четимостта на кода - наместо сгъчкани 5,6 предиката
# може да групираме проверки от типа на wall_ahead? или body_ahead?.
# 7. По добре е да използваме стринг интерполация, наместо конкатенация
# 8. В руби, ключовата дума return не е задължителна, даже не е препоръчителна
# (забелязват патърни, които ненужно използват return)
# 9. Синтаксисът със символ наместо блок, може значително да подобри четимостта
# 10. Разликата между .. и ... (the horror).. +- 1 число, who knows? :)
# 11. Има разлика между `Integer * String` и `String * Integer`
# 12. Разликата в синтаксиса на глобални променливи, константи, обикновенни променливи,
# атрибути на клас, променливи на клас и т.н.
# 13. Сложните решения довеждат до огромни главоболия при рефакториране
# 14. Предаването на функции като параметри(които ще се извикат чрез send или call),
# в 99% от случаите е code smell, който може да се направи по по-добър начин
# 15. Използването на ?-ия символ е по-добър начин за отделяне на фунции, връщащи
# boolean, отколкото използването на представка/наставка _is|is_
# 16. Ако искам да маркирам, че няма да използвам дадена промемнлива, използването
# на символа _ е добър подход.
# 17. Използването на Struct значително симплифицира кода и премахва boilerplate-a(win, win)
# 18. Многоредови блокове стават по-четими, използвайки do end синтаксиса
# 19. Създавайки метод, неприемащ аргументи, можем да изпуснем кръглите скоби
# 20. Създаването на правилна йерархия от класове прави кода много по-лесен за надграждане
# 21. Използването на Mixins е чудесен начин да композираш кода

Отнемам ти една точка, понеже в окончателните ти решения имаш проблеми с идентацията и неконвенционални парчета код като това:

if snake.include?(next_position) or wall_ahead?(next_position, dimensions)
  true
else
  false
end

Което може да се запише така:

snake.include?(next_position) or wall_ahead?(next_position, dimensions)

Между другото:

"19. Създавайки метод, неприемащ аргументи, можем да изпуснем кръглите скоби"

Могат да се изпуснат скобите дори и да има аргументи, както при извикването, така и при дефиницията, но когато има аргументи, поне при дефиниция по конвенция винаги се слагат скоби.