История изменений
Исправление monk, (текущая версия) :
Пальцем покажете? Мне вот, например, из прототипа hh_parse не очевидно, что сохраненные в r_name/r_value указатели подлежат освобождению вызывающей стороной.
Так тип же указывает. Если в выходной аргумент функции пишется строка, то почти всегда её должна освобождать вызывающая сторона. Документированию подлежат исключения, когда вместо заполнения выходного аргумента передаётся наружу указатель на какую-то внутреннюю структуру.
Что до очевидного, то мне лично пришлось долго вкуривать что делает вот этот фрагмент:
Подстрочник перевода:
все подчёркивания и дефисы заменить на дефис
не первую или не после дефиса: большие заменить на маленькие
после дефиса или первую: маленькие заменить на большие
если встретилось что-то кроме дефиса, подчёркивания, буквы или цифры, вернуть -3
Это требует дополнительного комментария?
Лучше было бы сделать enum.
Да. enum был бы эквивалентен этому комментарию.
Но теперь встречный вопрос: вы реально считаете, что комментарий, в котором перечислены целочисленные значения, и эти же целочисленные значения захардкожены в теле функции – это норм?
По стилю самой программы согласен, хотя на мой взгляд именно коды ошибок можно и хардкодить, если этих кодов не очень много.
Как раз чтобы не делать таких ошибок:
if(n==MAX_HEADER_NAME) return HH_PARSE_BAD_NAME;
Исходная версия monk, :
Пальцем покажете? Мне вот, например, из прототипа hh_parse не очевидно, что сохраненные в r_name/r_value указатели подлежат освобождению вызывающей стороной.
Так тип же указывает. Если в выходной аргумент функции пишется строка, то почти всегда её должна освобождать вызывающая сторона. Документированию подлежат исключения, когда вместо заполнения выходного аргумента передаётся наружу указатель на какую-то внутреннюю структуру.
Что до очевидного, то мне лично пришлось долго вкуривать что делает вот этот фрагмент: Подстрочник перевода:
все подчёркивания и дефисы заменить на дефис
не первую или не после дефиса: большие заменить на маленькие
после дефиса или первую: маленькие заменить на большие
если встретилось что-то кроме дефиса, подчёркивания, буквы или цифры, вернуть -3
Это требует дополнительного комментария?
Лучше было бы сделать enum.
Да. enum был бы эквивалентен этому комментарию.
Но теперь встречный вопрос: вы реально считаете, что комментарий, в котором перечислены целочисленные значения, и эти же целочисленные значения захардкожены в теле функции – это норм?
По стилю самой программы согласен, хотя на мой взгляд именно коды ошибок можно и хардкодить, если этих кодов не очень много.
Как раз чтобы не делать таких ошибок:
if(n==MAX_HEADER_NAME) return HH_PARSE_BAD_NAME;