Merge pull request #258 from eesast/renovate/rebex.sftp-6.x chore(deps): update dependency rebex.sftp to v6.0.8558
Merge pull request #258 from eesast/renovate/rebex.sftp-6.x
chore(deps): update dependency rebex.sftp to v6.0.8558
THUAI5:清华大学第五届人工智能挑战赛电子系赛道(原电子系第二十三届队式程序设计大赛 teamstyle23)
Gitee 镜像仓库地址:https://gitee.com/eesast/THUAI5
GitLink 镜像仓库地址:https://www.gitlink.org.cn/EESAST/thuai5
项目主页:THUAI5 Project Home Page
更多内容参见 THUAI5 Github Wiki
比赛名称: 机算挑魁
赛题背景:
在展览会上,清华推出了全新的智能机器人,为了抢夺全新的算力资源,这些机器人蓄势待发,一场算力争夺的比赛就此打响。比赛中,“CPU工厂”将生产CPU,机器人来回巡视,拾取并安装CPU,提高自己的算力。看!机器人1号躲入了电磁屏蔽区,消失在了大家的视野中;机器人2号发射了信号干扰弹,对其他机器人产生了干扰……
比赛不断进行,机器人们也不断安装上CPU,它们的算力持续增加。诶?校科协的成员们带着自制的道具来了!他们在赛场上放置道具,给机器人们使用。什么?机器人3号电量不足,被迫离场充电。太可惜了,它的诸多零件都被机器人4号抢走了……
时间不断推移,比赛进入白热化阶段。各队机器人的算力不断增加着。谁能神机妙算,一战夺魁?让我们拭目以待!
比赛规则参见 game-rules
计划架构如下:
本仓库为所有开发工作共用仓库,请勿上传不必要的文件。本仓库采用 git 作为版本控制系统,每个子目录内均已经预先包含由 Visual Studio 2019 自动生成的 .gitignore,可以根据自身需要增加忽略规则。主目录内的 .gitignore 非必要尽量不要修改;为了防止行尾不一致的问题,主目录内已经配置了 .gitattributes 以进行行尾标准化,非必要也尽量不要修改,如果有必要可以在子目录内自定义 .gitattributes。
.gitignore
.gitattributes
详情参见各子目录内的 README,各个开发组成员请详细阅读自己所负责子目录内的 README,并推荐阅读所有子目录内的 README,便于了解整体的开发工作,互相交流合作。
使用 Git 与 GitHub 进行协作开发的过程中,各个开发组成员应当遵守下面的流程:
文件的字符编码格式须统一使用 UTF-8 编码,并用 4 空格缩进,尤其是 C/C++:Visual Studio 创建 cpp 文件时默认使用 GB2312 编码、TAB 缩进,因此每创建一个文件都需要注意手动设置字符编码(当代码文件中出现中文时)和缩进方式
使用等宽字体进行编程,例如 Source Code Pro、Consolas 等,便于对齐
注意代码的整洁性与可读性
代码风格尽量统一。书写不要过于紧凑,善于使用空格、缩进与换行来让代码看起来更整洁
命名风格尽量统一。相同类别的命名规则要相同,例如类名统一使用大驼峰命名法或其他常用的命名法,但是不要混用(非必要不要使用匈牙利命名法)
命名应当明白易懂。除循环变量等可以使用 i、j、k 等单字母外,其他的命名应当明白如话,且谨慎使用缩写。尽量使用众人皆知的缩写,不要自创缩写。如果连自己都不知道的缩写或根本没有众人皆知的缩写,则应当坚持使用全称,不要害怕变量名长。常用的缩写有:
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,避免直接的系统调用带来的跨平台问题
发布时请在 Release 模式下发布而不是 Debug,并且要确认代码在 Debug 和 Release 模式下均能正常构建并正确运行
适时维护开发文档等资料,便于后来维护者更快看懂代码
做好部会记录,及时记录饼和锅,以及赛题规则等,避免日后忘记
小组内进行合理的分工,尽量避免一个人工作过多或过少
多了解其他人的开发进度,增加互相之间的协作,遇到困难互相帮助,奥里给
Mirror of https://github.com/eesast/THUAI5.git
©Copyright 2023 CCF 开源发展委员会 Powered by Trustie& IntelliDE 京ICP备13000930号
THUAI5
THUAI5:清华大学第五届人工智能挑战赛电子系赛道(原电子系第二十三届队式程序设计大赛 teamstyle23)
Gitee 镜像仓库地址:https://gitee.com/eesast/THUAI5
GitLink 镜像仓库地址:https://www.gitlink.org.cn/EESAST/thuai5
项目主页:THUAI5 Project Home Page
更多内容参见 THUAI5 Github Wiki
赛题简介
比赛名称: 机算挑魁
赛题背景:
在展览会上,清华推出了全新的智能机器人,为了抢夺全新的算力资源,这些机器人蓄势待发,一场算力争夺的比赛就此打响。比赛中,“CPU工厂”将生产CPU,机器人来回巡视,拾取并安装CPU,提高自己的算力。看!机器人1号躲入了电磁屏蔽区,消失在了大家的视野中;机器人2号发射了信号干扰弹,对其他机器人产生了干扰……
比赛不断进行,机器人们也不断安装上CPU,它们的算力持续增加。诶?校科协的成员们带着自制的道具来了!他们在赛场上放置道具,给机器人们使用。什么?机器人3号电量不足,被迫离场充电。太可惜了,它的诸多零件都被机器人4号抢走了……
时间不断推移,比赛进入白热化阶段。各队机器人的算力不断增加着。谁能神机妙算,一战夺魁?让我们拭目以待!
比赛规则
比赛规则参见 game-rules
游戏主界面
软件架构
计划架构如下:
仓库说明
本仓库为所有开发工作共用仓库,请勿上传不必要的文件。本仓库采用 git 作为版本控制系统,每个子目录内均已经预先包含由 Visual Studio 2019 自动生成的
.gitignore
,可以根据自身需要增加忽略规则。主目录内的.gitignore
非必要尽量不要修改;为了防止行尾不一致的问题,主目录内已经配置了.gitattributes
以进行行尾标准化,非必要也尽量不要修改,如果有必要可以在子目录内自定义.gitattributes
。目录分配
详情参见各子目录内的 README,各个开发组成员请详细阅读自己所负责子目录内的 README,并推荐阅读所有子目录内的 README,便于了解整体的开发工作,互相交流合作。
分支
开发规则
关于社区开发者
使用 Git 与 Github 进行开发的流程
使用 Git 与 GitHub 进行协作开发的过程中,各个开发组成员应当遵守下面的流程:
使用 Git 与 Github 时的注意事项
统一约定
其他注意事项
文件的字符编码格式须统一使用 UTF-8 编码,并用 4 空格缩进,尤其是 C/C++:Visual Studio 创建 cpp 文件时默认使用 GB2312 编码、TAB 缩进,因此每创建一个文件都需要注意手动设置字符编码(当代码文件中出现中文时)和缩进方式
使用等宽字体进行编程,例如 Source Code Pro、Consolas 等,便于对齐
注意代码的整洁性与可读性
代码风格尽量统一。书写不要过于紧凑,善于使用空格、缩进与换行来让代码看起来更整洁
命名风格尽量统一。相同类别的命名规则要相同,例如类名统一使用大驼峰命名法或其他常用的命名法,但是不要混用(非必要不要使用匈牙利命名法)
命名应当明白易懂。除循环变量等可以使用
i
、j
、k
等单字母外,其他的命名应当明白如话,且谨慎使用缩写。尽量使用众人皆知的缩写,不要自创缩写。如果连自己都不知道的缩写或根本没有众人皆知的缩写,则应当坚持使用全称,不要害怕变量名长。常用的缩写有:当然命名也不能太过啰嗦,能完整表明意图即可,过于啰嗦的变量名也是不好的
代码应保证可读性,清楚易懂。严禁中学 OI 竞赛的各种“卡常”奇技淫巧!!!一来相信编译器优化能力比人肉优化好得多,二来运行时效率不总是最重要的,保证代码可读性与可维护性有时更加重要
注意代码的可维护性。面向对象编程时:
注意代码的复用性。将各部分模块化,便于以后的复用
注意跨平台的问题,尽量同时支持 windows 与 linux,避免直接的系统调用带来的跨平台问题
发布时请在 Release 模式下发布而不是 Debug,并且要确认代码在 Debug 和 Release 模式下均能正常构建并正确运行
适时维护开发文档等资料,便于后来维护者更快看懂代码
做好部会记录,及时记录饼和锅,以及赛题规则等,避免日后忘记
小组内进行合理的分工,尽量避免一个人工作过多或过少
多了解其他人的开发进度,增加互相之间的协作,遇到困难互相帮助,奥里给
开发组成员