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

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

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

Решение на Девета задача от Мартин Симеонов

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

Към профила на Мартин Симеонов

Резултати

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

Код

REPOSITORY = 'https://github.com/martin-simeonov/ruby-retrospective-2015-1'
## Задача 1
# 1. Коефициенти е добре да се съхраняват в константи.
# 2. Добре е да има запетая след последния елемент в Hash.
# 3. Когато в няколко отделни if-а, тестваме една и съща променлива(стойност и др.), е по-удачно те да бъдат събрани в една if-elsif конструкция.
# 4. result не е добро име за променлива. Като цяло винаги е важно името на променливата да описва максимално добре, какво точно представлява нейната стойност.
# 5. Трябва да се избягват излишни присвоявания на променливи.
## Задача 2
# 6. Методи предикати, които тестват за няколко различни неща е добре да бъдат разделени в отделни методи, от които всеки да тества конкретен случай. Като цяло всеки метод трябва да изпълнява едно конкретно действие.
# 7. Когато се използва метода drop на Array, трябва да се обърне внимание на случая, при който масива остава празен.
## Задача 3
# 8. Научих за оператора ** - повдигане на степен, около него не трябва да има интервали.
# 9. Аргументите в ruby са pass by value.
# 10. Всички методи, които не са предназначени за използване от потребителя трябва да бъдат private.
# 11. Когато се дефинира метод each, той трябва да предава подадения му блок на съответните елементи.
# 12. Генерирането на безкрайни поредици е по-елегантно когато се използва метода lazy.
# 13. Метода meaningless е по-добре да се реализира с Enumerable#partition вместо със select.
## Задача 4
# 14. Когато се използват автоматизирани тестове времето за разработка се скъсява многократно.
# 15. С наследяване от Struct.new е много удобно да се създават класове, които имат малък брой или никакви методи.
# 16. Класове, които се използват като помощни от друг клас и са пряко свързани с него, е удобно да бъдат дефинирани като вложени в него. В конкретната задача class Deal е по-удобно да бъде дефиниран в class Deck.
# 17. Методът Array#product е по-удачен за създаване на тесте от карти, отколкото използването на 2 each-а за обхождане на всички бои и карти.
# 18. Когато искаме един клас да може да се сравнява, логиката за сравнението не винаги е добра идея да бъде в самия него. В случая, моята логика за сравняване на карти беше в class Card, но това създаваше проблеми при различните видове игра. Извод - винаги е добра идея първо да се помисли, а после да се пише код.
# 19. Комбинацията между методите map и join е много удобна за създаване на низове от елементите на колекция.
# 20. Научих за оператора &, който прави сечение между 2 масива.
# 21. Метода each_cons е много удобен. Като цяло разучих доста по-добре методите на Enumerable.

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

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 f6121fe Find consecutive cards logic fixed
From /tmp/ruby-retrospective-2015-1/checker
 * branch            master     -> FETCH_HEAD
 * [new branch]      master     -> upstream/master

Changes URL:
https://github.com/martin-simeonov/ruby-retrospective-2015-1/compare/767dd8dfe46...f6121fe7c74

‘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.00493 seconds
8 examples, 0 failures
OK
....................

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

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

Finished in 0.0268 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.00157 seconds
1 example, 0 failures

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

Мартин обнови решението на 26.01.2016 19:05 (преди около 9 години)

+REPOSITORY = 'https://github.com/martin-simeonov/ruby-retrospective-2015-1'
+
+## Задача 1
+# 1. Коефициенти е добре да се съхраняват в константи.
+# 2. Добре е да има запетая след последния елемент в Hash.
+# 3. Когато в няколко отделни if-а, тестваме една и съща променлива(стойност и др.), е по-удачно те да бъдат събрани в една if-elsif конструкция.
+# 4. result не е добро име за променлива. Като цяло винаги е важно името на променливата да описва максимално добре, какво точно представлява нейната стойност.
+# 5. Трябва да се избягват излишни присвоявания на променливи.
+## Задача 2
+# 6. Методи предикати, които тестват за няколко различни неща е добре да бъдат разделени в отделни методи, от които всеки да тества конкретен случай. Като цяло всеки метод трябва да изпълнява едно конкретно действие.
+# 7. Когато се използва метода drop на Array, трябва да се обърне внимание на случая, при който масива остава празен.
+## Задача 3
+# 8. Научих за оператора ** - повдигане на степен, около него не трябва да има интервали.
+# 9. Аргументите в ruby са pass by value.
+# 10. Всички методи, които не са предназначени за използване от потребителя трябва да бъдат private.
+# 11. Когато се дефинира метод each, той трябва да предава подадения му блок на съответните елементи.
+# 12. Генерирането на безкрайни поредици е по-елегантно когато се използва метода lazy.
+# 13. Метода meaningless е по-добре да се реализира с Enumerable#partition вместо със select.
+## Задача 4
+# 14. Когато се използват автоматизирани тестове времето за разработка се скъсява многократно.
+# 15. С наследяване от Struct.new е много удобно да се създават класове, които имат малък брой или никакви методи.
+# 16. Класове, които се използват като помощни от друг клас и са пряко свързани с него, е удобно да бъдат дефинирани като вложени в него. В конкретната задача class Deal е по-удобно да бъде дефиниран в class Deck.
+# 17. Методът Array#product е по-удачен за създаване на тесте от карти, отколкото използването на 2 each-а за обхождане на всички бои и карти.
+# 18. Когато искаме един клас да може да се сравнява, логиката за сравнението не винаги е добра идея да бъде в самия него. В случая, моята логика за сравняване на карти беше в class Card, но това създаваше проблеми при различните видове игра. Извод - винаги е добра идея първо да се помисли, а после да се пише код.
+# 19. Комбинацията между методите map и join е много удобна за създаване на низове от елементите на колекция.
+# 20. Научих за оператора &, който прави сечение между 2 масива.
+# 21. Метода each_cons е много удобен. Като цяло разучих доста по-добре методите на Enumerable.