Modify as review

Signed-off-by: Naqxyjay <zhangchunxin@huawei.com>

zh-cn/contribute/OpenHarmony-64bits-coding-guide.md

-# OpenHarmony 64位软件编程规范
+# OpenHarmony 32/64位可移植编程规范
 
 ## 前言
 
@@ -11,7 +11,11 @@ OpenHarmony支持三种系统类型：
 2. 小型系统（small system），面向应用处理器（例如Arm Cortex-A 64位）的设备，支持的设备最小内存为1MiB
 3. 标准系统（standard system），面向应用处理器（例如Arm Cortex-A 64位）的设备，支持的设备最小内存为128MiB
 
-因此，OpenHarmony的代码运行在32位/64位的设备上。对系统代码的可移植性、32位/64位运行模式下的编码需要一定的规约。本文以此为初衷，结合OpenHarmony的特点，拟定了相关编程规约，用于指导代码移植和64位编码，提升代码的规范性及One Track能力，供研发人员参考。
+因此，OpenHarmony的代码运行在32位/64位的设备上。对系统代码的可移植性、32位/64位运行模式下的编码需要一定的规约。本文以此为初衷，结合OpenHarmony的特点，拟定了相关编程规约，用于指导代码移植和64位编码，提升代码的规范性及可移植能力，供研发人员参考。
+
+### 适用范围
+
+用户态和内核态的C、C++代码，不区分语言的标准。
 
 ### 32位/64位系统的类型差异
 
@@ -91,15 +95,15 @@ typedef struct tagFoo {
 
 ### 总则
 
-#### 【规则】代码应当遵循Clean Code的要求，编写出可同时应用于32位和64位的代码
+#### 【规则】开发者贡献的代码应当遵循此规范，编写出可同时应用于32位和64位的代码
 
-【说明】由于OpenHarmony会长期同时存在32位的运行环境和64位的运行环境，而为了代码的一致性，达成One Track要求，在编码时需要充分考虑代码的可移植性能力。
+【说明】由于OpenHarmony会长期同时存在32位的运行环境和64位的运行环境，而为了代码的一致性，开发者在编码时需要充分考虑代码的可移植能力。
 
 ### 数据类型定义和格式化
 
 #### 【规则】应当使用统一定义的数据类型定义变量，无特殊意义或要求应当避免自行定义基本数据类型
 
-【说明】基于Clean Code和可移植性要求，在32位和64位条件下，可变长度的数据类型可能导致兼容性错误，为简单清晰，要求采用归一清晰的数据类型进行定义。基于当前的要求，定义下列基础数据类型：
+【说明】基于可移植性要求，在32位和64位条件下，可变长度的数据类型可能导致兼容性错误，为简单清晰，要求采用归一清晰的数据类型进行定义。基于当前的要求，定义下列基础数据类型：
 
 | 类型定义         | ILP32 | LP64  | PRINT   | 使用场景及代替类型                                           |
 | ---------------- | ----- | ----- | ------- | ------------------------------------------------------------ |
@@ -260,7 +264,7 @@ format ‘%p’ expects argument of type ‘void *’, but argument 2 has type
 | 0x8000000000L  | **NA或8** | **8** | 后缀为L，对超过uint32_t的范围常数，增加该参数没有意义，应当避免使用 |
 | 0x8000000000LL | 8         | 8     | 默认为LL，uint64_t类型                                       |
 
-从上表中可看出，使用L或UL后缀的常量，其长度在32位和64位下发生变化，不利于Clean Code，因此禁止使用这个后缀。
+从上表中可看出，使用L或UL后缀的常量，其长度在32位和64位下发生变化，不利于代码的可移植性，因此禁止使用这个后缀。
 
 【示例】
 

zh-cn/contribute/OpenHarmony-hdf-coding-guide.md

@@ -18,13 +18,9 @@ HDF（Hardware Driver Foundation）驱动框架，为开发者提供驱动框架
 
 【说明】HDF驱动框架提供了驱动加载、驱动服务管理和驱动消息机制，同时还提供了操作系统抽象层(OSAL, Operating System Abstract Layer)和平台抽象层(PAL, Platform Abstract Layer)来保证驱动程序的跨系统跨平台部署的特性。除此之外，HDF提供了驱动模型的抽象、公共工具、外围器件框架等能力。开发者应该基于HDF提供的这些能力开发驱动，从而保证驱动程序可以在各种形态的OpenHarmony上进行部署。
 
-#### 【规则】使用统一开发工具DevEco Device Tool进行驱动开发
+#### 【规则】开发者应当遵循此规范要求，开发能够同时满足内核态和用户态的驱动
 
-【说明】DevEco Device Tool为开发者提供一站式的开发环境、一站式资源获取通道，实现了从芯片模板工程创建、到开发资源挑选定制，再到快速编码、调试、调优、烧录环节的全流程覆盖。能够快速生成符合HDF框架的驱动源码以及配置文件，免去繁琐的目录创建及配置过程，方便开发者开发和管理驱动模块。
-
-#### 【规则】HDF驱动区分内核态与用户态，开发者应当按照两种不同形态的规范要求进行开发和部署
-
-【说明】内核态驱动与用户态驱动的开发规范存在着部分差异，两种形态适用的场景也不相同。开发者在业务设计的时候，应当明确驱动的部署形态，从而基于对应形态的规范要求来进行开发。内核态与用户态之间的差异，在本规范的后续章节中有详细阐述。
+【说明】内核态驱动与用户态驱动天然存在着差异，两种形态适用的场景也不尽相同。开发者在业务设计和开发的时候应当遵循此规范，使用HDF提供的OSAL、PAL等特性来屏蔽形态的差异，来保证开发的驱动同时满足内核态和用户态。
 
 #### 【建议】使用HDF框架时，编译脚本应当包含drivers/framework/include目录，而不是子模块目录