返回：安全开发篇（一）目录 · 上一篇：009、控制台指令

对应视频：1.9 基础-语法规范风格.mp4

1、学习目标

这一节整理代码风格。代码风格不决定程序能不能编译，但会影响能不能长期维护、能不能快速审计、能不能定位安全问题。

需要掌握：

  1. 缩进统一；
  2. 命名清楚；
  3. 括号风格统一；
  4. 空行分隔逻辑；
  5. 注释解释原因和边界；
  6. 安全相关代码要主动暴露风险点。

2、基本规范

项目 建议
缩进 同一项目统一 4 空格或 Tab，不混用
命名 变量名表达含义，不用 a1、tmp2 到处乱飞
括号 {} 风格统一，嵌套层级清楚
空行 用空行分隔逻辑块，不要整篇挤在一起
注释 解释原因、边界和坑点，不重复代码表面意思
函数 一个函数只做相对清楚的一件事

代码规范不是为了好看，而是为了降低理解成本。能快速读懂的代码，才更容易被调试、审计和修复。

3、较乱的写法

1
2
#include<stdio.h>
int main(){int a=1;int b=2;printf("%d",a+b);return 0;}

这段代码能运行，但不适合复盘：

  1. 头文件和函数之间没有空行；
  2. 所有语句挤在一行；
  3. 变量名没有语义；
  4. 输出缺少说明和换行；
  5. 后续加断点不方便。

4、更适合复盘的写法

1
2
3
4
5
6
7
8
9
10
11
12
#include <stdio.h>

int main(void)
{
    int left = 1;
    int right = 2;
    int sum = left + right;

    printf("sum = %d\n", sum);

    return 0;
}

改进点：

  1. 结构清楚；
  2. 变量名表达含义；
  3. 输出可读；
  4. 每行语句便于断点调试；
  5. 后续扩展更容易。

5、安全开发中的命名习惯

安全相关代码要让风险点尽量清楚。

命名 含义
buffer_size 缓冲区大小
input_len 输入长度
is_valid 校验是否通过
has_error 是否出现错误
max_retry 最大重试次数
file_path 文件路径

不推荐把关键变量写成 a、b、p、buf2 一类难以判断用途的名字，除非它们只在极短范围内使用。

6、边界要写清楚

1
2
3
4
5
6
7
8
9
10
11
12
13
#include <stdio.h>

#define NAME_SIZE 16

int main(void)
{
    char name[NAME_SIZE] = {0};

    // 最多保存 15 个有效字符，最后 1 字节留给 '\0'
    printf("buffer size = %d\n", NAME_SIZE);

    return 0;
}

安全开发里，数组大小、字符串结束符、输入长度、返回值检查都应该在代码结构和注释里尽量清晰。

7、最小复盘代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#include <stdio.h>

void print_title(void)
{
    printf("==== Chap1 Environment And Framework ====\n");
}

int add(int left, int right)
{
    return left + right;
}

int main(void)
{
    print_title();

    int first = 10;
    int second = 20;
    int result = add(first, second);

    printf("%d + %d = %d\n", first, second, result);

    return 0;
}

这一章结束时，至少应该能独立写出这类小程序，并说清楚每一部分的作用。

8、学习检查清单

检查项 状态
能安装并打开 Visual Studio 的 C++ 桌面开发环境 待复盘
能新建控制台项目并添加 .c 文件 待复盘
能写出 Hello World 并解释每一行 待复盘
能区分注释、预处理指令、函数和语句 待复盘
能写一个普通函数并在 main 中调用它 待复盘
能使用 Ctrl + F5、断点或命令行观察运行结果 待复盘
能把代码整理成统一缩进和命名风格 待复盘

9、复盘题

9.1 代码风格会影响程序运行结果吗？

通常不会直接影响运行结果，但会影响阅读、调试、审计和维护成本。风格混乱的代码更容易藏住错误。

9.2 为什么安全相关变量要命名清楚？

因为安全问题常常出现在边界、长度、指针、状态和返回值上。变量名清楚，可以更快发现输入长度未检查、缓冲区大小不匹配、错误状态被忽略等问题。

9.3 注释应该重点记录哪些内容？

重点记录设计原因、边界条件、安全风险、实验观察和临时写法。不要只重复代码表面意思。

这一节的结论：规范不是形式主义。对安全开发来说，清楚的代码结构本身就是降低风险的一部分。