My coding standards, т. е. checklist при публикации --------------------------------------------------- Придумать имя (в том числе капитализацию), искать конфликты имён с существующими проектами [Сделать для libsh] Придумать описание проекта для гитхаба. Чтобы при просмотре проектов на гитхабе можно было сразу понять, что про что Искать альтернативы проекту GNU formatting style for C and C++ Желательно не учитывать опции, идущие после операндов. Нужно всегда (даже когда нет опций) поддерживать опцию --. Желательно поддерживать операнд - Поддерживать --help и --version в c/c++-программах в стиле gnu coding standards. sh-скрипты должны при запуске "script.sh --help" показывать usage в любой fd и могут завершаться с любым кодом возврата [Сделать для libsh] Программы, принимающие в качестве аргумента команду, должны содержать в хелпе EXEC-CMD или SH-CMD libabc рекомендует -V как синоним для --version? Писать NOTREACHED В C и C++ hate mode нужно использовать NULL, чтобы его было сразу видно, в C++ - nullptr. Нулевой символ - это непременно '\0' В exec* пишем (char *) NULL. NULL, т. к. везде пишем NULL. (char *), т. к. в C++ NULL - это 0 Можно использовать mixed declarations and code и комментарии "//", потому что это удобно. Нужно использовать только комментарии вида "//" для единообразия #ifndef для хедеров и __cplusplus для библиотек Бинарники для небиблиотек для Windows [Сделать для libsh] Выбрать лицензию, проставить уведомления о лицензии, установить правила проекта, в том числе приёма патчей Нельзя использовать C _Bool в библиотечных хедерах, т. к. C _Bool и C++ bool могут быть несовместимы, см. https://gcc.gnu.org/ml/gcc/2002-04/msg01472.html [Сделать для libsh] Reentrant и thread-safe - это разные вещи. Их лучше не применять к программе или библиотеке целиком. Рекурсивные функции, конечно, должны быть reentrant в том смысле, что они должны корректно работать, когда вызывают себя. Signal handlers (и вызываемые из них функции) должны быть reentrant, если один signal handler может прервать себя или другой handler (в том числе для другого сигнала). Функции, используемые в signal handlers и в обычном коде должны быть reentrant. В остальных случаях reentrancy не нужна, т. к. мало кому нужно, чтобы из signal handlers можно было запускать что угодно. Если это библиотека, то в документации должно быть написано, что reentrancy может отсутствовать. Библиотека должна быть по возможности thread-aware (в смысле libabc от Poettering'а), т. е. одна функция, применённая к разным данным (например, к разным данным, переданным в качестве аргументов) должна работать в нескольких потоках одновременно. Но работа одной функции с одними данными в разных потоках (thread safety в смысле libabc) необязательна. В документации к библиотеке должно быть написано, является ли она thread-aware и thread-safe В случае публикации на Github'е настроить репозиторий, например, отключить вики Требовать от юзера либы инициализировать нулями все структуры, т. к. могут добавиться новые поля. Разрешить инициализировать инициализатором (я не буду менять порядок полей) [Сделать для libsh] Скриншоты, примеры, kickstart-инструкция, объяснение, зачем нужна программа и что она делает [Сделать для libsh] Для либы написать утилиты-примеры для очень многих функций. Например, написать пример для sh_curl в libsh, чтобы было понятно, как перед этим инициализировать curl [Сделать для libsh] Указать номер версии По возможности использовать const и enum вместо #define Сейчас я пишу все C++ программы в C++ hate mode, т. е. придерживаюсь стандартов C при написании C++, например, "int &foo", "[](void){}", не выношу API либы в namespace [Сделать для libsh] Объяснить все design choices. Объяснить как "зачем использовать X", так и "что привело конкретно меня к X" [Сделать для libsh] Либы должны собираться динамически и статически (чтобы можно было статически собирать проги) [Сделать для libsh] Указать зависимости, язык, ОС [Сделать для libsh] Тестировать на всех ОС, в том числе на Windows [Сделать для libsh] Собирать с максимальным уровнем предупреждений [Сделать для libsh] Все программы на C должны собираться компилятором C++ с максимальным уровнем предупреждений? [Сделать для libsh] Читать https://wiki.debian.org/UpstreamGuide , включая ссылки, https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code [Сделать для libsh] В случае если проект некоммерческий, свободный, следует UpstreamGuide и так далее - прямо об этом писать. А то есть полно коммерческих проектов без всякого UpstreamGuide [Сделать для libsh] Решает ли проект какую-то мою задачу? Т. е. нужен ли он мне? Если нет, то задача будет поставлена искусственно и будет непонятно, какие фичи нужны, а какие - нет. Вот допустим, ты пишешь свою либу для работы с bmp. Какие фичи нужны? Непонятно, т. к. мне такая программа не нужна libsh ----- Docs: отмечена "///", находится в начале funcs.in и помечена "docs:" в funcs.in. README.markdown не является частью All System 2-проекта. Разобраться со старыми доками из libsh-tools: ossp-ex-readme, ossp-ex.pod, xfuncs-readme-en, xfuncs-readme-ru, stdio.*, about-xfuncs Checklist: См. "[Сделать для libsh]" в checklist'е, остальной checklist сделан. При реализации многопоточности реально подумать, например, при непойманном исключении, видимо, должен завершаться поток, а не процесс TODO-Code: Есть единственный тег: SOMEDAY - сделать когда-нибудь, срочности нет вообще TODO-Files: В libsh-tools есть TODO. Дела в нём мне сейчас не нужны, можно откладывать сколько угодно, хорошо сформулированы, возможно, нужно сделать до публикации Blocking: Публиковать можно только после реализации дела про дополнительные функции типа tcp_connect из libsh-tools/TODO