本代码库描述了需要部署至 Arch OJ 的题目应遵守的规范、文件命名和目录结构。
- 作业描述
- 必须:截止时间,题目列表(包括:题目名、分数、难度、测评环境),提交依赖关系(涉及多文件时,描述每个题目依赖哪些类)
- 可选:其他补充说明
- 题目描述
- 必须:题目简述,输入输出格式,范例输入输出
- 可选:背景,示例代码,相关链接
- 测评文件
- 必须:所有题目的测评文件(IO:in/out对,JUnit5:测试类),所有题目的标准代码(部署测试用)
- 可选:生成脚本
- 使用 in/out 对,使用数字作为编号,从 1 开始。
- 针对每个测试用例,将输入写在
testcase_n.in
,输出写在testcase_n.out
。
注:当前服务器上的比较参数:
diff -Z -B
- 使用 JUnit 5,文件使用 UTF-8 编码。
- 涉及文件操作时,应使用相对路径,避免使用绝对路径,因为题目评判会在低权限的隔离环境中进行。
- 对于路径分隔符,应使用标准库的
File.separator
和File.pathSeparator
,避免使用硬编码,因为题目评判会在 Linux 环境下进行。 - 换行符请使用
System.lineSeparator()
,而不是硬编码的\n
,因为在 Windows, Linux, macOS 上这个值各不相同。 - 使用
*Test.java
或Test*.java
作为文件名。其他命名方式可能导致 JUnit 引擎无法正确识别。
- 考虑到 JUnit 5 在计时上的问题,对可能出现的运行时间较长的样例,请使用
assertTimeoutPreemptively
防止死循环。如果对时间限制有严格要求,可以考虑传统 I/O 测评方式。 - 请使用注解保证样例运行顺序,如
@TestMethodOrder(MethodOrderer.Alphanumeric.class)
。 - 使用反射检测对象/方法属性,而非基于行为的检测。
- 样例名和提示信息(如 assertMessage)应具有描述性,以便同学们自行修正错误。
- 使用
@BeforeAll
,@BeforeEach
等 setUp / tearDown 方法保证各测试样例之间的独立性。 - 避免使用
System.exit(int returnCode)
,这会导致 JUnit 随着 JVM 一起退出。
- 尽量使用 Markdown 编写文档以方便 OJ 使用。如遇 Markdown 无法处理的复杂布局,再使用 Word / Latex 等其他工具进行排版。
- 分发题目文档的原始文件,以避免 PDF 复制导致的问题。如无法做到,至少对描述输入/输出的样例部分,分发 txt / Markdown 等纯文字版本。
- 对英文题目文档进行审校,尽可能避免语法错误、描述模糊、歧义等问题。必要时,对可能导致理解困难的部分进行补充说明。
- 涉及空格
\
、换行符\n
、制表符\t
或其他「空白字符」之处,须明确说明其位置,避免同学们自行通过复制等方式猜测输出布局。
- 把 Word 复制到某个编辑器生成 Markdown 文件不是好文明。建议在出题初期就使用 Markdown。
- 建议使用 Typora,也可以使用其他带预览的功能的编辑器。
- 遵循 Markdown 的常见格式规范,如:标题层级、列表、代码(Code)、代码块(Fenced Code Block)等。
- 题目标题为 H1,内部各小段(背景、题目描述、输入输出格式、范例)使用 H2,视情况使用更低层级。
- 如果存在方法名、变量名等代码元素和正常文字混排,使用代码加以区分。
- 尽可能为代码块设定语言,以保证代码高亮的显示。
- 使用粗体表示需要强调的内容。
- 编写完成 Markdown 文档后,请进行预览,确认布局和格式正常。
- 如果需要附加图片,请先使用相对位置,将图片放置在文档所在的文件夹。我们会进行处理,保证图片在 OJ 上的正常显示。
见 example_data 目录。
- A+B (I/O):最简单的 IO 示例
- A+B With Adder (JUnit5):最简单的 JUnit 示例
- Flat Sub Matrix And Sort:JUnit 带数据文件示例
- Rectangle:JUnit 多个测试类示例