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

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

Решение на Пета задача от Ангел Венчев

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

Към профила на Ангел Венчев

Резултати

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

Код

REPOSITORY = 'https://github.com/AngelVenchev/ruby-retrospective-3'
# 1. По-важно е кода да е по-четим, отколкото да е по "оптимален", като
# например обхождайки числата до корен от числото, за което проверяваме
# дали е просто, вместо до самото число минус 1.
# 2. Важно да е изпълняваме зададеното усовие на задачите, а не това което
# ние си мислим, че трябва да изпълняваме.
# 3. Важно е да кръщаваме променливите си със смислени име на с цел
# по-добра четимост и разбираемост на кода.
# 4. В Ruby трябва да направим възможно най-краткият и ясен код, който решава проблема.
# 5. Трябва да познаваме инструментите, с които разполагаме за да можем
# да се възползваме от силните страни на средата или технологията, която ползваме.
# 6. Разделяйки кода на малки части изпълняващи прости неща го правим по-четим
# и преизползваем.
# 7. Спазвайки конвенцийте приети от обществото на Ruby в open-source света
# има по-голям шанс да получим съдействие, защото кодът ни е лесно разбираем,
# четим и по-качествен.
# 8. Трябва да разделяме отговорностите на отделните класове, както и
# на отделните методи.
# 9. Дори и в езици като Ruby има малко място за пестене на ресурс, като
# "замразяването" на стрингове
# 10. Можем да направим кода по-четим и чрез форматирането му. С подравнени
# оператори за присвояване и списъци и хешове на няколко реда
# 11. Важно е да не замърсяваме общото пространство с наши помощни методи,
# можем да ги разпределяме в модул и класове или ако не искаме да са в публичния ни интерфейс, можем да ги направим private
# 12. Много метапрограмиране води до труден за дебъгване код

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

Ангел обнови решението на 22.01.2014 03:12 (преди почти 11 години)

+REPOSITORY = 'https://github.com/AngelVenchev/ruby-retrospective-3'
+
+# 1. По-важно е кода да е по-четим, отколкото да е по "оптимален", като
+# например обхождайки числата до корен от числото, за което проверяваме
+# дали е просто, вместо до самото число минус 1.
+# 2. Важно да е изпълняваме зададеното усовие на задачите, а не това което
+# ние си мислим, че трябва да изпълняваме.
+# 3. Важно е да кръщаваме променливите си със смислени име на с цел
+# по-добра четимост и разбираемост на кода.
+# 4. В Ruby трябва да направим възможно най-краткият и ясен код, който решава проблема.
+# 5. Трябва да познаваме инструментите, с които разполагаме за да можем
+# да се възползваме от силните страни на средата или технологията, която ползваме.
+# 6. Разделяйки кода на малки части изпълняващи прости неща го правим по-четим
+# и преизползваем.
+# 7. Спазвайки конвенцийте приети от обществото на Ruby в open-source света
+# има по-голям шанс да получим съдействие, защото кодът ни е лесно разбираем,
+# четим и по-качествен.
+# 8. Трябва да разделяме отговорностите на отделните класове, както и
+# на отделните методи.
+# 9. Дори и в езици като Ruby има малко място за пестене на ресурс, като
+# "замразяването" на стрингове
+# 10. Можем да направим кода по-четим и чрез форматирането му. С подравнени
+# оператори за присвояване и списъци и хешове на няколко реда
+# 11. Важно е да не замърсяваме общото пространство с наши помощни методи,
+# можем да ги разпределяме в модул и класове или ако не искаме да са в публичния ни интерфейс, можем да ги направим private
+# 12. Много метапрограмиране води до труден за дебъгване код

Макар че имам леки забележки по някои от изводите ти, като цяло са добри. Надявам се, че си доволен от наученото от теб :)

За съжаление, тестовете ти не минават, както и си в нарушение на някои skeptic ограничения и не мога да ти дам точки за тази задача. Ще трябва да се задоволиш само с наученото... :)

Имам само една бележка по употребата на Struct - виждам смисъл в това само ако има нужда да се замести клас, т.е. се спестява дефиницията на отделен клас. Употреба като тази: class Dec < Struct.new :destination, :value не намирам за добра. Предпочитам да дефинирам атрибутите с attr_accessor :destination, :value - не само, че е по-кратко, но и е по-праволинейно, просто и ясно. Struct носи допълнителни неща, които в не само, че повечето случаи не са необходими (например, енумерация на атрибутите), ами са и направо излишни.