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

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

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

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

Към профила на Моника Димитрова

Резултати

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

Код

REPOSITORY = 'https://github.com/mdimitrova/ruby-retrospective-3'
# Двадесет и едно неща, които научих.
# 01. upto е по-добър вариант от range за изброяване на числа
# 02. pred връща числото - 1
# 03. Има по-смислени имена за итератори от i (но понякога skeptic ни притиска)
# 04. each_with_object прилага дадения блок върху всеки елемент на някакъв обект и връща обекта
# 05. array[1..-1] е хитър(?) начин да вземем елементите на масив без първия (т.е. нулевия)
# 06. attr_accessor спестява писане и място
# 07. Връщайки някакъв новосъздаден обект не е нужно да го присвояваме на променлива и да връщаме нея
# 08. uniq е удобен начин да махнем повтарящите се елементи при обединяване
# 09. alias спестява повторения при дефинирането на сходни методи
# 10. Помощните методи е добре да са private
# 11. Проверките за стойностите на from и to за отсечка (и аналогично за правоъгълник) е добре да стават в самата инициализация, за да не се повтарят в другите методи
# 12. Array.new(height) { Array.new(width, 0) } е по-ясен начин за създаване на двумерен масив от нули
# 13. По-дългите алгоритми е добре да се разделят на части в отделни методи
# 14. При еднакви фигури трябва да се връща един и същ хеш
# 15. Константите не само правят кода по-кратък, но и по-четим и по-лесен за refactoring
# 16. Keyword аргументите предотвратяват WTF моментите при четене на кода
# 17. "Новия" синтаксис за хешове
# 18. Изнасяне на методи в модули и включването на модулите в класове с цел яснота (и вместване в критериите на skeptic)
# 19. Добре е константи от типа на JUMPS да се freeze-ват
# 20. Не трябва да се страхувам от ламбда оператори :)
# 21. Хубаво е да се commit-ва по-често...

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

Моника обнови решението на 22.01.2014 17:09 (преди над 10 години)

+REPOSITORY = 'https://github.com/mdimitrova/ruby-retrospective-3'
+
+# Двадесет и едно неща, които научих.
+# 01. upto е по-добър вариант от range за изброяване на числа
+# 02. pred връща числото - 1
+# 03. Има по-смислени имена за итератори от i (но понякога skeptic ни притиска)
+# 04. each_with_object прилага дадения блок върху всеки елемент на някакъв обект и връща обекта
+# 05. array[1..-1] е хитър(?) начин да вземем елементите на масив без първия (т.е. нулевия)
+# 06. attr_accessor спестява писане и място
+# 07. Връщайки някакъв новосъздаден обект не е нужно да го присвояваме на променлива и да връщаме нея
+# 08. uniq е удобен начин да махнем повтарящите се елементи при обединяване
+# 09. alias спестява повторения при дефинирането на сходни методи
+# 10. Помощните методи е добре да са private
+# 11. Проверките за стойностите на from и to за отсечка (и аналогично за правоъгълник) е добре да стават в самата инициализация, за да не се повтарят в другите методи
+# 12. Array.new(height) { Array.new(width, 0) } е по-ясен начин за създаване на двумерен масив от нули
+# 13. По-дългите алгоритми е добре да се разделят на части в отделни методи
+# 14. При еднакви фигури трябва да се връща един и същ хеш
+# 15. Константите не само правят кода по-кратък, но и по-четим и по-лесен за refactoring
+# 16. Keyword аргументите предотвратяват WTF моментите при четене на кода
+# 17. "Новия" синтаксис за хешове
+# 18. Изнасяне на методи в модули и включването на модулите в класове с цел яснота (и вместване в критериите на skeptic)
+# 19. Добре е константи от типа на JUMPS да се freeze-ват
+# 20. Не трябва да се страхувам от ламбда оператори :)
+# 21. Хубаво е да се commit-ва по-често...

Като цяло, решенията ти са прилични. По втора задача, не ми харесва много parse в комбинация с Task.new. Бих го променил следното:

TodoList.new parsed.map { |task| Task.new(task) }

С това:

TodoList.new parsed.map { |task| Task.new(*task) }

И бих променил конструктора на Task така:

class Task
  def initialize(status, description, priority, tags = nil)
    @status      = status.downcase.to_sym
    @description = description
    @priority    = priority.downcase.to_sym
    @tags        = tags.nil? ? [] : tags.split(', ')
  end
end

По трета задача, предпочитам представянето на пано с хеш, вместо с масив от масиви. Допълнително, не ми харесва, когато видя в renderer-ите неща като gsub, chomp и прочее.

По нещата, които си написала:

Точка 01. upto е по-добър вариант от range за изброяване на числа

Когато целта е обхождане от А до Б - да. Но не винаги. Range-овете имат своето приложение :)

Точка 02. pred връща числото - 1

Има и succ :)

Точка 05. array[1..-1] е хитър(?) начин да вземем елементите на масив без първия (т.е. нулевия)

Да, но Array#drop(1) е по-четим такъв.

Точка 13. По-дългите алгоритми е добре да се разделят на части в отделни методи

Зависи. Не винаги. Това не е абсолютна истина, за съжаление. Със сигурност е добре да са ясно разписани и с добре именувани променливи и добре отделени смислени блокове.

Точка 14. При еднакви фигури трябва да се връща един и същ хеш

В контекста на трета задача - да. Принципно - зависи :) Принципната идея е, че ако два обекта са равни, в смисъл, че могат да се считат за еднакви, когато се подават като ключове на хешове, тогава методът им hash трябва да връщат една и съща стойност, както и при ставнение с eql? трябва да се връща true.

Точка 19. Добре е константи от типа на JUMPS да се freeze-ват

Добре е константи принципно да се freeze-ват (освен ако не са immutable, като символи и числа).

Останалите неща ми харесват. Препоръчвам ти, когато имаш време, да си избереш три решения на тази задача, на които съм дал най-много точки и да ги разгледаш внимателно. Вярвам, че ще има още интересни и важни неща, които ще научиш.