学电子的小伙伴都知道，我们的逻辑电平0代表低，1代表高。还有，逻辑运算时，0代表假，非0值代表真。
那么，你发现一个问题没有，我们C/C++编程时，很多情况下都是返回0代表成功？
比如：RTOS创建任务返回“错误信息”
OS_ERR_NONE这个值就是宏定义的0：
#define OS_ERR_NONE 0u其实不止这个返回值，还有很多都是类似0代表成功（或无错误）。
在嵌入式C/C++编程中，函数返回0代表成功，一种广泛接受的约定。
为什么会有这种约定？其实背后都是有故事的，下面简单说几点。
1、历史原因
在早期的C语言编程实践中，特别是在早期的Unix系统编程中，0被用作成功执行的返回值，即程序执行成功没有错误发生，而非0值则表示出现了某种错误。
而Unix在当时又非常流行，后来，这种习惯随着这些系统和语言的普及而变得普遍。
2、统一规范
因为有前面 Uinx 的案例，后面的开发者为了代码的可读性和可维护性，许多编程标准和规范都使用0表示成功，这样可以使得代码在不同的开发者和项目之间保持一致性。
3、行业潜规则
随着时间的推移，这种使用0表示成功、非零值表示失败的约定，逐渐成为了C语言及嵌入式编程中的行业潜规则。遵守这一潜规则可以使代码更易于理解和维护，同时也便于不同程序员之间的协作。
同时，在编程社区中，这种约定已经深入人心，成为了编程实践中的一种标准做法。因此，即使在新开发的嵌入式系统中，也往往会延续这一潜规则。
4、符合逻辑
从逻辑上讲，成功通常被视为一种特殊情况（即只有一种可能），而失败则可能由多种原因造成（即有多种可能）。
比如上面举的例子RTOS中，存在很多种错误：
#define OS_ERR_NONE 0u
#define OS_ERR_EVENT_TYPE 1u
#define OS_ERR_PEND_ISR 2u
#define OS_ERR_POST_NULL_PTR 3u
#define OS_ERR_PEVENT_NULL 4u
#define OS_ERR_POST_ISR 5u
#define OS_ERR_QUERY_ISR 6u
#define OS_ERR_INVALID_OPT 7u
#define OS_ERR_ID_INVALID 8u
#define OS_ERR_PDATA_NULL 9u
#define OS_ERR_TIMEOUT 10u
#define OS_ERR_EVENT_NAME_TOO_LONG 11u
#define OS_ERR_PNAME_NULL 12u
#define OS_ERR_PEND_LOCKED 13u
#define OS_ERR_PEND_ABORT 14u
#define OS_ERR_DEL_ISR 15u
#define OS_ERR_CREATE_ISR 16u
#define OS_ERR_NAME_GET_ISR 17u
#define OS_ERR_NAME_SET_ISR 18u
#define OS_ERR_ILLEGAL_CREATE_RUN_TIME 19u
//...
#define OS_ERR_TLS_NO_MORE_AVAIL 160u
#define OS_ERR_TLS_ID_INVALID 161u
#define OS_ERR_TLS_NOT_EN 162u
#define OS_ERR_TLS_DESTRUCT_ASSIGNED 163u
#define OS_ERR_OS_NOT_RUNNING 164u你会发现，成功只有一种，错误有100多种。因此，使用唯一的0值来表示成功，并使用非零值来表示多种可能的失败情况，在逻辑上更为清晰和合理。
5、兼容性更强
很多时候，我们做项目都会使用第三方库，这个时候，如果你项目的规则和和第三方不一直，调试或维护代码就很恼火，一会0，一会儿非0，你都不知道究竟是什么意思了。
6、其他
其实还有很多原因，什么编码习惯、错误处理等，大致就是保持代码一致性的意思。当然，也欢迎大家留言说出更多原因。
说了这么多，其实，我们都是建立在别人成功的基础上，或者说站在巨人的肩膀上。你不要想着自己搞一套规则出来，这种情况，一般人都是找麻烦，除非你是真正的牛人。
END
作者：strongerHuang
来源：strongerHuang
推荐阅读
欢迎大家点赞留言，更多Arm技术文章动态请关注极术社区嵌入式客栈专栏欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
)
