Дмитрий Каратаев

Keyboard.GetKeyStates(Key.Return)

Самое главное в хорошей библиотеке - это ваше желание ее поддерживать. Прежде всего оформите проект как следует: GitHub + хорошее описание (примеры API, демки) + немного дизайнерской работы, чтобы привлечь внимание (хорошее лого по крайней мере). Напишите тесты.

Далее о проекте можно будет написать, хоть на тот же хабр. Но учтите, на хабре сразу же посмотрят вашу библиотеку, кто-то ее проверит и будет очень плохо, если она не работает или содержит баги.

Обязательно загуглите конкурентов, вы должны обосновать почему ваша библиотека лучше и знать свои слабые и сильные стороны чтобы написать о них. Люди очень косервативны, и если они уже используют что-то еще, то будет очень трудно переубедить их переключиться на ваше решение.

1. Делаете хороший README, разумеется на английском, где указываете, как ей пользоваться, и что ей требуется.
2. Делаете несколько примеров (именно рабочий код в подпапке examples) для основных кейсов применения библиотеки.
3. Льете на опенсурсный хостинг, если еще не сделали.
4. Настраиваете CI (например на AppVeyour), это не обязательно, но желательно.
5. Заливаете готовые пакеты на NuGet. Разумеется, вы должны научиться упаковывать свою библиотеку в нормальный пакет. В nuspec ставите годные правильные теги.
6. Покрываете тестами, хотя бы частично.

После этого к вашей библиотеке начнут относиться более-менее серьезно.

7. Можете попробовать на CodeProject рассказать, там часто рассказывают именно про библиотеки.

Мне показалось что человек спрашивал как описать ТЗ а не как его оформить по ГОСТу. Если я прав, то советую взять листок бумаги написать главную цель ТЗ, далее разбиваете эту цель на подзадачи и так в виде дерева до самого низкого уровня который сможете описать. Данное дерево будет основой ТЗ, условно можно представить что каждая задача пункт ТЗ, подзадача подпункт, но тут от уровня погружения зависит. Чем подробнее будет такое дерево тем качественнее получится итоговый продукт, остальное что касается оформления и структуры носит больше формальный характер.

Второй вариант с точки зрения ООП однозначно правильнее. Ответ на вопрос: да, правильно.

В первом случае главный подводный камень будет в том, что тебе нужно будет в каждую сущность внедрять сервис.
Вот в этой книге всё достаточно доступно описано.

Очень хороший вопрос. На нейминг нужно осознанно тратить время, пробовать все возможные варианты. Хорошо названные классы и переменные - один из признаков чистого кода. Я именно так и поступаю - гуглотранслейчу русское и пробую на "вкус" :) лучше кстати пользоваться www.multitran.ru - там есть отраслевой перевод
Рекомендую к прочтению www.ozon.ru/context/detail/id/5011068 (в сети можно найти сканы) и вот это видео к просмотру https://moscowdjango.ru/meetup/26/how-to-name-vari...