Парадигма кодирования: Должен ли я вернуть 0, если функция успешна?
Когда я пишу пользовательскую функцию определения, я должен вернуть 0, если функция успешна или ненулевое значение?
Мне лично нравится возвращать 0, если моя функция успешна, но я всегда вижу обработку ошибок, как (!var) и меньше как (var != NULL), Так что было бы лучше вернуть какое-то значение, как 1, также известный как TRUEдаже в небулевой ситуации?
Что предлагает переполнение стека?
Причина, по которой я спрашиваю, заключается в том, что я написал небулевую оболочку для WINAPI BOOL CreateProcessW и это скинул мой код, потому что я был returning 0 в обертке и прежде чем я проверял, если TRUE,
3 ответа
Мне легче возвращать ненулевое значение в случае успеха, потому что тогда вы можете сказать что-то вроде:
int result = foo()
if (!result) { .. }
что гораздо яснее о намерениях. Часто NULL возвращается в исключительных случаях или в случаях ошибки, поэтому возвращение NULL в случае успеха противоречит интуиции.
Однако еще лучшим решением было бы использовать перечисления для всех кодов ошибок и сверяться с ними, а не использовать что-то вроде !result, Это позволит вам хорошо справиться и с несколькими кодами ошибок.
Я бы сказал, чтобы просто выбрать один и быть последовательным. Если вы работаете с каким-либо другим приложением значительным образом, постарайтесь соответствовать этому коду.
Мне нравится возвращать 0 в случае успеха, а затем использовать ненулевые числа для различных условий ошибки. Если вы используете 0 в качестве ошибки, то вы можете иметь только один вид возвращаемой ошибки, не вдаваясь в гораздо более сложную обработку ошибок. Но проверка на! Foo() может показаться нелогичной.
Это действительно субъективный вопрос, но в целом я бы предложил вернуть enum'd коды ошибок и явно проверить условия, которые вы ожидаете. Это позволяет избежать ситуаций, подобных той, в которой вы оказались.
Согласованность важнее, чем любая другая схема.