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

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

Решение на Ретроспекция от Илия Ячев

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

Към профила на Илия Ячев

Резултати

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

Код

REPOSITORY = 'http://github.com/IliaSky/python-retrospective'
# Двадесет неща, които научих:
#
# 1. Да спазвам по-добре PEP-8
#
# 2. Да предпочитам използването на готови колекции от collections,
# пред това да преоткривам топлата вода
#
# 3. Да внимавам повече по време на refactoring
#
# 4. Да използвам closures вместо да давам атрибути на функциите, които пиша
#
# 5. Да не добавям излишни атрибути и функционалност с идеята,
# че на някого някога може да му потрябват
#
# 6. Да не over-engineer-вам някои прости неща
#
# 7. Да разделям отделните функционалности по-добре
#
# 8. Избирайки подходяща колекция за дадената ситуация впоследствие
# може ни да спести много време и нерви (и бъгове)
#
# 9. Итерирането по дадена колекция и прилагането на функционални подходи
# за обработването на дадената информация може да доведе до доста кратки
# и елегантни решения
#
# 10.Колкото и пъти да го гледам, прилагането на метод join върху стринг и
# подаването на нещо iterable като аргумент ми е много странно. Знам и
# разбирам логиката зад решението - по този начин можем да събираме
# всякакви итеруеми неща, правейки дефинирането доста по-лесно и
# синтаксиса по-разбираем, но все пак...
#
# 11.Когато искаме много проста структура за пакетиране на данни, събирането
# им в tuple е доста лесно решение. След това и итерацията е много удобна.
#
# 12.Tip-of-the-day могат да бъдат доста полезни за идеи за някои домашни
#
# 13.Фатален номер, колкото е и писането на кирилица по средата на рефакторинг
#
# 14.Понякога простото написване на 9 числа е по-бързо от правенето на
# ламбда, която да ги смята
#
# 15.Използвайки zip можем доста лесно да транспонираме матрица(двумерен масив)
#
# 16.Чрез itertools.chain можем да конкатенираме и 3 и повече итеруеми
# едновременно
#
# 17.Понякога желанието за рефакторинг може да ни докара до съвсем друго
# решение, макар и оригиналното също да е било добро
#
# 18.Плъгина AutoPep8 на sublime text 2 не харесва използването на литерален
# синтаксис на set, като например {self}
#
# 19.След всички GUI-та и плъгини, все пак най-лесно се работи с git
# през конзолата, дори под windows
#
# 20.Определено многократно предпочитам задача с регулярни изрази пред
# термини по български език и литература

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

Илия обнови решението на 28.04.2013 03:06 (преди над 11 години)

+REPOSITORY = 'http://github.com/IliaSky/python-retrospective'
+
+# Двадесет неща, които научих:
+#
+# 1. Да спазвам по-добре PEP-8
+#
+# 2. Да предпочитам използването на готови колекции от collections,
+# пред това да преоткривам топлата вода
+#
+# 3. Да внимавам повече по време на refactoring
+#
+# 4. Да използвам closures вместо да давам атрибути на функциите, които пиша
+#
+# 5. Да не добавям излишни атрибути и функционалност с идеята,
+# че на някого някога може да му потрябват
+#
+# 6. Да не over-engineer-вам някои прости неща
+#
+# 7. Да разделям отделните функционалности по-добре
+#
+# 8. Избирайки подходяща колекция за дадената ситуация впоследствие
+# може ни да спести много време и нерви (и бъгове)
+#
+# 9. Итерирането по дадена колекция и прилагането на функционални подходи
+# за обработването на дадената информация може да доведе до доста кратки
+# и елегантни решения
+#
+# 10.Колкото и пъти да го гледам, прилагането на метод join върху стринг и
+# подаването на нещо iterable като аргумент ми е много странно. Знам и
+# разбирам логиката зад решението - по този начин можем да събираме
+# всякакви итеруеми неща, правейки дефинирането доста по-лесно и
+# синтаксиса по-разбираем, но все пак...
+#
+# 11.Когато искаме много проста структура за пакетиране на данни, събирането
+# им в tuple е доста лесно решение. След това и итерацията е много удобна.
+#
+# 12.Tip-of-the-day могат да бъдат доста полезни за идеи за някои домашни
+#
+# 13.Фатален номер, колкото е и писането на кирилица по средата на рефакторинг
+#
+# 14.Понякога простото написване на 9 числа е по-бързо от правенето на
+# ламбда, която да ги смята
+#
+# 15.Използвайки zip можем доста лесно да транспонираме матрица(двумерен масив)
+#
+# 16.Чрез itertools.chain можем да конкатенираме и 3 и повече итеруеми
+# едновременно
+#
+# 17.Понякога желанието за рефакторинг може да ни докара до съвсем друго
+# решение, макар и оригиналното също да е било добро
+#
+# 18.Плъгина AutoPep8 на sublime text 2 не харесва използването на литерален
+# синтаксис на set, като например {self}
+#
+# 19.След всички GUI-та и плъгини, все пак най-лесно се работи с git
+# през конзолата, дори под windows
+#
+# 20.Определено многократно предпочитам задача с регулярни изрази пред
+# термини по български език и литература

В repo-то си имаш __pycache__ директории. Обикновено не искаш *.pyc файловете да са под source control. Спокойно можеш да ги изтриеш.

А за да не ти досаждат с присъстието си в "git status", можеш да го добавиш .gitignore. Примерна употреба можеш да видиш тук

19.След всички GUI-та и плъгини, все пак най-лесно се работи с git през конзолата, дори под windows

+1

10.Колкото и пъти да го гледам, прилагането на метод join върху стринг и подаването на нещо iterable като аргумент ми е много странно.

Ruby и JavaScript правят обратното. И двата подхода имат и предимства, и недостатъци. Не мога да се сетя за елегантно решение, без да се използва типовата система на Хаскел. Това е просто едно от онези неща...

За .gitignore доста се учудих, че нямаше във вашето оригинално repository, понеже подозирам, че не съм единствен, а наистина е досадно да ги има тези файлове. Иначе бях се опитал да го създам, но windows-a не ми позволи понеже не го счита за валидно да има име само от extension-a, но добавяйки го от самия github стана.