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

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

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

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

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

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

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

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

antares0mayton,
Не альтератива а равнофигизм. Юниксовые утилиты должны читать данные с потока стандартного ввода. А стоит за ним реальный терминал с живым пользователем или конвеерный вывод другой утилиты не долнжно влять на логику работы.
Я имел в виду не STDIN а формат ключей или опций командной строки.

dbpatch
конкретно возник вопрос по существу - есть логгинг, отлично, при этом разработчики как хотят, так и пишут туда.
кто-то в info, кто-то в debug, кто-то в warn

форматы самые дикие и разнообразные. и почти никто - не пишет контекст - где там возникла та или иная ошибка, классика жанра - плюнуть в лог нечто вида invalid value detected: <value> и.... все, больше ничего.

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

потому и возник вопрос - где есть явно писанные правила, как писать серверный софт.

не надо рассказывать, что там в каждом проекте все свое невероятно уникальное - в 99% случаев это одна и та-же переработка входящего потока в исходящий с сохранением всякого в базу данных
Порядка 15 лет я сопровождаю и разрабатываю ПО для серверного софта. Но до сих пор я озадачен теми-же
вопросами что и вы. Я не отвечу на ваши. Я скорее наоборот - подкину новых. И дам несколько своих взглядов.

По поводу логгинга.

Тема - бесконечная. И неунывающая. И я задам вопрос (1). Кто будет читать лог? Пользователь? Дев-опс?
Первая-вторая-линия поддержки? Сисадмин? Разработчик? Разработчику по большему счету лог не нужен.
В режиме debug он степает по коду и видит все и вся. А в некоторых приложениях (mobile/Android/iOS) пользователь никогда
логи не увидит да и не нужны они ему никогда.

Давайте поговорим про это.

Вопрос (2). Упровни логгирования. . Я думаю тут просто надо подумать о том что мы не только инженеры но еще
и чуть экономисты. Мы работаем в условиях ограниченных ресурсов (диск) и не можем трейсить и дебажить все-все
переменные стека/потока/глобального контекста. На придется искать золотую середину. Не лишним будет курнуть
API логгирования (log4c?) и посмотреть какие есть возможности и рекомендации по использованию.

Давайте поговорим про золотую середину в уровнях детализации.

Вопрос (3). Форматы. . Скорее всего их не существует. И каждый пишет как бох даст. Но я-бы предложил
предварять каждую запись лога TIMESTAMP-ом в позиционном формате. Тоесть чтобы старшие разряды времени
шли в первую очередь. Это (гипотетически) даст нам возможность греп-ать и сорт-ить файл лексическими
конструкциями в диапазоне времени. Форматы уровня. Месседжа и контекста - произвольны. Но я-бы предложил
разбить их по логгерам. При этом полагать что логгер - это некий агрегат для технологии. Например DAO/Contoller/UI e.t.c.
Не для каждого модуля (это мелко) а именно для технологии или некого подраздела приложения.

Давайте обсудим это.

Вопрос (4). Контекст . Тут опять-же вопрос экономии. Как много мы готовы отдать дискового пространства
для сброса контекста ошибки? Локал-переменные? Стектрейс? Memory-dump? Забегая вперед я реально встречал
веб-приложения которые имели узким местом процедуру дампа сведений об ошибке. Она не бесплатна. И при некоторых
условиях можно DDOS-ить приложение искусственными ошибочными ситуациями. Обработка исключения - небесплатна.
Есть и забавные ситуации экономии ресурсов CPU/Memory. Яркий пример - неудачная реализация CSV-парсера на регулярках потребляет в 1000% больше энергии на ошибочных строках которые не проходят валидацию. Фиксится редко. Как показывает мой личный опыт.

Давайте про контекст.

Вопрос (5). invalid value detected . Здесь по пункту 1 надо смотреть в того что будет читателем этого сообщения.
Но если взять метрику соотношение полезного кода к коду который форматирует ошибку то я-бы очень сильно
настаивал на некой разумной цифре. Правило Паретто? 80:20 ? Возможно. В противном случае мы рискуем поймать
сложно уловимую ошибку типа - "исключение в блоке обработки исключений". Я более чем уверен что присутствующие
здесь господа не всегда тестируют негативные кейсы в модульных тестах и не всегда гарантируют отсутствие этого
сценария. Вобщем - будьте кратки. Сложный код обработки ошибки порождает рекурсивную дилемму. А сколько вообще
кейсов ошибки может быть? Вот ради примера берите простейшее С++/DBMS оконное GRUD приложение с 1-й табличкой
и давайте рисовать все ситуации с БД. (БД недоступна, таблица в блокировках, транзакция не прошла по ошибке триггеров,
ошибка констрейнта, и много-много). Все state базы данных перечислить и решить как и что выводить в ответ на каждую
ситуацию. И если мы просто дампим стек - то мы съезжаем с этого вопроса и уходим в начало дискуссии о том для
кого это лог.

Обсудим комплексность самой детализации ошибки.

Вопрос (6). Безопасность. . Согласно Керхгофсу, кража исходного кода не должна причинять неудобств. Тоесть
мы должны исходить из самого пессимистичного сценария. Злоумышленник знает код. Он его видел. Он - бывший сотрудник.
И он обладает бесконечным временем и терпением для осуществления атаки на систему. Какие сведения он может получить
делая синтетические ошибки и получая фидбек на экран или еще каким-то образом. Если вам кажется что это пустяк
и этим не стоит заниматься то обратите внимание на программные продукты Veracode и библиотеки OWASP. Иногда
(я имею в виду ентрепрайз) вы не сможете выкатить новый релиз пока не войдете в зеленый сектор отчота Veracode
или Sonar или прочих статик анализаторов в части отчота по безопасности.

Давайте поговорим про безопасность логов и дампов.

Вопрос (7). Собственно цена доработки системы до человеческого уровня логгирования. Я-бы предложил
анализ метрик сложности кода "до" и "после". Человеческий code-review. И ожидаемый business-value.

И по каждому пункту - соотв принимать решение.

dbpatchв) писать все ошибки в stderr, а не в stdout, не писать в stderr, если демонизированы, писать в syslog

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

Семантический вопрос разделения прикладного и системного я пока оставляю за кадром. Бох вам судья
если вы решили что ваш код системный. Тут важнее осознание значимости момента.