ArchOJ 出题规范

本代码库描述了需要部署至 Arch OJ 的题目应遵守的规范、文件命名和目录结构。

出题时需要提交的文件

1. 作业描述
   • 必须：截止时间，题目列表（包括：题目名、分数、难度、测评环境），提交依赖关系（涉及多文件时，描述每个题目依赖哪些类）
   • 可选：其他补充说明
2. 题目描述
   • 必须：题目简述，输入输出格式，范例输入输出
   • 可选：背景，示例代码，相关链接
3. 测评文件
   • 必须：所有题目的测评文件（IO：in/out对，JUnit5：测试类），所有题目的标准代码（部署测试用）
   • 可选：生成脚本

测试用例构建

传统 I/O

1. 使用 in/out 对，使用数字作为编号，从 1 开始。
2. 针对每个测试用例，将输入写在 testcase_n.in ，输出写在 testcase_n.out。

注：当前服务器上的比较参数：diff -Z -B

JUnit

1. 使用 JUnit 5，文件使用 UTF-8 编码。
2. 涉及文件操作时，应使用相对路径，避免使用绝对路径，因为题目评判会在低权限的隔离环境中进行。
3. 对于路径分隔符，应使用标准库的 File.separator 和 File.pathSeparator ，避免使用硬编码，因为题目评判会在 Linux 环境下进行。
4. 换行符请使用 System.lineSeparator() ，而不是硬编码的 \n ，因为在 Windows, Linux, macOS 上这个值各不相同。
5. 使用 *Test.java 或 Test*.java 作为文件名。其他命名方式可能导致 JUnit 引擎无法正确识别。

JUnit 补充说明

1. 考虑到 JUnit 5 在计时上的问题，对可能出现的运行时间较长的样例，请使用 assertTimeoutPreemptively 防止死循环。如果对时间限制有严格要求，可以考虑传统 I/O 测评方式。
2. 请使用注解保证样例运行顺序，如 @TestMethodOrder(MethodOrderer.Alphanumeric.class)。
3. 使用反射检测对象/方法属性，而非基于行为的检测。
4. 样例名和提示信息（如 assertMessage）应具有描述性，以便同学们自行修正错误。
5. 使用 @BeforeAll, @BeforeEach 等 setUp / tearDown 方法保证各测试样例之间的独立性。
6. 避免使用 System.exit(int returnCode)，这会导致 JUnit 随着 JVM 一起退出。

文档编写

1. 尽量使用 Markdown 编写文档以方便 OJ 使用。如遇 Markdown 无法处理的复杂布局，再使用 Word / Latex 等其他工具进行排版。
2. 分发题目文档的原始文件，以避免 PDF 复制导致的问题。如无法做到，至少对描述输入/输出的样例部分，分发 txt / Markdown 等纯文字版本。
3. 对英文题目文档进行审校，尽可能避免语法错误、描述模糊、歧义等问题。必要时，对可能导致理解困难的部分进行补充说明。
4. 涉及空格\ 、换行符\n、制表符\t或其他「空白字符」之处，须明确说明其位置，避免同学们自行通过复制等方式猜测输出布局。

Markdown 补充说明

1. 把 Word 复制到某个编辑器生成 Markdown 文件不是好文明。建议在出题初期就使用 Markdown。
2. 建议使用 Typora，也可以使用其他带预览的功能的编辑器。
3. 遵循 Markdown 的常见格式规范，如：标题层级、列表、代码（Code）、代码块（Fenced Code Block）等。
   1. 题目标题为 H1，内部各小段（背景、题目描述、输入输出格式、范例）使用 H2，视情况使用更低层级。
   2. 如果存在方法名、变量名等代码元素和正常文字混排，使用代码加以区分。
   3. 尽可能为代码块设定语言，以保证代码高亮的显示。
   4. 使用粗体表示需要强调的内容。
4. 编写完成 Markdown 文档后，请进行预览，确认布局和格式正常。
5. 如果需要附加图片，请先使用相对位置，将图片放置在文档所在的文件夹。我们会进行处理，保证图片在 OJ 上的正常显示。

示例题目和数据结构

见 example_data 目录。

1. A+B （I/O）：最简单的 IO 示例
2. A+B With Adder (JUnit5)：最简单的 JUnit 示例
3. Flat Sub Matrix And Sort：JUnit 带数据文件示例
4. Rectangle：JUnit 多个测试类示例