|
|
|
@@ -1,2 +1,117 @@ |
|
|
|
# THUAI6 |
|
|
|
清华大学第六届人工智能挑战赛电子系赛道(原电子系第 24 届队式程序设计大赛 teamstyle24) |
|
|
|
|
|
|
|
## 赛题背景 |
|
|
|
|
|
|
|
待定 |
|
|
|
|
|
|
|
## 比赛规则 |
|
|
|
|
|
|
|
待定 |
|
|
|
|
|
|
|
## 软件架构 |
|
|
|
|
|
|
|
待定 |
|
|
|
|
|
|
|
## 仓库说明 |
|
|
|
|
|
|
|
### 配置说明 |
|
|
|
|
|
|
|
本仓库使用 git 进行版本控制,为所有开发工作共用仓库,请勿上传不必要的文件。主目录文件结构非必要请勿修改,且主目录中已配置的`.gitignore`、`.gitattributes`文件非必要请勿修改;各子目录已预先包含使用`Visual Studio`开发的`.gitignore`模板,可以根据自身需要增加忽略规则;如有必要,可在子目录下自定义`.gitattributes`文件。 |
|
|
|
|
|
|
|
### 目录分配 |
|
|
|
|
|
|
|
待定。 |
|
|
|
|
|
|
|
### 分支管理 |
|
|
|
|
|
|
|
- main:代码较稳定版本或阶段性成果,需要 2 reviewers,但由总负责人(端茶倒水)维护 |
|
|
|
- dev:各开发者开发工作的最新进展,需要 1 reviewer |
|
|
|
|
|
|
|
## 开发规则 |
|
|
|
|
|
|
|
### 关于社区开发者 |
|
|
|
|
|
|
|
- 社区开发者开发工作请遵循 [THUAI6社区开发者贡献指南](./CONTRIBUTING.md) |
|
|
|
- 社区开发者贡献的代码请遵循 [Contributor Covenant Code of Conduct](./CODE_OF_CONDUCT.md) |
|
|
|
|
|
|
|
### 开发流程 |
|
|
|
|
|
|
|
THUAI6 开发组成员与其他贡献者应当遵循以下流程: |
|
|
|
|
|
|
|
1. 将 `eesast/THUAI6` fork 到自己的仓库中 |
|
|
|
2. 基于 `dev` 分支建立一个新的功能分支 |
|
|
|
3. 在新的分支上进行修改与开发 |
|
|
|
4. 向 `eesast/THUAI6` 的 `dev` 分支提出 pull request |
|
|
|
5. 等待其他开发组成员 review 与 merge |
|
|
|
|
|
|
|
### 使用 Git 与 Github 时的注意事项 |
|
|
|
|
|
|
|
- 非必要请勿上传大文件到 Github |
|
|
|
|
|
|
|
- commit 提交信息请遵循 Semantic Commit 规范,即:`type: content `格式 |
|
|
|
|
|
|
|
常用的 commit message type 包括: |
|
|
|
|
|
|
|
| Type | Explanation | |
|
|
|
| -------- | ---------------------------------------------- | |
|
|
|
| chore | 日常代码开发;改变构建流程;增加依赖库、工具等 | |
|
|
|
| fix | 修复bug | |
|
|
|
| refactor | 改变代码结构,但没有增加新功能 | |
|
|
|
| docs | 修改文档,如 README、CONTRIBUTE 等 | |
|
|
|
| revert | 版本回退 | |
|
|
|
| ... | ... | |
|
|
|
|
|
|
|
- 鼓励开发组成员之间互相 review 并 merge 代码到 dev 分支上。merge 前建议简单检查其 pull request 是否符合上述规范 |
|
|
|
- 一般情况下,不要向 main 分支提出 pull request,更不要 merge 到 main 分支上 |
|
|
|
- 一般情况下,不允许 merge 无法通过 CI 的 pull request |
|
|
|
|
|
|
|
### 开发约定 |
|
|
|
|
|
|
|
+ 统一使用空格缩进而非制表符缩进 |
|
|
|
+ 统一使用 4 个空格进行缩进而非 2 个 |
|
|
|
+ 统一使用 UTF-8 字符编码 |
|
|
|
|
|
|
|
## 其他注意事项 |
|
|
|
|
|
|
|
+ 文件的字符编码格式须统一使用 UTF-8 编码,并用 4 空格缩进,尤其是 C/C++:Visual Studio 创建 cpp 文件时默认使用 GB2312 编码、TAB 缩进,因此每创建一个文件都需要注意手动设置字符编码(当代码文件中出现中文时)和缩进方式 |
|
|
|
|
|
|
|
+ 使用等宽字体进行编程,例如 Source Code Pro、Consolas 等,便于对齐 |
|
|
|
|
|
|
|
+ 注意代码的整洁性与可读性 |
|
|
|
|
|
|
|
+ 代码风格尽量统一。书写不要过于紧凑,善于使用空格、缩进与换行来让代码看起来更整洁 |
|
|
|
|
|
|
|
+ 命名风格尽量统一。相同类别的命名规则要相同,例如类名统一使用大驼峰命名法或其他常用的命名法,但是不要混用(非必要不使用匈牙利命名法) |
|
|
|
|
|
|
|
+ 命名应当通俗易懂,让阅读代码者能够通过命名理解变量、函数等的意义。除循环变量等可以使用 `i`、`j`、`k` 等单字母外,其他的命名应当明白如话,且谨慎使用缩写。尽量使用众人皆知的缩写,不要自创缩写。如果连自己都不知道的缩写或根本没有众人皆知的缩写,则应当坚持使用全称,命名可以适当加长。 |
|
|
|
|
|
|
|
常用的缩写有: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
> address-addr、answer-ans、application-app、arguments-args、array-arr、assemble-asm、(a)synchronize-(a)sync、attribute-attr、begin-beg、bitmap-bmp、buffer-buf、button-btn、clock-clk、command-cmd、coordinates-coord、copy-cpy、count-cnt、current-cur、database-db、decrease-dec、default/define-def、delete-del、dependency-dep、destination-dest、device-dev、dialog-dlg、dictionary-dict、display-disp、divide-div、document-doc、educate-edu、equal-eq、error-err、extend-ext、format-fmt、frequency-freq、function-func、horizon-horz、image-img、implement-impl、increment-inc、index-idx、information-info、initialize-init、instance-inst、iterator-itr、length-len、list-lst、memory-mem、message-msg、middle-mid、number-num、object-obj、package-pkg、parameter-param、password-pwd、pointer-ptr、position-pos、previous-prev、receive-recv、reference-ref、resource/result-res、return-ret、second-sec、select-sel、semaphore-sem、signal-sig、source-src、stack-stk、standard-std、statistic/state-stat、string-str、system-sys、temporary-temp/tmp、text-txt、user-usr、value-val、variable-var、version-ver、vertical-vert、window-win |
|
|
|
> |
|
|
|
> |
|
|
|
|
|
|
|
- 命名允许较长,但不应过于啰嗦冗余,能完整表明意图即可。 |
|
|
|
- 代码应保证良好的可读性;**禁止**中学 OI 竞赛的各种“卡常”奇技淫巧!!!效率并非总是最重要的,良好的可读性与可维护性往往更加重要。 |
|
|
|
- 熟练运用面向对象编程的思想,设计架构时尽可能降低模块与模块的耦合性,保证代码的可维护性 |
|
|
|
- 慎用全局变量、全局函数等 |
|
|
|
- 尽可能将各功能模块化,便于日后复用;尽可能降低类与类的耦合,善用继承与多态 |
|
|
|
- 适当设计单元测试,保证代码的正确运行 |
|
|
|
|
|
|
|
- 注意跨平台问题,代码需保证同时支持 Windows 与 Linux,避免直接的系统调用带来的跨平台问题 |
|
|
|
- 注意维护开发文档,便于后来者快速了解本仓库代码结构 |
|
|
|
- 小组内合理分工,避免个人任务量过重或过轻 |
|
|
|
- 做好部会记录,及时完成工作任务,避免拖延到ddl |
|
|
|
- 各组间多交流,相互了解各自的开发进度,加强协作,遇到困难互相帮助。 |
|
|
|
- 加油,奥里给 |
|
|
|
|
|
|
|
## 开发组成员 |
|
|
|
|
|
|
|
- 逻辑组: |
|
|
|
- 通信组: |
|
|
|
- 界面组: |
|
|
|
- 赛事组: |
|
|
|
- 端茶倒水:唐昌礼 |