Skip to content

Latest commit

 

History

History
66 lines (55 loc) · 3.77 KB

File metadata and controls

66 lines (55 loc) · 3.77 KB

AGENTS.md

이 저장소는 competitive programming 참고 라이브러리입니다 (ICPC, CF, BOJ 등). 여기에 코드를 추가하거나 수정할 때는, 대회에서의 사용성을 최우선으로 최적화하세요.

핵심 목표

  • 빠르게 타이핑하고 붙여넣기: 짧은 코드 길이. 실용적인 API와 파일 구조.
  • 빠르고 메모리 효율적: 검증된 시간 복잡도, 낮은 상수, 최소한의 할당.
  • 압박 속에서도 읽기 쉬움: 단순한 제어 흐름, 명확한 불변식, 친절한 주석.
  • 템플릿 친화적: 최소한의 수정으로 다양한 변형 문제들에 적용 가능.

코드 스타일 및 규칙

Naming

  • 상수 (예: constexpr, 전역 const, 고정 파라미터): UPPER_SNAKE_CASE.
    • 예시: constexpr int MOD = 1e9 + 7;, const int INF = 1e9;
  • 그 외 모든 식별자소문자 snake_case 사용 (STL 스타일):
    • struct, class, namespace, function, variable
    • 예시: struct fenwick_tree, solve_case, add_edge
  • 간결하지만 설명적: 이름은 최대 12자 이내로 짧아야 함. 동시에 압박 속에서도 읽을 수 있을 정도로 명확해야 함.
    • Good: cnt, idx, res, nxt, vis, dist.
    • Bad: number_of_elements, adjacency_list, calculated_distance.

Types, Macros

  • 오버플로 디버깅을 줄이기 위해 기본적으로 ll을 선호. int는 명확히 안전하고 이점이 있을 때만 사용 (메모리, bitset 인덱싱, 배열 인덱스, 빡센 제약 등).
  • 코드 길이, 타이핑을 줄이기 위해 common.hpp의 alias (예: pll, all(x))를 항상 사용.

기타

  • 무거운 추상화보다 직관적인 구현을 선호.
  • 불필요한 동적 다형성, 복잡한 메타프로그래밍, 과도하게 공학적인 설계를 피하기.
  • ICPC 팀 노트에는 길이 제한이 있음. 코드는 가능한 한 짧고 간결하게 작성.
  • 커스텀 namespace를 사용하지 말고, struct로 대체할 것.
  • 코드 라인 수를 적극적으로 줄일 것. 불필요한 줄바꿈을 피하고, 가능하면 한 줄에 많은 코드를 작성할 것.

주석과 문서화

일관된 형식으로 친절하고 신호가 높은 문서를 작성. 특히, 난이도가 높은 알고리즘/자료구조일수록 자세하게 설명.

모듈 헤더 (재사용 가능한 각 컴포넌트마다)

상단 근처에 헤더 주석을 추가:

  • what: 구현체애 대한 설명. 단순히 알고리즘/자료구조의 이름을 적는 것이 아닌, 해당 구현체가 사용되는 context, 해결할 수 있는 문제를 black box로 작성.
  • time: 시간복잡도; memory: 공간복잡도
  • constraint: 구현 세부사항, 코드에 내재된 가정, 주의사항 등.
  • usage: 사용 예시 코드

인라인 주석 (코드 전반)

짧고 일관된 주석을 넉넉하게 달기:

  • 출력 (// result: ... = 주요 함수 반환값의 의미)
  • 의도 (// goal: ...)
  • 불변식 (// invariant: ... = 루프/알고리즘 전반에서 항상 참이어야 함)
  • 엣지 케이스 (// edge: ...)
  • 까다로운 추론 (// why: ...)

Formatting

변경 후에는 항상 실행:

  • scripts/format.sh

테스트

  • 템플릿 파일과 1:1 대응되는 테스트 파일을 둔다.
    • 예: src/1-ds/erasable_pq.cpp -> tests/1-ds/test_erasable_pq.cpp
    • 파일명 규칙: test_{*}.cpp
  • 테스트는 단일 실행 파일로 작성하고 외부 프레임워크 없이 assert/직접 비교를 사용.
  • src/* 내 코드는 절대로 틀려서는 안됨. 철저히 버그를 잡아낼 수 있도록 특별히 주의를 기울여 robust한 테스트 코드를 작성.
  • 랜덤 + 나이브 비교, 엣지 케이스는 반드시 포함.
  • 랜덤은 재현 가능하도록 고정 seed 사용.
  • 실행은 scripts/test.sh로 일괄.