代码规范正在被某些低素质的开发人员给无视掉了！

[geniusgogo]

说某些人素质低，真的不是说你人品，而是指你的职业素质。 review了一下近期的更新看到些地方的代码规范越来越离谱： 1.命名，这特么什么鬼，最为中间件能用这么公用的命名？难道不能RT_DBG_XXX? / DEBUG level /

define DBG_ERROR 0

define DBG_WARNING 1

define DBG_INFO 2

define DBG_LOG 3

2.SConscirpt文件，同样作为demo或者测试代码或者公用组件，请严格按照功能来写。 src = Split(''' src/at_cli.c src/at_utils.c ''') 请问你的at_cli.c是AT组件必须的吗？ 我不想用不可以？难道让我把官方的SConscript组件文件改了是吧？合理吗？ 3.对齐方式，类似下面这种对齐方式也都存在。将就吧，别扭吧？ void eMBMasterRTUStart( void ) 4.新增加的组件AT所有接口，麻痹的既然出乎意料的不是rt打头，学学人家usb协议栈，看起来就舒服多了。

没有洁癖哪里来的艺术

[BernardXiong]

好吧，我表示很汗颜，rtdbg.h最初是我提出的，然后就是这样的风格 🦀

[armink]

跟素质有什么关系，自己的观念也没必要强加到别人身上。最早 at 组件都是有 rt 开头，后面还专门花了一两天时间去把 rt 去掉。你先多去用用再来抱怨。

[Lawlieta]

组件内部都必须以rt打头吗，finsh、dfs、vmm这些常用的老牌组件中接口怎么没有以rt开头？是不是这些都要改掉先？

[heyuanjie87]

我一般是不提供给其他组件或用户的接口就不加rt_，省三个字母是为了懒为了勤俭节约

[geniusgogo]

跟素质有什么关系，自己的观念也没必要强加到别人身上。最早 at 组件都是有 rt 开头，后面还专门花了一两天时间去把 rt 去掉。你先多去用用再来抱怨。

哪里是我的个人观念？这是我的观念？这些东西哪个不是约定俗成的东西或是口头强调或是明文规定？ 既然是约定俗成的东西或是口头强调或是明文规定的东西那么不遵守是不是职业素质出问题了？

[liruncong]

建议全面整理下类型定义.现在的类型定义很乱.很难让使用者搞得清楚,在什么地方该使用哪一套类型定义. 针对芯片厂提供的代码,可以先存储到独立的库上. 在这个库上存放一份原始的代码,和一份转换为rtthread风格后的代码.芯片厂更新代码后,先在这个库上更新转换前代码和转换后代码.然后再更新到rt-thread. 要保证rt-thread中代码风格一致.仅供参考.

[BernardXiong]

@geniusgogo 别扯到素质上去了，就事论事。AT组件，大家都能看得到，是一个非常好用，非常棒的组件。可能有些不同的声音，但是好评还是更多。

@liruncong typedef，不建议使用了；使用多了，会造成混乱，尽量都使用struct a_aa这样的方式，除非是你确实想隐藏些什么，例如FILE *fp；

随着RT-Thread代码规模上去，必然会遇到一些问题，欢迎大家向我们提出质疑出来。我们在RT-Thread 3.0.x、3.1.x的开发过程中，也时时刻刻在想着一些问题，如何能够尽量简化，把最大的便利提供给大家。但这个过程中不可能照顾到方方面面，所以还请大家多多提出建议，多多指正。

[liruncong]

@BernardXiong typedef本身不是问题. 具体问题,我举个例子: rtdef.h中定义了rt_uint8_t/rt_uint16_t/rt_uint32_t等类型,这个本意应该是要统一类型吧. 但是unsigned char/unsigned short/unsigned long等到处使用. 然后有时函数声明是unsigned int,函数定义就成了unsigned long.或者函数声明是unsigned int,定义时用rt_uint_32_t等等

[BernardXiong]

@liruncong 后续习惯于使用uint8_t/uint32_t等。也有过一次考虑，把这些私有的东西，都更改为标准的定义（包括rt_memcpy等也都取消），但是后来一些场景中需要保证系统核小型化（不依赖于libc），所以后来又反复了。

至少来说，rt_memcpy等这些kservice.c中的还是保留，并且在核心上尽量使用。

[liruncong]

@BernardXiong 你的意思是推荐使用int8_t/uint8_t/uint32_t这类编译器定义的类型，不建议使用rt_int8_t等这类rt专门定义的类型吧。这个我支持，可以少敲些3个字符。关于rt_memory，gcc我不确定，但是armcc和armclang是不需要对libc进行裁剪处理的，如果代码简单到只有memcpy函数，那么只会包含memcpy这个函数，不会包含其它libc函数。

[BernardXiong]

主要是gcc有这样的rt_memcpy的考虑，实际上在Keil/IAR下，memcpy的效率都会比rt_memcpy要高。

[liruncong]

@BernardXiong 应该测试下gcc在未初始化时memcpy是否正常?因为按道理这个拷贝不需要初始化任何东西. arm编译器的memcpy是不需要初始化C库或裁剪C库的. 另外,可否先把基本数据类型统一下?就是把rt_int32_t系列及unsiged long等定义移除,替换为int32_t系列?

[BernardXiong]

@liruncong 因为要保持独立的内核，所以rt_uint32_t等也不会移除。只是在一些非RTT范畴内的东西，会尽量避免使用。