правила написания ПО, style guide, но не для форматирования кода, а для функциональности

как известно, существуют Style guide для кода, сколько там пробелов отступать и как скобки ставить.
с этим понятно и вопросов нет

но какие есть на просторах интернетов примеры гайдов к требованию написанию уже самого ПО?

к примеру, если мы пишем некие консольные приложения, демоны и утилиты:

а) приложения, бросающие ошибки - должны в обязательном порядке говорить о контексте, на котором они упали -
если обрабатывался файл, то нужно указать имя файла, номер строки и колонки,
если обрабатывалась таблица в базе данных - то показать имя таблицы, значение PK или rowid
б) обработка параметров командной строки, когда и как использовать два -, когда --, --usage, --help
в) писать все ошибки в stderr, а не в stdout, не писать в stderr, если демонизированы, писать в syslog
г) не требовать явного пользовательского ввода с клавиатуры

ну и т.п.

т.е. что-то вроде https://www.gnu.org/prep/standards/standards.html

но поглобальнее?

dbpatch,

для начала общие принципы, SOLID, юнит-тесты. потом вырабатываете свои правила под конкретные кейсы. нет смысла тащить всё и колупать мозг пациентам. зачем?

Правила... это пожалуй слишком строгая форулировка. По каждому пункту - it depends.

dbpatch,

для функциональности есть шаблоны проектирования

kealon(Ruslan)
dbpatch, для функциональности есть шаблоны проектирования

блин, ну что за ерунда? я же показал пример (см. выше ссылку) руководства,

нужны - такие-же, только более развернутые.

а ты что привел? давай еще ссылку на K&R, на .NET Reference или и вовсе - на букварь и на арифметику для 3-го класса школы, нет ну почему нет?

интересуют имена собственные. вот тут, к примеру, чувак описывает - как физически огранизовывать код - группы пакетов, пакеты, компоненты
https://github.com/bloomberg/bde/wiki/physical-code-organization
https://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620

вот тут - описывается типовая веб страница, правила организации оной
http://webstyleguide.com/wsg3/6-page-structure/3-site-design.html

аналогичные руководства есть по всем аспектам - от логгинга до правил написания распределенных приложений.

без привязки к каким-то библиотекам и коду - а именно требования функциональные - вот у вас такое должно быть

не?

dbpatch
не?

Не. Есть просто некоторые традиции и понимание, что люди плохо обучаемы и потому следование этим традициям ускоряет процесс их привыкания к твоей софтине.

dbpatch
без привязки к каким-то библиотекам и коду - а именно требования функциональные - вот у вас такое должно быть

ну а там разве не так? кода там нет, просто схемы организации

Я бы посоветовал не париться со всякой фигнёй, везде по разному, пишите по ходу того что вас раздражать будет.
Как правило от правил, на высоких уровнях, больше вреда чем пользы.

dbpatch
аналогичные руководства есть по всем аспектам - от логгинга до правил написания распределенных приложений. без привязки к каким-то библиотекам и коду - а именно требования функциональные - вот у вас такое должно быть не?

У нас постоянно такой гайд формируется, для каждого проекта свой. Очень сильно зависит от специфики, от уровня команды, на каждом уровне свой гайд: у дизайнеров свой, у верстальщиков свой, у прикладных разработчиков свой, у аналитиков свой, у фреймворк разработчиков свой. И ещё они разные от проекта к проекту. Ведётся вики, Howto, внутренний faq, теги, слак, всякое.

Унылый 500 страничный документ -- кому он нафиг упал? Ищете как ещё можно усложнить жизнь коллегам?

dbpatch
без привязки к каким-то библиотекам и коду - а именно требования функциональные - вот у вас такое должно быть

Такие вопросы. Как часто должен средний разработчик обращаться к этим общим функциональным требованиям? Должен ли он помнить всё? Или как? Каким образом это должно контролироваться? Какие есть средства? Раз в неделю инспекция? Каждый день? Кто самый образованный следит за всем?

И где тут автоматизация?

dbpatch
а) приложения, бросающие ошибки - должны в обязательном порядке говорить о контексте, на котором они упали - если обрабатывался файл, то нужно указать имя файла, номер строки и колонки, если обрабатывалась таблица в базе данных - то показать имя таблицы, значение PK или rowid

Это очень красиво звучит на бумаге. Но на практике - потребует от разработчика потратить некоторые
усилия на детализацию ошибки.

По поводу таблиц и колонок и значений. Есть огромное количество классических "толстых" клиентов
которые никогда ничего подобного не выводят. Фактически - они - контрпример.

б) обработка параметров командной строки, когда и как использовать два -, когда --, --usage, --help

Если взять Unix-утилиты командной строки то там можно заметить игнорирование этих правил.

г) не требовать явного пользовательского ввода с клавиатуры

Здесь - непонятно. Если "не требовать" - это означает предлагать альтернативу. А какая альтернатива?
Вы - знаете?