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

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

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

Решение на Пета задача от Светослав Кръстев

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

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

Резултати

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

Код

REPOSITORY = 'https://github.com/skrustev/ruby-retrospective-4'
#1. Case е по-подходящо да се използва ако проверяваме за една #променлива повече от веднъж. По-четливо е например ако ползваме #oneliner-ите на if повече пъти.
#2. Много е важно да се именува променливите правилно за да направим #връзката и да знаеме за какво става дума
#3. Когато имаме някавъв array не е много удачно да го именуваме също #array а по-добре да има връзка със структурата която описва.
#4. За дефиниране на each медота на класа наследил Enumerable във #втора задача може директно да се използва each на списъка с параметер #самия блок което го имаме на готово вместо да проверяваме ръчно дали #ни е даден блокм тъй като вече се проверява от each на списъка.
#5. В ruby може да се напише оператора unless на един ред ако имаме #само една проверка.
#6. Ключовите думи and и or вече не се ползват изобщо и най-добра #практика е да се ползват техните заместители && и ||.
#7. За проверка дали подадено число е от тип Integer, Float, Complex, #Rational може директно да се сравнят класовете на подаденото число и #искания клас с вункцията .is_a?
#8. Вместо да пишем отделна функция за присвояване на променливи от #даден клас е по-лесно и по-кратко директно да изнесем променливата #като attr_accessor.
#9. В case се сравнява промеливате със зададената стойност с помощта #на === , което значи че можем директно да проверяваме от кой клас е #променливата вместо да проверяваме със .is_a?. Това е много по-#четливо и лесно за разбиране.
#10. В задача 3, когато проверяваме дали даден низ е от тип Boolean #можем директно да проверим дали това е така при създаването на нов #обект вместо да го изнесем в отделна функция.
#11. В задача 3, можем да съставим още по-общ обект които парсва и #директории и файлове без да знае предварително какво са. Чрез yeild #можем просто да подадем необходимата функция (за директория или файл) #като стойност на блока и да я извикаме на същия тип елемент то вече #като знаем името и съдържанието.
#12. Можем да използваме директно стойност по подразбиране празен #обек, който само се създава ако не е въведена някаква стойност без да #проверяваме ръчно.
#13. Вместо да проверяваме дали даден хеш има искания от нас ключ #можем да изполваме, че когато искаме хеш стойноста с даден ключ и тои #го няма ни въща nil, което можем директно да го използваме с || #оператор и да ни въща този ключ, който го има първи.
#14. Когато форматираме текст на 4-та задача е добре да имаме иерархия #, в която започваме от най-простата компонента. В случая това е един #ред.
#15. Вместо да променяме редовете със съответния стил и рамка в общите #групи можем да изнесем това в нов клас наследяващ базовата компонента #и да извикаме на него да приведе в подходящ вид компонентата.

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

Светослав обнови решението на 19.01.2015 15:51 (преди почти 10 години)

+REPOSITORY = 'https://github.com/skrustev/ruby-retrospective-4'
+
+#1. Case е по-подходящо да се използва ако проверяваме за една #променлива повече от веднъж. По-четливо е например ако ползваме #oneliner-ите на if повече пъти.
+#2. Много е важно да се именува променливите правилно за да направим #връзката и да знаеме за какво става дума
+#3. Когато имаме някавъв array не е много удачно да го именуваме също #array а по-добре да има връзка със структурата която описва.
+#4. За дефиниране на each медота на класа наследил Enumerable във #втора задача може директно да се използва each на списъка с параметер #самия блок което го имаме на готово вместо да проверяваме ръчно дали #ни е даден блокм тъй като вече се проверява от each на списъка.
+#5. В ruby може да се напише оператора unless на един ред ако имаме #само една проверка.
+#6. Ключовите думи and и or вече не се ползват изобщо и най-добра #практика е да се ползват техните заместители && и ||.
+#7. За проверка дали подадено число е от тип Integer, Float, Complex, #Rational може директно да се сравнят класовете на подаденото число и #искания клас с вункцията .is_a?
+#8. Вместо да пишем отделна функция за присвояване на променливи от #даден клас е по-лесно и по-кратко директно да изнесем променливата #като attr_accessor.
+#9. В case се сравнява промеливате със зададената стойност с помощта #на === , което значи че можем директно да проверяваме от кой клас е #променливата вместо да проверяваме със .is_a?. Това е много по-#четливо и лесно за разбиране.
+#10. В задача 3, когато проверяваме дали даден низ е от тип Boolean #можем директно да проверим дали това е така при създаването на нов #обект вместо да го изнесем в отделна функция.
+#11. В задача 3, можем да съставим още по-общ обект които парсва и #директории и файлове без да знае предварително какво са. Чрез yeild #можем просто да подадем необходимата функция (за директория или файл) #като стойност на блока и да я извикаме на същия тип елемент то вече #като знаем името и съдържанието.
+#12. Можем да използваме директно стойност по подразбиране празен #обек, който само се създава ако не е въведена някаква стойност без да #проверяваме ръчно.

