здесь же благодаря большой аудитории хочется найти/вспомнить и другие огни, а также обсудить уже перечисленные
хочется собрать в одном месте, какие концепции(стремления) применяются в программировании (или про что надо помнить при программировании)
пока не могу сформулировать что такое именно стремление, попробую по ходу.
но в итоге хочется получить "картинку": меж каких огней находится разработчик для того, чтобы выполнить свою задачу хорошо.
навскидку:
1. unix-way(Пусть каждая программа делает одну вещь, но хорошо)
а) single responsibility principle
2. premature optimization is the root of all evil
3. любую проблему можно решить путём введения дополнительного абстрактного слоя (кроме проблемы слишком большого количества абстрактных слоёв).
4. Don't Repeat Yourself (acronym DRY, also known as Single Point of Truth and Single Point of Maintenance)
а) single point of knowledge
5. Keep it simple, stupid (acronym KISS), "Не плодить сущностей без необходимости." (Бритва Оккама)
а) кода должно быть чем меньше, тем лучше
6. Код должен читаться (легко пониматься)
7. Код должен не мешать повторному использованию
8. Атомарность
9. Связность и связанность
а) Tell, don't ask
10. Код должен вести себя адекватно даже в непредвиденной ситуации
а) безопасность исключений
11. Время разработки
12. Время выполнения
13. Оптимальность выполнения
14. SOLID: An abbreviation for five basic class design principles in Object-Oriented-Design: Single responsibility principle, Open/closed principle, Liskov substitution principle, Interface segregation principle, Dependency inversion principle
15. GRASP (англ. General Responsibility Assignment Software Patterns (общие образцы распределения обязанностей)) — паттерны, используемые в объектно-ориентированном проектировании для решения общих задач по назначению обязанностей классам и объектам.
16 CoC (Convention over configuration) — http://en.wikipedia.org/wiki/Convention_over_configuration
17. get, don't set — формируй новую реальность, а не меняй имеющуюся
18. "утверждение"(кусок кода) должно быть самодостаточным (требовать как можно меньше обращений к внешним справочникам)
19. число поддерживаемых внешних вариантов должно быть как можно больше, число внутренних вариантов поведения как можно меньше
20. полнота (код, по возможности, должен уметь обрабатывать все варианты входной информации)
21. there's more than one way to do it
a) There should be one-- and preferably only one --obvious way to do it.
22. структура кода должна быть формализованной (достаточно понятной для автоматики)
а) должна оставаться возможность автоматического\автоматизированного рефакторинга
Огни которые применяются в разных языках/подходах и т.д.
1) python: The Zen of Python (import this)
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let's do more of those!
2)*nix: Unix-way
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
there's more than one way to do it
все есть файл http://www.freesource.info/wiki/Stat'ja_Klassicheskijj_Unix_Way
зы
время будет — добавлю и структурирую, пока все валом записываю
E>Я не заметил самого важного "огонька": "Программа должна работать!" (т.е. делать именно то, за что заплатили ее заказчики/покупатели).
записал так
25. Название должно точно отражать содержимое (уже по названию должно быть понятно, что содержится внутри)
а) Программа должна работать
b) должно быть как можно меньше side-effect-ов
Здравствуйте, DarkGray, Вы писали:
DG>5. Keep it simple, stupid (acronym KISS)...
Родственным (но тем не менее отдельно выделяемым) принципом является YAGNI. Правда, в конкретной формулировке Википедии принцип может показаться спорным, но в бытовом смысле — очень здравое руководство.
Здравствуйте, DarkGray, Вы писали:
DG>здесь же благодаря большой аудитории хочется найти/вспомнить и другие огни
Я знаю, в меня сейчас кинут тухлым помидором, но кроме шуток: TIMTOWTDI — there's more than one way to do it. Программирование — это искусство, давайте об этом не забывать.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
F>Я знаю, в меня сейчас кинут тухлым помидором, но кроме шуток: TIMTOWTDI — there's more than one way to do it. Программирование — это искусство, давайте об этом не забывать.
Ага. И вершина программирования как искусства — динамическая композиция "Ariane 5 Flight 501" Ракета, арифметическое переполнение.
Дело в том, что в искусстве нет неправильных путей. В программировании они есть. Это важное различие. Давайте о нем не забывать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, frogkiller, Вы писали:
F>Я знаю, в меня сейчас кинут тухлым помидором, но кроме шуток: TIMTOWTDI — there's more than one way to do it. Программирование — это искусство, давайте об этом не забывать.
Здравствуйте, Klapaucius, Вы писали:
K>>>Дело в том, что в искусстве нет неправильных путей.
E>>Ой ли?
K>Конечно нет. Вы же сами ссылку на подтверждение и дали.
Тогда программирование -- несомненно искусство. А ПО разбившегося Ариан 5 одно из ярчайших проявлений направления "шок-арт": одним маленьким арифметическим переполнением пустить на воздух $500M!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Klapaucius, Вы писали:
K>Конечно нет. Вы же сами ссылку на подтверждение и дали.
Не будем спорить про определение искусства А то ведь окажется, что арифметическое переполнение это был перфоманс, а может даже и инсталляция
Но, например, в такой области как архитектура неправильные пути определённо есть. Неправильные дома падают. Это не мешает архитектору одной ногой быть художником. Другой ногой он, конечно, должен быть инженером. А возможно ему ещё третья нога понадобится, из области экономики-логистики.
добавлю в 26 пункт
26. новое делай снаружи, старое интегрируй внутрь
а) чем большим количеством что-то используется, тем более оно ядернее и интегрируемее должно быть (и наоборот)
M>Lisvov principle M>http://en.wikipedia.org/wiki/Liskov_substitution_principle
это есть в 14 пункте
14. SOLID: An abbreviation for five basic class design principles in Object-Oriented-Design: Single responsibility principle, Open/closed principle, Liskov substitution principle, Interface segregation principle, Dependency inversion principle
Здравствуйте, eao197, Вы писали:
E>Тогда программирование -- несомненно искусство. А ПО разбившегося Ариан 5 одно из ярчайших проявлений направления "шок-арт": одним маленьким арифметическим переполнением пустить на воздух $500M!
Иманно это я и написал:
И вершина программирования как искусства — динамическая композиция "Ariane 5 Flight 501" Ракета, арифметическое переполнение
Это лицо программирования как искусства. Нет багов — есть выражение внутреннего мира художника. Тесты и спецификации не нужны — неверных путей все равно нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, SergH, Вы писали:
SH>Но, например, в такой области как архитектура неправильные пути определённо есть. Неправильные дома падают. Это не мешает архитектору одной ногой быть художником. Другой ногой он, конечно, должен быть инженером. А возможно ему ещё третья нога понадобится, из области экономики-логистики.
Ну так я не спорю, что любой инженер может быть одной ногой художником — и архитектор и программист.
Я-то говорю о том, что инженер не может быть художником двумя ногами. Потому, что тогда падающие здания и ракеты нужно будет считать нормой, а так радикально перестроить мировосприятие человечеству будет сложно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
