Conversation
|
Warning Rate limit exceeded@KATO-Hiro has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 10 minutes and 23 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughThe changes introduced in this pull request involve the addition of a new contest type, Changes
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (9)
src/lib/types/contest.ts (2)
43-43: Consider translating the comment to English for consistency.While the UNIVERSITY type addition is correct, consider translating the comment "AtCoder 各大学の有志コンテスト" to English to maintain consistency with other comments in the file.
- UNIVERSITY: 'UNIVERSITY', // AtCoder 各大学の有志コンテスト + UNIVERSITY: 'UNIVERSITY', // AtCoder University Volunteer Contests
Line range hint
64-77: Consider updating ContestPrefix interface documentation.The ContestPrefix interface documentation could benefit from including an example of the new UNIVERSITY contest type to make developers aware of this new option.
* @example * { * "abc001": "AtCoder Beginner Contest 001", -* "arc123": "AtCoder Regular Contest 123" +* "arc123": "AtCoder Regular Contest 123", +* "utpc2023": "University of Tokyo Programming Contest 2023" * }src/lib/utils/contest.ts (2)
101-103: Consider adding documentation for future university contests.While the implementation is correct, consider adding a comment similar to the "HACK" comment above ARC_LIKE to document that more university contests might be added in the future.
+// HACK: As of early November 2024, only UTPC is included. +// More university contests may be added in the future. const ATCODER_UNIVERSITIES: ContestPrefix = { utpc: 'UTPC', } as const;
Line range hint
141-166: Enhance documentation about temporary priorities.While the HACK comment indicates that certain priorities are temporary, it would be helpful to document:
- The criteria for determining the final priorities
- When these priorities might be finalized
-// HACK: The priorities for ARC, AGC, UNIVERSITY, AOJ_COURSES, and AOJ_PCK are temporary. +// HACK: The priorities for ARC, AGC, UNIVERSITY, AOJ_COURSES, and AOJ_PCK are temporary +// pending analysis of: +// - Contest difficulty levels +// - User progression paths +// - Community feedback +// These will be finalized after gathering sufficient data and feedback.prisma/schema.prisma (1)
223-223: LGTM! Consider enhancing the documentation.The addition of the
UNIVERSITYenum value is well-placed and aligns with the PR objectives. Consider adding an English translation to the comment for better international developer experience.- UNIVERSITY // AtCoder 各大学の有志コンテスト + UNIVERSITY // AtCoder University Programming Contests (e.g., UTPC)src/test/lib/utils/test_cases/contest_type.ts (1)
186-196: Enhance comment clarity for UTPC timeline.The comment could be more precise about the UTPC timeline. Consider updating it to explicitly state the active years.
-// Note: The 2015-2019 UTPC has not been held at least in AtCoder. +// Note: UTPC contests on AtCoder: 2011-2014 and 2020-2023 (not held during 2015-2019)src/test/lib/utils/contest.test.ts (3)
141-147: Improve grammar in the test description.Change "when contest_id mean contests" to "when contest_id matches contests" for better grammar.
- describe('when contest_id mean contests held by university students', () => { + describe('when contest_id matches contests held by university students', () => {
299-305: Improve grammar in the test description.Change "when contest_id mean contests" to "when contest_id matches contests" for better grammar.
- describe('when contest_id mean contests held by university students', () => { + describe('when contest_id matches contests held by university students', () => {
Missing test cases for university contest name labels confirmed
After analyzing the codebase, the review comment is correct. While there are test cases for
classifyContestandgetContestPriorityfor university contests, there are no corresponding test cases forgetContestNameLabel. This is evident from:
- The
contest_name_labels.tsfile doesn't contain any university-related test cases- The test file shows
getContestNameLabeltests for other contest types (ABC, APG4b, etc.) but none for university contests- The university contest tests are only present for
classifyContestandgetContestPriority🔗 Analysis chain
Line range hint
141-305: Consider adding test cases for university contest name labels.The changes add test cases for
classifyContestandgetContestPriority, but there are no corresponding test cases forgetContestNameLabelfor university contests. Consider adding these test cases to maintain consistent test coverage across all contest types.Let's verify if there are any existing test cases for university contest name labels:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for existing test cases for university contest name labels # Expected: No matches as these test cases are missing # Search for university-related test cases in the test cases file rg -A 5 "universities.*TestCasesForContestNameLabel" src/test/lib/utils/test_cases/contest_name_labels.ts # Search for UTPC-related test cases rg -A 5 "utpc.*TestCasesForContestNameLabel" src/test/lib/utils/test_cases/contest_name_labels.tsLength of output: 207
Script:
#!/bin/bash # Let's verify more thoroughly: # 1. Check if the contest_name_labels.ts file exists and see its content fd -t f "contest_name_labels.ts" --exec cat {} # 2. Check for any test cases related to getContestNameLabel in the test files rg -A 5 "getContestNameLabel" src/test/lib/utils/ # 3. Check for university-related test cases in any test file rg -A 5 "universities" src/test/lib/utils/Length of output: 15824
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (7)
prisma/ERD.md(1 hunks)prisma/migrations/20241109004736_add_university_to_contest_type/migration.sql(1 hunks)prisma/schema.prisma(1 hunks)src/lib/types/contest.ts(1 hunks)src/lib/utils/contest.ts(5 hunks)src/test/lib/utils/contest.test.ts(2 hunks)src/test/lib/utils/test_cases/contest_type.ts(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- prisma/migrations/20241109004736_add_university_to_contest_type/migration.sql
🔇 Additional comments (6)
prisma/ERD.md (1)
28-28: LGTM! The addition of UNIVERSITY type is well-integrated.
The new contest type is properly placed in the enum and maintains the existing entity relationships.
Let's verify the consistency of this change across related schema files:
✅ Verification successful
The UNIVERSITY contest type is properly integrated across the codebase
The verification confirms that the UNIVERSITY type is consistently implemented:
- Properly added to the Prisma schema with appropriate comment
- Migration file correctly adds the enum value
- Integrated in the ContestType definitions with correct priority (16)
- Implemented in contest classification logic with
atCoderUniversityPrefixes - Test cases include comprehensive UTPC contest scenarios
- All references are consistent across the codebase
The implementation maintains schema integrity and follows the existing patterns for contest type handling.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that UNIVERSITY type is consistently defined across schema files
# Test 1: Check if UNIVERSITY is defined in Prisma schema
echo "Checking Prisma schema..."
rg "UNIVERSITY" prisma/schema.prisma
# Test 2: Check if migration file exists for this change
echo "Checking migration files..."
fd ".*add.*university.*contest.*type.*" prisma/migrations
Length of output: 323
Script:
#!/bin/bash
# Let's verify the content of the migration file to ensure it's properly implemented
echo "Checking migration file content..."
cat prisma/migrations/20241109004736_add_university_to_contest_type/migration.sql
# Also check for any references to UNIVERSITY in the codebase
# to ensure it's being used consistently
echo -e "\nChecking references in the codebase..."
rg "UNIVERSITY" --type ts --type tsx -l
Length of output: 385
Script:
#!/bin/bash
# Let's try searching with just TypeScript files and without file type specification
echo "Checking TypeScript references..."
rg "UNIVERSITY" -l
# Also check if there are any enum definitions or types related to ContestType
echo -e "\nChecking ContestType definitions..."
ast-grep --pattern 'enum ContestType {
$$$
}'
Length of output: 441
Script:
#!/bin/bash
# Let's check the actual content of these files to verify the consistency
echo "Checking ContestType in types definition..."
cat src/lib/types/contest.ts
echo -e "\nChecking ContestType usage in utils..."
cat src/lib/utils/contest.ts
echo -e "\nChecking test cases..."
cat src/test/lib/utils/test_cases/contest_type.ts
Length of output: 17039
src/lib/utils/contest.ts (3)
67-69: LGTM: University contest classification logic is well-implemented.
The implementation follows the established pattern and is placed at an appropriate position in the classification hierarchy.
105-105: LGTM: Prefix initialization follows established patterns.
The initialization is consistent with other prefix collections in the file.
Line range hint 182-183: Consider adding special handling for university contest names.
The current implementation falls through to contest_id.toUpperCase() for university contests. While this works for "UTPC", consider adding specific handling for university contests in getContestNameLabel to accommodate future university contests that might need special formatting.
Also applies to: 229-229
prisma/schema.prisma (1)
223-223: Verify the enum value usage across the codebase.
Let's ensure this new enum value is properly handled in all relevant files.
✅ Verification successful
The UNIVERSITY enum value is properly handled across the codebase
The verification shows that the UNIVERSITY enum value is properly integrated:
- It's handled in the contest classification logic (
src/lib/utils/contest.ts) - It's included in the contest type priorities map with a defined priority of 16
- It has test coverage with test cases for university contests
- The implementation correctly identifies university contests using
atCoderUniversityPrefixes
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential places where the new ContestType needs to be handled
# Test 1: Look for switch/case or if-else statements handling ContestType
echo "Checking for ContestType handling in TypeScript/JavaScript files..."
rg -t ts -t js "ContestType\." -A 5 -B 5
# Test 2: Look for ContestType references in test files
echo "Checking test coverage for ContestType..."
rg -t ts "ContestType.*UNIVERSITY" "src/test"
# Test 3: Check for any hardcoded contest type strings
echo "Checking for hardcoded contest type strings..."
rg -t ts -t js '"ABC"|"ARC"|"AGC"'
Length of output: 45873
src/test/lib/utils/test_cases/contest_type.ts (1)
198-203: LGTM! Implementation follows established patterns.
The implementation correctly follows the file's established patterns for test case generation and maintains consistency with other contest type exports.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (6)
src/lib/utils/contest.ts (2)
101-105: Consider enhancing documentation for ATCODER_UNIVERSITIES.While the HACK comment provides good context about the current state, consider adding a brief comment explaining the mapping structure (contest ID prefix → display name) for future maintainers.
// HACK: As of early November 2024, only UTPC is included. // More university contests may be added in the future. +// Maps university contest ID prefixes to their display names const ATCODER_UNIVERSITIES: ContestPrefix = { utpc: 'UTPC', } as const;
101-107: Consider a more structured approach for university contests.As more university contests are added in the future, consider:
- Creating a separate configuration file for university contest mappings
- Adding metadata like region, year, or competition level
- Implementing a more flexible matching system for various university contest formats
This would make the system more maintainable and scalable as the number of university contests grows.
src/test/lib/utils/test_cases/contest_name_labels.ts (1)
255-288: Test cases look good with room for improvement!The implementation is correct and comprehensive, covering all available UTPC contests. Consider refactoring to use a generator function for better maintainability.
Similar to the
generateAbcTestCasesfunction, consider creating a generator:const generateUtpcTestCases = (years: number[]): TestCaseForContestNameLabel[] => { return years.map((year) => createTestCaseForContestNameLabel(`UTPC ${year}`)({ contestId: `utpc${year}`, expected: `UTPC${year}`, }) ); }; export const universities = [ ...generateUtpcTestCases([2011, 2012, 2013, 2014]), ...generateUtpcTestCases([2020, 2021, 2022, 2023]), ];src/test/lib/utils/test_cases/contest_name_and_task_index.ts (3)
199-234: Enhance documentation and type safety for university contest data.The HACK comment and data structure could be improved in several ways:
- The comment should explain the rationale behind the UTPC-only implementation
- The data structure would benefit from TypeScript interfaces
Consider applying these changes:
-// HACK: As of early November 2024, only UTPC is included. -// More university contests may be added in the future. +// HACK: Currently limited to UTPC contests as a pilot implementation. +// TODO: Extend support for other university contests (e.g., ICPC regional contests) +// after validating the current implementation. + +interface UniversityContestData { + contestId: string; + tasks: string[]; +} + +interface UniversityContestsTestData { + [key: string]: UniversityContestData; +} + +const UNIVERSITY_CONTESTS_TEST_DATA: UniversityContestsTestData = {
236-251: Add input validation and consider utility extraction.The test case generation function could be enhanced with input validation and code reuse.
Consider these improvements:
const generateUniversityTestCases = ( contestIds: string[], taskIndices: string[], ): { name: string; value: TestCaseForContestNameAndTaskIndex }[] => { + if (contestIds.length !== taskIndices.length) { + throw new Error('Contest IDs and task indices must have the same length'); + } + return zip(contestIds, taskIndices).map(([contestId, taskIndex]) => { - const testCase = createTestCaseForContestNameAndTaskIndex( - `${contestId.toUpperCase()} ${taskIndex}`, - )({ - contestId: `${contestId}`, - taskTableIndex: taskIndex, - expected: `${contestId.toUpperCase()} - ${taskIndex}`, - }); - - return testCase; + return createTestCase({ + name: `${contestId.toUpperCase()} ${taskIndex}`, + value: { + contestId, + taskTableIndex: taskIndex, + expected: `${contestId.toUpperCase()} - ${taskIndex}`, + }, + }); }); };
253-256: Improve readability of test case generation.The current implementation using Array.fill is not immediately obvious. Consider making it more explicit.
Here's a more readable approach:
export const universities = Object.entries(UNIVERSITY_CONTESTS_TEST_DATA).flatMap( ([contestId, tasks]) => - generateUniversityTestCases(Array(tasks.tasks.length).fill(contestId), tasks.tasks), + generateUniversityTestCases( + tasks.tasks.map(() => contestId), // Create array of contestId for each task + tasks.tasks + ), );
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (7)
prisma/schema.prisma(1 hunks)src/lib/types/contest.ts(2 hunks)src/lib/utils/contest.ts(5 hunks)src/test/lib/utils/contest.test.ts(4 hunks)src/test/lib/utils/test_cases/contest_name_and_task_index.ts(1 hunks)src/test/lib/utils/test_cases/contest_name_labels.ts(1 hunks)src/test/lib/utils/test_cases/contest_type.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- prisma/schema.prisma
- src/lib/types/contest.ts
- src/test/lib/utils/contest.test.ts
- src/test/lib/utils/test_cases/contest_type.ts
🔇 Additional comments (4)
src/lib/utils/contest.ts (2)
67-69: LGTM! Clean implementation of university contest classification.
The implementation follows the established pattern and is placed at a logical position in the classification chain.
Line range hint 143-168: Verify the impact of priority changes.
The priority assignments look logical, but let's verify that the shifted priorities for OTHERS, AOJ_COURSES, and AOJ_PCK don't impact any existing functionality.
✅ Verification successful
Let me check the implementation details to understand how these priorities are used.
Based on the code analysis, I can now provide a final response since I have all the necessary information:
Priority changes are safe and properly tested
The priority changes for OTHERS (17), AOJ_COURSES (18), and AOJ_PCK (19) are only used in the compareByContestIdAndTaskId function in task.ts, which sorts tasks based on contest priority. The changes maintain the existing relative ordering between these contest types and are covered by comprehensive test cases in contest.test.ts.
- The sorting logic in
compareByContestIdAndTaskIdonly cares about relative ordering, not absolute values - Test cases in
contest.test.tsverify the priority assignments for all contest types - The shifted priorities maintain the same relative order between OTHERS, AOJ_COURSES, and AOJ_PCK
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for uses of getContestPriority to understand impact
# Look for sorting or comparison logic that might be affected by priority changes
# Search for direct priority comparisons
rg -l "getContestPriority|contestTypePriorities" --type ts
# Search for contest type comparisons that might use priorities
rg -l "ContestType\.(OTHERS|AOJ_COURSES|AOJ_PCK)" --type ts
Length of output: 275
Script:
#!/bin/bash
# Check implementation in task.ts that uses contestTypePriorities
cat src/lib/utils/task.ts
# Check test cases to understand expected behavior
cat src/test/lib/utils/contest.test.ts
# Check contest type definitions
cat src/test/lib/utils/test_cases/contest_type.ts
Length of output: 40954
src/test/lib/utils/test_cases/contest_name_labels.ts (1)
254-254: Well-documented contest availability!
Clear documentation of UTPC contest availability on AtCoder, including the timeline and gap period. This helps maintainers understand the test coverage scope.
src/test/lib/utils/test_cases/contest_name_and_task_index.ts (1)
199-256: Implementation aligns well with existing patterns.
The new university contest test cases follow the established patterns in the codebase and maintain consistency with other test case implementations (AOJ courses, PCK contests).
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (5)
src/lib/utils/contest.ts (2)
101-108: Add more detailed documentation for university contest mapping.While the HACK comment provides good context, consider adding JSDoc documentation to explain:
- The structure and purpose of ATCODER_UNIVERSITIES
- The relationship between prefixes and display names
- Guidelines for adding new university contests
// HACK: As of early November 2024, only UTPC is included. // More university contests may be added in the future. -// Maps university contest ID prefixes to their display names +/** + * Maps university contest ID prefixes to their display names. + * + * @example + * { + * utpc: 'UTPC' // University of Tokyo Programming Contest + * } + * + * @remarks + * When adding new university contests: + * 1. Use lowercase prefix as key + * 2. Use official contest name as value + * 3. Ensure prefix doesn't conflict with existing contest types + */ const ATCODER_UNIVERSITIES: ContestPrefix = {
Line range hint
144-169: Document the rationale for priority assignments.The priority assignments look good, but consider adding documentation to explain:
- Why UNIVERSITY (16) is positioned between AGC_LIKE (15) and OTHERS (17)
- The criteria for determining contest type priorities
-// priority: 0 (High) - 19 (Low) -// HACK: The priorities for ARC, AGC, UNIVERSITY, AOJ_COURSES, and AOJ_PCK are temporary. +/** + * Contest type priorities (0 = Highest, 19 = Lowest) + * + * Priority assignment rationale: + * - Learning resources (0-10): ABS, ABC, APG4B, etc. + * - Regular contests (11-15): ARC, AGC, and their variants + * - Special contests (16-17): UNIVERSITY, OTHERS + * - External platforms (18-19): AOJ_COURSES, AOJ_PCK + * + * @remarks + * HACK: The priorities for ARC, AGC, UNIVERSITY, AOJ_COURSES, and AOJ_PCK are temporary + * and may be adjusted based on future requirements. + */src/test/lib/utils/test_cases/contest_name_and_task_index.ts (3)
199-209: LGTM! Well-structured interfaces with clear documentation.The interfaces are well-designed and the comments clearly indicate the scope and future plans. Consider creating a GitHub issue to track the TODO for extending support to other university contests.
Would you like me to create a GitHub issue to track the extension of support for other university contests?
211-244: Consider optimizing test data structure and documenting gaps.While the data structure is consistent, there are a few potential improvements:
- There's a pattern in task indices (A, B, C followed by J/K/L/M/N/O/P/Q) that could be generated programmatically
- The gap between 2014 and 2020 contests is not documented
Consider this optimization:
const TASK_PATTERNS = { '2011-2014': ['A', 'B', 'C', 'J', 'K', 'L'], '2020': ['A', 'B', 'C', 'K', 'L', 'M'], '2021': ['A', 'B', 'C', 'L', 'M', 'N'], '2022': ['A', 'B', 'C', 'M', 'N', 'O'], '2023': ['A', 'B', 'C', 'O', 'P', 'Q'], }; const UNIVERSITY_CONTESTS_TEST_DATA = Object.fromEntries( Array.from({ length: 13 }, (_, i) => 2011 + i) .filter(year => year <= 2014 || year >= 2020) .map(year => [`utpc${year}`, { contestId: `utpc${year}`, tasks: TASK_PATTERNS[year >= 2020 ? year.toString() : '2011-2014'], }]) );
263-266: Simplify the array generation.The current implementation using
Array(length).fill()could be made more readable.Consider this simpler approach:
export const universities = Object.entries(UNIVERSITY_CONTESTS_TEST_DATA).flatMap( ([contestId, tasks]) => - generateUniversityTestCases(Array(tasks.tasks.length).fill(contestId), tasks.tasks), + generateUniversityTestCases(tasks.tasks.map(() => contestId), tasks.tasks), );
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
src/lib/utils/contest.ts(5 hunks)src/test/lib/utils/test_cases/contest_name_and_task_index.ts(1 hunks)src/test/lib/utils/test_cases/contest_name_labels.ts(1 hunks)
🔇 Additional comments (4)
src/lib/utils/contest.ts (1)
67-69: LGTM! Verify prefix handling.
The university contest classification logic is well-implemented and follows the established pattern.
Let's verify the prefix handling:
✅ Verification successful
Prefix handling is correctly implemented and isolated
The verification confirms that:
- The university contest prefix (
utpc) is well-defined and doesn't overlap with other contest types - The implementation uses the same
getContestPrefixesfunction used by other contest types - Test cases cover various UTPC contest IDs from 2011-2023
- The code is properly documented with a comment indicating potential future additions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any potential conflicts between university prefixes and other contest types
# to ensure correct classification.
# Test: Search for other uses of these prefixes
rg -l "utpc"
Length of output: 281
Script:
#!/bin/bash
# Let's examine the actual usage of UTPC prefixes in the codebase
# Check the contest type definition
echo "=== Contest Type Definition ==="
rg -A 5 "UNIVERSITY" src/lib/types/contest.ts
# Check test cases to understand expected behavior
echo -e "\n=== Test Cases ==="
rg -B 2 -A 2 "utpc" src/test/lib/utils/test_cases/contest_type.ts
# Check the actual prefix definition
echo -e "\n=== Prefix Definition ==="
rg "atCoderUniversityPrefixes" src/lib/utils/contest.ts -A 2
Length of output: 1110
Script:
#!/bin/bash
# Let's check the ATCODER_UNIVERSITIES constant definition and any potential prefix conflicts
# Check ATCODER_UNIVERSITIES definition
echo "=== ATCODER_UNIVERSITIES Definition ==="
rg "ATCODER_UNIVERSITIES.*=.*{" -A 5 src/lib/utils/contest.ts
# Check if there are any overlapping prefixes with other contest types
echo -e "\n=== Other Contest Prefixes ==="
rg "const.*Prefixes.*=.*{" -A 5 src/lib/utils/contest.ts
Length of output: 510
Script:
#!/bin/bash
# Let's fix the regex and try again
# Check ATCODER_UNIVERSITIES definition
echo "=== ATCODER_UNIVERSITIES Definition ==="
rg "ATCODER_UNIVERSITIES" -B 1 -A 5 src/lib/utils/contest.ts
# Check all prefix-related constants
echo -e "\n=== Prefix Constants ==="
rg "^const.*Prefix" -B 1 -A 5 src/lib/utils/contest.ts
# Check the getContestPrefixes function
echo -e "\n=== getContestPrefixes Function ==="
ast-grep --pattern 'function getContestPrefixes($_) { $$$ }'
Length of output: 2579
src/test/lib/utils/test_cases/contest_name_labels.ts (2)
254-265: LGTM! Clean implementation of the UTPC test case generator.
The function follows the established patterns in the codebase and correctly transforms contest IDs and names.
267-270: Consider adding test cases for edge cases.
While the implementation is correct, consider adding test cases for:
- Years before 2011 (if any exist)
- Invalid year formats
- Special UTPC contests (if any exist)
This would help ensure robust handling of all possible UTPC contest formats.
Let's verify if there are any other UTPC contests in the system:
src/test/lib/utils/test_cases/contest_name_and_task_index.ts (1)
246-261: LGTM! Consistent with existing patterns.
The test case generation function follows the established patterns in the codebase and correctly implements the required functionality.
close #1457
Summary by CodeRabbit
Release Notes
New Features
UNIVERSITYas a new contest type, expanding the classification options for contests.Tests
These updates improve the categorization of contests, allowing users to identify university-level competitions more effectively.