Светослав обнови решението на 19.01.2015 16:01 (преди почти 10 години)

REPOSITORY = 'https://github.com/skrustev/ruby-retrospective-4'
#1. Case е по-подходящо да се използва ако проверяваме за една #променлива повече от веднъж. По-четливо е например ако ползваме #oneliner-ите на if повече пъти.
#2. Много е важно да се именува променливите правилно за да направим #връзката и да знаеме за какво става дума
#3. Когато имаме някавъв array не е много удачно да го именуваме също #array а по-добре да има връзка със структурата която описва.
#4. За дефиниране на each медота на класа наследил Enumerable във #втора задача може директно да се използва each на списъка с параметер #самия блок което го имаме на готово вместо да проверяваме ръчно дали #ни е даден блокм тъй като вече се проверява от each на списъка.
#5. В ruby може да се напише оператора unless на един ред ако имаме #само една проверка.
#6. Ключовите думи and и or вече не се ползват изобщо и най-добра #практика е да се ползват техните заместители && и ||.
#7. За проверка дали подадено число е от тип Integer, Float, Complex, #Rational може директно да се сравнят класовете на подаденото число и #искания клас с вункцията .is_a?
#8. Вместо да пишем отделна функция за присвояване на променливи от #даден клас е по-лесно и по-кратко директно да изнесем променливата #като attr_accessor.
#9. В case се сравнява промеливате със зададената стойност с помощта #на === , което значи че можем директно да проверяваме от кой клас е #променливата вместо да проверяваме със .is_a?. Това е много по-#четливо и лесно за разбиране.
#10. В задача 3, когато проверяваме дали даден низ е от тип Boolean #можем директно да проверим дали това е така при създаването на нов #обект вместо да го изнесем в отделна функция.
#11. В задача 3, можем да съставим още по-общ обект които парсва и #директории и файлове без да знае предварително какво са. Чрез yeild #можем просто да подадем необходимата функция (за директория или файл) #като стойност на блока и да я извикаме на същия тип елемент то вече #като знаем името и съдържанието.
#12. Можем да използваме директно стойност по подразбиране празен #обек, който само се създава ако не е въведена някаква стойност без да #проверяваме ръчно.
+#13. Вместо да проверяваме дали даден хеш има искания от нас ключ #можем да изполваме, че когато искаме хеш стойноста с даден ключ и тои #го няма ни въща nil, което можем директно да го използваме с || #оператор и да ни въща този ключ, който го има първи.
+#14. Когато форматираме текст на 4-та задача е добре да имаме иерархия #, в която започваме от най-простата компонента. В случая това е един #ред.
+#15. Вместо да променяме редовете със съответния стил и рамка в общите #групи можем да изнесем това в нов клас наследяващ базовата компонента #и да извикаме на него да приведе в подходящ вид компонентата.

Решенията ти не минават проверката за skeptic ограниченията и не си написал достатъчно неща. Също така, би могъл да поработиш над правописа, пунктуацията и писменото си изразяване. На места ми беше трудно да разбера какво си имал предвид.