📝 docs(playbook): add contributing and multi-language standards
Introduce C++ and Python docs/templates and split .agents rulesets by language (tsl/cpp/python). Move commit message guidance to CONTRIBUTING.md (full spec remains in docs/common/commit_message.md).
This commit is contained in:
@@ -10,9 +10,9 @@
|
||||
|
||||
## 2. 格式
|
||||
|
||||
推荐使用以下结构(emoji 可选):
|
||||
推荐使用以下结构(emoji 可选,但建议默认带上以便快速扫读):
|
||||
|
||||
```
|
||||
```txt
|
||||
:emoji: type(scope): subject
|
||||
|
||||
body
|
||||
@@ -20,7 +20,7 @@ body
|
||||
footer
|
||||
```
|
||||
|
||||
- `emoji`:可选,位于首行行首;若使用,必须与 `type` 一一对应(见 4)。
|
||||
- `emoji`:可选,位于首行行首;若使用,必须与 `type` 一一对应(见 4)。为保持一致性,建议默认使用 emoji;若不使用则省略即可。
|
||||
- `type`:变更类型,必须从 4 的对应表中选取。
|
||||
- `scope`:可选,业务域/组件名(`lower_snake_case`),用于辅助定位影响范围。
|
||||
- `subject`:一句话概述,使用祈使句/现在时,首字母小写,不加句号。
|
||||
@@ -64,23 +64,23 @@ footer
|
||||
|
||||
本仓库采用固定的 `type`/emoji 一一对应关系;使用 emoji 时必须使用对应的那一个,不得错配。
|
||||
|
||||
| type | emoji(预览 / 代码) | 说明 |
|
||||
| ----------- | --------------------------------- | ---------------------------- |
|
||||
| `init` | :tada: `:tada:` | 初始化/首次发布 |
|
||||
| `feat` | :sparkles: `:sparkles:` | 新功能 |
|
||||
| `fix` | :bug: `:bug:` | Bug 修复 |
|
||||
| `perf` | :rocket: `:rocket:` | 性能优化 |
|
||||
| `refactor` | :recycle: `:recycle:` | 重构(行为不变) |
|
||||
| `style` | :art: `:art:` | 代码样式/格式(行为不变) |
|
||||
| `docs` | :memo: `:memo:` | 文档更新 |
|
||||
| `test` | :white_check_mark: `:white_check_mark:` | 测试新增/修正 |
|
||||
| `deps` | :package: `:package:` | 依赖更新 |
|
||||
| `security` | :lock: `:lock:` | 安全修复 |
|
||||
| `deprecate` | :warning: `:warning:` | 废弃/弃用标记 |
|
||||
| `remove` | :wastebasket: `:wastebasket:` | 删除功能/代码 |
|
||||
| `chore` | :wrench: `:wrench:` | 构建/配置/工具/维护性改动 |
|
||||
| `contrib` | :busts_in_silhouette: `:busts_in_silhouette:` | 贡献者/致谢相关 |
|
||||
| `release` | :bookmark: `:bookmark:` | 发布/打版本标签 |
|
||||
| type | emoji(预览 / 代码) | 说明 |
|
||||
| ----------- | --------------------------------------------- | ------------------------- |
|
||||
| `init` | :tada: `:tada:` | 初始化/首次发布 |
|
||||
| `feat` | :sparkles: `:sparkles:` | 新功能 |
|
||||
| `fix` | :bug: `:bug:` | Bug 修复 |
|
||||
| `perf` | :rocket: `:rocket:` | 性能优化 |
|
||||
| `refactor` | :recycle: `:recycle:` | 重构(行为不变) |
|
||||
| `style` | :art: `:art:` | 代码样式/格式(行为不变) |
|
||||
| `docs` | :memo: `:memo:` | 文档更新 |
|
||||
| `test` | :white_check_mark: `:white_check_mark:` | 测试新增/修正 |
|
||||
| `deps` | :package: `:package:` | 依赖更新 |
|
||||
| `security` | :lock: `:lock:` | 安全修复 |
|
||||
| `deprecate` | :warning: `:warning:` | 废弃/弃用标记 |
|
||||
| `remove` | :wastebasket: `:wastebasket:` | 删除功能/代码 |
|
||||
| `chore` | :wrench: `:wrench:` | 构建/配置/工具/维护性改动 |
|
||||
| `contrib` | :busts_in_silhouette: `:busts_in_silhouette:` | 贡献者/致谢相关 |
|
||||
| `release` | :bookmark: `:bookmark:` | 发布/打版本标签 |
|
||||
|
||||
注:`:white_check_mark:` 为补充图例,用于 `test` 类型。
|
||||
|
||||
@@ -146,7 +146,7 @@ MAJOR.MINOR.PATCH
|
||||
|
||||
带 emoji:
|
||||
|
||||
```
|
||||
```txt
|
||||
:sparkles: feat(order): add batch cancel api
|
||||
|
||||
support canceling multiple orders in one request; keep old api unchanged.
|
||||
@@ -156,6 +156,6 @@ Refs: TSL-1234
|
||||
|
||||
不带 emoji:
|
||||
|
||||
```
|
||||
```txt
|
||||
refactor(order): simplify cancel flow
|
||||
```
|
||||
|
||||
@@ -0,0 +1,23 @@
|
||||
# clangd 补全配置(`.clangd`)
|
||||
|
||||
本章节提供 `clangd` 的推荐配置模板与落地要点(参考 `tsl-devkit/lsp-server/.clangd`)。
|
||||
|
||||
## 1. 目标
|
||||
|
||||
- 让 IDE/编辑器的 C++ 补全、跳转、诊断稳定可复现。
|
||||
- 优先依赖 `compile_commands.json`(由 CMake 生成),避免手写复杂编译参数。
|
||||
|
||||
## 2. 必要前提:生成 `compile_commands.json`
|
||||
|
||||
- CMake:建议开启 `CMAKE_EXPORT_COMPILE_COMMANDS=ON`(本 Playbook 的 `templates/cpp/CMakeLists.txt` 已开启)。
|
||||
- 使用 preset 构建后,在对应 build 目录会生成 `compile_commands.json`:
|
||||
- 例如:`build/windows-x86_64-clang-cross/Release/compile_commands.json`
|
||||
|
||||
## 3. `.clangd` 模板
|
||||
|
||||
- 模板文件:`templates/cpp/.clangd`
|
||||
- 关键字段:`CompileFlags.CompilationDatabase` 指向 build 目录(包含 `compile_commands.json` 的目录)。
|
||||
|
||||
## 4. Modules 注意事项(C++23)
|
||||
|
||||
- 若新增/删除/重命名 `.cppm`,必须同步更新构建系统的模块清单(例如 CMake `FILE_SET CXX_MODULES`),否则 `compile_commands.json` 可能缺项,导致 clangd 补全/跳转不稳定。
|
||||
@@ -0,0 +1,72 @@
|
||||
# C++ 代码风格(Code Style)
|
||||
|
||||
本章节规定 C++(C++23,含 Modules)代码的结构与格式约定。
|
||||
|
||||
## 1. 文件与组织
|
||||
|
||||
### 1.1 目录建议(项目落地)
|
||||
|
||||
推荐将 C++ 代码放在独立目录(多语言项目便于隔离规则与工具):
|
||||
|
||||
```txt
|
||||
cpp/
|
||||
include/ # 对外头文件(如项目仍使用头文件边界)
|
||||
src/ # 实现文件与 module 实现单元
|
||||
modules/ # module interface / partition(如使用 modules)
|
||||
tests/ # (可选)测试
|
||||
CMakeLists.txt
|
||||
```
|
||||
|
||||
若项目不采用 `cpp/` 根目录,也应保持 include/src/modules 分层清晰。
|
||||
|
||||
### 1.2 文件扩展名约定
|
||||
|
||||
- 头文件:`.h`(Google 风格;若项目已统一 `.hpp`,以项目既有为准)
|
||||
- 源文件:`.cc`(优先;`main` 入口建议使用 `main.cc`;若项目已统一 `.cpp`,以项目既有为准)
|
||||
- Module Interface Unit:`.cppm`(推荐统一)
|
||||
- Module Partition:`.cppm`(在文件名中体现分区,例如 `foo_part.cppm`)
|
||||
|
||||
### 1.3 Modules 约定(C++23)
|
||||
|
||||
- Module 名称建议使用“点分层级”组织,且每一段使用 `lower_snake_case`:
|
||||
- 示例:`my_project.net.http`
|
||||
- 文件路径与 module 名建议可映射(便于检索):
|
||||
- `cpp/modules/my_project/net/http.cppm` → `export module my_project.net.http;`
|
||||
- 避免在同一模块内混用“头文件边界”和“模块边界”造成可见性混乱;对外 API 优先通过 `export` 暴露。
|
||||
- 工程约束:新增/删除/重命名 `.cppm`(或变更 `export module ...`)时,必须同步更新构建系统的模块清单(例如 CMake 的 `target_sources(FILE_SET CXX_MODULES ...)`),否则容易出现“本地能编、CI/他人机器不能编”的漂移。
|
||||
|
||||
## 2. 格式(Formatting)
|
||||
|
||||
### 2.1 clang-format(必选)
|
||||
|
||||
- 本仓库/标准默认:`clang-format` + Google 风格。
|
||||
- 建议在项目根目录提供 `.clang-format` 并纳入 CI/本地钩子。
|
||||
- 列宽建议与本 Playbook 其他语言保持一致:默认 100(可按项目调整,但要全仓一致)。
|
||||
- 模板:`templates/cpp/.clang-format`(参考 `tsl-devkit/lsp-server/.clang-format` 并做了最小化泛化)。
|
||||
|
||||
### 2.2 通用格式约定
|
||||
|
||||
- 缩进使用空格,单次缩进 4 空格(Google)。
|
||||
- 不做“空格对齐排版”(避免 diff 噪音),用缩进表达结构。
|
||||
- 头文件 include 顺序建议(从上到下):
|
||||
1. 本文件对应头(如有)
|
||||
2. C 标准库 / C++ 标准库
|
||||
3. 第三方库
|
||||
4. 项目内其他头/模块导入
|
||||
|
||||
## 3. 头文件与可见性
|
||||
|
||||
- 头文件应可被独立 include(自包含)。
|
||||
- 对外接口放在 `include/`,实现细节放 `src/`。
|
||||
- 避免在头文件中引入沉重依赖;可用前置声明或 PImpl(按项目需要)。
|
||||
|
||||
## 4. 错误处理与资源管理
|
||||
|
||||
- 默认使用 RAII 管理资源;避免裸 `new/delete`。
|
||||
- 禁止吞异常/忽略错误;失败路径必须可观测(返回值/异常/日志其一或按项目约定)。
|
||||
|
||||
## 5. Windows 支持
|
||||
|
||||
- 本规范假设 **不做原生 Windows 开发环境支持**;Windows 产物通过 **Linux 上的 Clang 交叉编译工具链**获得(工具链路径/三元组等由项目的 Conan profile 或 toolchain 文件定义)。
|
||||
- 如需条件编译,优先用标准特性检测与最小化条件编译,并写清动机(例如 ABI/平台差异)。
|
||||
- 对路径、换行、编码、大小写敏感等行为要明确约束并在文档/测试中覆盖。
|
||||
@@ -0,0 +1,79 @@
|
||||
# C++ 第三方依赖(Conan)
|
||||
|
||||
本章节给出 Conan + CMake 的推荐落地方式(参考 `tsl-devkit/lsp-server/` 的实践)。
|
||||
|
||||
## 1. 基本约定
|
||||
|
||||
- 依赖清单使用 `conanfile.txt`(或项目统一的 `conanfile.py`)。
|
||||
- 本 Playbook 不内置“标准依赖集合/固定版本”;依赖选择与版本锁定由具体项目维护。
|
||||
- Conan:`2.x`(本 Playbook 假设 Conan 2;不保证 Conan 1 的兼容性)
|
||||
- 生成器使用:
|
||||
- `CMakeDeps`
|
||||
- `CMakeToolchain`
|
||||
- layout 使用:`cmake_layout`(让 build 目录结构稳定可预测)
|
||||
|
||||
## 2. 目录与文件(建议)
|
||||
|
||||
```txt
|
||||
cpp/
|
||||
conanfile.txt
|
||||
conan/
|
||||
profiles/
|
||||
<platform>-<arch>-clang
|
||||
windows-<arch>-clang-cross
|
||||
CMakeLists.txt
|
||||
CMakeUserPresets.json
|
||||
build/ # 本地/CI 生成,通常不入库
|
||||
```
|
||||
|
||||
## 3. Profile 命名与含义(规范)
|
||||
|
||||
- Profile 文件名按“产物平台”为前缀,避免误读:
|
||||
- `linux-...`:产物平台为 Linux(`[settings] os=Linux`)
|
||||
- `windows-...`:产物平台为 Windows(`[settings] os=Windows`)
|
||||
- 跨编译 profile 建议以 `-cross` 结尾(例如 `windows-x86_64-clang-cross`)。
|
||||
- “工具链版本”以 profile 的 `[settings] compiler.version` 为准;如同一仓库并存多版本 clang,可将版本体现在文件名中(例如 `linux-x86_64-clang20`)。
|
||||
|
||||
## 4. 安装与构建(推荐流程)
|
||||
|
||||
在项目的 C++ 根目录(例如 `cpp/`)下:
|
||||
|
||||
1. 安装依赖并生成工具链文件:
|
||||
- `CONAN_HOME=/tmp/conan-home conan install . -pr:b=conan/profiles/linux-x86_64-clang -pr:h=conan/profiles/windows-x86_64-clang-cross -of build/windows-x86_64-clang-cross --build=missing`
|
||||
- 若有 profile:`-pr:h=conan/profiles/<...> -pr:b=conan/profiles/<...>`
|
||||
2. 配置 CMake:
|
||||
- 直接指定 toolchain:
|
||||
- `cmake -S . -B build/clang -G Ninja -DCMAKE_TOOLCHAIN_FILE=$PWD/build/clang/Release/generators/conan_toolchain.cmake`
|
||||
- 或使用 Presets(推荐,见下节):
|
||||
- `cmake --preset conan-release`
|
||||
3. 构建:
|
||||
- `cmake --build --preset conan-release -j 8`
|
||||
|
||||
提示:如遇到 Conan 缓存/家目录权限问题,可临时设置 `CONAN_HOME=/tmp/conan-home` 再执行。
|
||||
|
||||
## 5. CMake Presets(推荐做法)
|
||||
|
||||
Conan 2 可以生成 CMake Presets(通常落在 `build/<...>/generators/CMakePresets.json`)。
|
||||
|
||||
推荐将一个稳定的 `CMakeUserPresets.json` 放进仓库并 include 生成文件(参考 `tsl-devkit/lsp-server/CMakeUserPresets.json`),例如:
|
||||
|
||||
```json
|
||||
{
|
||||
"version": 4,
|
||||
"vendor": { "conan": {} },
|
||||
"include": ["build/clang-linux/Release/generators/CMakePresets.json"]
|
||||
}
|
||||
```
|
||||
|
||||
这样团队/CI 就可以统一使用:
|
||||
|
||||
- 配置:`cmake --preset conan-release`
|
||||
- 构建:`cmake --build --preset conan-release -j 8`
|
||||
- 测试:`ctest --preset conan-release --output-on-failure`
|
||||
|
||||
## 6. 模板文件(本 Playbook)
|
||||
|
||||
- `templates/cpp/conanfile.txt`
|
||||
- `templates/cpp/CMakeUserPresets.json`
|
||||
- `templates/cpp/conan/profiles/linux-x86_64-clang`
|
||||
- `templates/cpp/conan/profiles/windows-x86_64-clang-cross`
|
||||
@@ -0,0 +1,31 @@
|
||||
# C++ 命名规范(Naming)
|
||||
|
||||
本章节以 Google C++ Style Guide 为基线,并补充模块化(Modules)相关的命名约定。
|
||||
|
||||
## 1. 总原则
|
||||
|
||||
- 一致性优先:以仓库现有风格为准,标准用于“无上下文/新代码”的默认选择。
|
||||
- 名字体现作用域与语义,不用 `tmp/data/info` 这类弱语义词。
|
||||
|
||||
## 2. 命名风格总览(默认)
|
||||
|
||||
- 类型(class/struct/enum/using):`PascalCase`
|
||||
- 函数/方法:`PascalCase`
|
||||
- 变量:`lower_snake_case`
|
||||
- 成员变量:`lower_snake_case_`(尾随下划线,Google)
|
||||
- 常量:`kPascalCase`(编译期/全局固定值)
|
||||
- 命名空间:`lowercase` 或 `lower_snake_case`(按项目约定,建议全仓统一)
|
||||
|
||||
## 3. 文件命名
|
||||
|
||||
- 文件名:`lower_snake_case`(与 Google 风格一致)
|
||||
- 头文件:`foo_bar.h`
|
||||
- 源文件:`foo_bar.cc`
|
||||
- Module 文件:`foo_bar.cppm`
|
||||
|
||||
## 4. Modules 命名
|
||||
|
||||
- Module 名使用点分层级:`<root>.<subsystem>.<component>`
|
||||
- 每一段建议用 `lower_snake_case`:
|
||||
- 示例:`my_project.market.data_feed`
|
||||
- 文件路径建议与 module 名可映射(便于检索与定位)。
|
||||
@@ -0,0 +1,80 @@
|
||||
# C++ 工具链与验证命令(模板)
|
||||
|
||||
本文件提供一份**通用占位模板**,用于在不同 C++ 项目中快速补齐“工具链与如何验证”的关键上下文。
|
||||
|
||||
## 1. 工具链(必填)
|
||||
|
||||
### 1.1 编译器与标准
|
||||
|
||||
- C++ 标准:C++23(含 Modules)
|
||||
- 编译器:
|
||||
- 目标平台:Windows(通过 Linux 交叉编译)
|
||||
- 主机平台:Linux
|
||||
- 工具链:`clang <版本>`(交叉编译;具体 clang 可执行路径由 Conan profile 配置)
|
||||
- 目标三元组(示例):`x86_64-w64-mingw32` / `aarch64-w64-mingw32`
|
||||
|
||||
### 1.2 构建系统
|
||||
|
||||
- CMake:`>= 4.0`
|
||||
- 生成器:
|
||||
- Linux:`Ninja`
|
||||
|
||||
### 1.3 依赖管理(Conan,推荐)
|
||||
|
||||
若项目使用 Conan 管理三方依赖,建议:
|
||||
|
||||
- Conan:`2.x`(本 Playbook 假设 Conan 2;不保证 Conan 1 的兼容性)
|
||||
- 使用 `conanfile.txt` + `CMakeDeps` + `CMakeToolchain` + `cmake_layout`(参考 `tsl-devkit/lsp-server/conanfile.txt`)。
|
||||
- 通过 `conan install` 生成工具链与(可选)CMake Presets,再用 `cmake --preset ...` 构建。
|
||||
|
||||
### 1.4 格式化(必选)
|
||||
|
||||
- `clang-format`:`<项目自选并固定版本>`
|
||||
- 兼容性策略:
|
||||
- `.clang-format` 是唯一真相(推荐使用 `templates/cpp/.clang-format` 落地到项目根目录)。
|
||||
- 不同版本的 `clang-format` 可能对同一配置产生不同输出;项目应在 CI/开发环境中固定版本,避免格式漂移。
|
||||
- CI 推荐用 `clang-format --dry-run --Werror <files...>` 做格式校验。
|
||||
|
||||
### 1.5 静态检查(暂不启用)
|
||||
|
||||
- `clang-tidy`:暂不启用(若未来启用,写明版本、配置文件与运行命令)
|
||||
|
||||
## 2. 验证命令(必填:把占位符替换成真实命令)
|
||||
|
||||
### 2.1 最小构建(必须能跑)
|
||||
|
||||
- Conan 生成(推荐,示例):
|
||||
- `CONAN_HOME=/tmp/conan-home conan install . -pr:b=conan/profiles/linux-x86_64-clang -pr:h=conan/profiles/windows-x86_64-clang-cross -of build/windows-x86_64-clang-cross --build=missing`
|
||||
- 配置(示例):
|
||||
- `cmake --preset conan-release`
|
||||
- 构建(示例):
|
||||
- `cmake --build --preset conan-release -j 8`
|
||||
|
||||
### 2.2 运行冒烟(建议)
|
||||
|
||||
- `build/<app_or_tool> <args>`
|
||||
- 或:`cmake --build build -t run_smoke`(如项目提供自定义 target)
|
||||
|
||||
### 2.3 格式化检查(建议)
|
||||
|
||||
- `clang-format -i <files...>`(本地)
|
||||
- `clang-format --dry-run --Werror <files...>`(CI)
|
||||
|
||||
### 2.4 失败处理约定(必填)
|
||||
|
||||
- 只修复与本次改动直接相关的失败;无关失败记录并隔离。
|
||||
- 若某步骤无法执行(缺环境/缺权限),必须写出原因与替代验证(例如手动检查清单/最小复现工程)。
|
||||
|
||||
## 3. Presets(可选但强烈推荐)
|
||||
|
||||
参考 `tsl-devkit` 的做法:
|
||||
|
||||
- 将 `CMakeUserPresets.json` 纳入版本控制,并 `include` Conan 生成的 `build/.../generators/CMakePresets.json`。
|
||||
- 优点:统一 Windows/Linux/macOS 构建入口;Agent 也更容易用固定命令验证。
|
||||
|
||||
本 Playbook 约定:
|
||||
|
||||
- **强制统一 preset 名称**:`conan-release` / `conan-debug`(项目必须提供这两个 preset;实现方式不限:可由 Conan 生成,也可由项目自建 `CMakePresets.json` 适配)。
|
||||
- `CMakeUserPresets.json` 不是强制标准,仅作为一种推荐落地方式(模板见 `templates/cpp/CMakeUserPresets.json`)。
|
||||
|
||||
不在本 Playbook 中强制规定工具链分发方式(例如某种特定打包形态);只要求把交叉编译所需的 `compiler_executables`、triplet、system_name 等写进 Conan profile,保证命令可复现。
|
||||
@@ -11,3 +11,18 @@
|
||||
- TSL 源文件后缀同时包含:`.tsl`(脚本)与 `.tsf`(模块/库代码)。
|
||||
- 代码风格:`tsl/code_style.md`
|
||||
- 命名规范:`tsl/naming.md`
|
||||
- 工具链与验证命令(模板):`tsl/toolchain.md`
|
||||
|
||||
## C++(cpp)
|
||||
|
||||
- 代码风格:`cpp/code_style.md`
|
||||
- 命名规范:`cpp/naming.md`
|
||||
- 工具链与验证命令(模板):`cpp/toolchain.md`
|
||||
- 第三方依赖(Conan):`cpp/dependencies_conan.md`
|
||||
- clangd 配置:`cpp/clangd.md`
|
||||
|
||||
## Python(python)
|
||||
|
||||
- 代码风格:`python/style_guide.md`
|
||||
- 工具链:`python/tooling.md`
|
||||
- 配置清单:`python/configuration.md`
|
||||
|
||||
@@ -0,0 +1,65 @@
|
||||
# Python 配置清单(Configuration)
|
||||
|
||||
本文件用于把 Python 工具配置“汇总说明”到一个可读入口。
|
||||
|
||||
注意:本 Playbook 将可复制模板放在 `templates/python/`;在目标项目落地时,这些文件通常需要复制到**项目根目录**(工具默认查找位置):
|
||||
|
||||
- `pyproject.toml`
|
||||
- `.flake8`
|
||||
- `.pylintrc`
|
||||
- `.pre-commit-config.yaml`
|
||||
- `.editorconfig`
|
||||
- `.vscode/settings.json`
|
||||
|
||||
## 1) `pyproject.toml`
|
||||
|
||||
模板文件:`templates/python/pyproject.toml`
|
||||
|
||||
- `tool.black`
|
||||
- `line-length = 80`
|
||||
- `target-version = ['py313']`(按项目 Python 版本调整)
|
||||
- `tool.isort`
|
||||
- `profile = "google"`
|
||||
- `line_length = 80`
|
||||
- `known_third_party` / `known_first_party`:按项目维护
|
||||
- `tool.mypy`
|
||||
- `python_version = "3.13"`(按项目调整)
|
||||
- `ignore_missing_imports = true`(对第三方二进制/无类型库更友好)
|
||||
- `tool.pytest.ini_options`
|
||||
- 测试发现与参数(若项目引入 `tests/` 会自动生效)
|
||||
|
||||
## 2) `.flake8`
|
||||
|
||||
模板文件:`templates/python/.flake8`
|
||||
|
||||
- `max-line-length = 80`
|
||||
- `docstring-convention = google`
|
||||
- 与 `black` 冲突的规则已屏蔽(例如 `E203`、`W503`)
|
||||
|
||||
## 3) `.pylintrc`
|
||||
|
||||
模板文件:`templates/python/.pylintrc`
|
||||
|
||||
- 命名风格:snake_case / PascalCase 等(对齐 Google Python 风格)
|
||||
- `max-line-length = 80`
|
||||
- `init-hook` 将项目根目录加入 `sys.path`(便于本地运行与检查;如项目不需要可移除)
|
||||
|
||||
## 4) `.pre-commit-config.yaml`
|
||||
|
||||
模板文件:`templates/python/.pre-commit-config.yaml`
|
||||
|
||||
- 基础文本检查:尾随空格、文件末尾换行、YAML/TOML 基础校验
|
||||
- Python:`black`、`isort`、`flake8`
|
||||
|
||||
## 5) `.editorconfig`
|
||||
|
||||
模板文件:`templates/python/.editorconfig`
|
||||
|
||||
- Python:4 空格缩进、行宽 80
|
||||
- 通用:UTF-8、LF、去尾随空格、文件末尾换行
|
||||
|
||||
## 6) `.vscode/settings.json`
|
||||
|
||||
模板文件:`templates/python/.vscode/settings.json`
|
||||
|
||||
- 保存即格式化、80 列标尺、默认使用 Black formatter、按需组织 import
|
||||
@@ -0,0 +1,14 @@
|
||||
# Python 代码风格(Google Python Style Guide)
|
||||
|
||||
本 Playbook 的 Python 代码风格以 Google Python Style Guide 为基线(基于 PEP 8):
|
||||
|
||||
- Google Python Style Guide: https://google.github.io/styleguide/pyguide.html
|
||||
- PEP 8: https://peps.python.org/pep-0008/
|
||||
|
||||
## 项目约定(Project Conventions)
|
||||
|
||||
- 行宽:80(与 `black`/`flake8`/`pylint` 配置保持一致)
|
||||
- docstring:Google 风格(与 `.flake8` 的 `docstring-convention = google` 对齐)
|
||||
- import 顺序:使用 `isort` 的 `profile = google`
|
||||
|
||||
当既有代码与本约定冲突时,优先保持局部一致性,逐步迁移。
|
||||
@@ -0,0 +1,36 @@
|
||||
# Python 工具链(Tooling)
|
||||
|
||||
本 Playbook 推荐用以下工具保证代码一致性与质量:
|
||||
|
||||
- `black`:格式化(行宽 80)
|
||||
- `isort`:import 排序(Google profile)
|
||||
- `flake8`:风格检查 + docstring 约定
|
||||
- `pylint`:静态检查(以 `.pylintrc` 为准,可按项目调整)
|
||||
- `mypy`:类型检查(可选)
|
||||
- `pytest`:测试(可选)
|
||||
- `pre-commit`:在 `git commit` 前自动运行上述检查/格式化(可选,但推荐)
|
||||
|
||||
## 常用命令(示例)
|
||||
|
||||
安装工具(示例,按项目实际依赖管理方式调整):
|
||||
|
||||
```bash
|
||||
python -m pip install black isort flake8 pylint mypy pytest pre-commit
|
||||
```
|
||||
|
||||
格式化与检查(示例):
|
||||
|
||||
```bash
|
||||
black .
|
||||
isort .
|
||||
flake8 .
|
||||
pylint .
|
||||
mypy .
|
||||
pytest
|
||||
```
|
||||
|
||||
启用 `pre-commit`(只需一次):
|
||||
|
||||
```bash
|
||||
pre-commit install
|
||||
```
|
||||
@@ -24,7 +24,6 @@
|
||||
- 所有语法关键字统一使用全小写书写,例如 `if`、`for`、`class`、`function`、`unit`、`return` 等。
|
||||
- 调用内置/标准库方法时,推荐保持官方大小写形式(`aaBBCC`/lowerCamelCase),例如 `getSysParams("xxx")`。
|
||||
|
||||
|
||||
## 3. 类型命名(Type Names)
|
||||
|
||||
TSL 的顶层声明只有三种:`class`、`unit`、`function`。
|
||||
|
||||
@@ -0,0 +1,62 @@
|
||||
# TSL 工具链与验证命令(模板)
|
||||
|
||||
本文件提供一份**通用占位模板**,用于在不同 TSL 项目中快速补齐“工具链与如何验证”的关键上下文。
|
||||
|
||||
使用方式:
|
||||
|
||||
- 在具体项目中复制本模板并把占位符替换为真实信息;
|
||||
- 或在项目文档中引用本模板,并在项目内提供对应的 `scripts/*` 统一入口脚本。
|
||||
|
||||
## 1. TSL 工具链
|
||||
|
||||
### 1.1 解释器/编译器(必填)
|
||||
|
||||
- 工具名称:`<tsl/tslcli/内部工具名>`
|
||||
- 可执行命令:
|
||||
- macOS/Linux:`<command>`(例:`tsl` / `tslcli` / `sh scripts/tsl.sh`)
|
||||
- Windows:`<command>`(例:`tsl.exe` / `tslcli.exe` / `powershell -File scripts/tsl.ps1`)
|
||||
- 版本要求:`<固定版本或范围,例如:= 3.2.1 / >=3.2,<4.0>`
|
||||
- 安装方式:`<内部安装包/路径/IDE 自带/CI 镜像等>`
|
||||
- 推荐统一入口脚本:`scripts/tsl.{sh,ps1}`(封装参数与环境变量,避免每个任务重复猜测)
|
||||
|
||||
### 1.2 运行环境(按需)
|
||||
|
||||
- 必要环境变量:`<TSL_HOME> <TSL_LIB_PATH> <LICENSE_PATH> ...`
|
||||
- 外部依赖:`<数据库/服务/共享目录/网络权限/账户权限>`
|
||||
- 运行约束:
|
||||
- 是否允许联网:`<yes/no>`
|
||||
- 是否需要许可证/凭证:`<说明如何在本地与 CI 提供;禁止写入仓库>`
|
||||
|
||||
## 2. 验证命令
|
||||
|
||||
> 要求:改动完成后至少能跑通“最小冒烟”;若项目存在测试体系,尽量补到对应层级。
|
||||
|
||||
### 2.1 最小冒烟(必须能跑)
|
||||
|
||||
- macOS/Linux:`<tsl> run <path/to/SmokeTest.tsl> -- <args>`
|
||||
- Windows:`<tsl.exe> run <path\\to\\SmokeTest.tsl> -- <args>`
|
||||
- 或统一入口:
|
||||
- `sh scripts/smoke.sh`
|
||||
- `powershell -File scripts/smoke.ps1`
|
||||
|
||||
### 2.2 单元测试(如有)
|
||||
|
||||
- `sh scripts/test.sh`
|
||||
- 或:`<tsl> test <tests/>`
|
||||
- 或:`<tsl> run <path/to/TestRunner.tsf>`
|
||||
|
||||
### 2.3 静态检查/格式化(如有)
|
||||
|
||||
- `sh scripts/lint.sh`
|
||||
- `sh scripts/format.sh`
|
||||
- 或:`<tsl> check <src/>` / `<tsl> fmt <src/>`
|
||||
|
||||
### 2.4 构建/打包(如有)
|
||||
|
||||
- `sh scripts/build.sh`
|
||||
- 或:`<tsl> build <project-file>`
|
||||
|
||||
### 2.5 失败处理约定(必填)
|
||||
|
||||
- 只修复与本次改动直接相关的失败;无关失败在输出中说明并隔离。
|
||||
- 若某验证步骤无法执行(缺环境/缺凭证),必须明确写出原因与替代验证手段(例如最小复现脚本/手动检查清单)。
|
||||
Reference in New Issue
Block a user