[Rejected] PEP 350 - Codetags

원문 링크: PEP 350 - Codetags

상태: Rejected 유형: Informational 작성일: 27-Jun-2005

PEP 350 – 코드태그 (Codetags)

거부 공지

이 PEP는 거부되었습니다. 커뮤니티가 이 제안에 관심을 가질 수는 있지만, 표준 라이브러리가 이 표준을 따르도록 만들려는 의도는 없습니다.

개요

이 정보성(Informational) PEP는 코드태그(codetags)의 일관된 사용을 위한 가이드라인을 제공하는 것을 목표로 합니다. 코드태그는 표준 유틸리티가 코드태그 정보를 활용할 수 있도록 하고, 프로젝트 전반에 걸쳐 Python 코드를 더욱 균일하게 만듭니다. 또한 코드태그는 매우 가벼운 프로그래밍 마이크로 패러다임을 나타내며 프로젝트 관리, 문서화, 변경 추적 및 프로젝트 상태 모니터링에 유용합니다. 이러한 아이디어가 Pythonic하다고 여겨지기 때문에 PEP로 제출되었지만, 이 개념은 Python 프로그래밍에만 국한되지 않습니다. 이 문서에는 코드태그의 정의, 그 이면에 있는 철학, 표준화된 규칙의 동기, 몇 가지 예시, 사양, 도구 세트 설명 및 코드태그 프로젝트/패러다임에 대한 가능한 반론이 포함되어 있습니다.

이 PEP는 사람들이 의견을 추가할 수 있는 위키로도 운영되고 있습니다.

코드태그란 무엇인가요?

프로그래머들은 더 면밀한 검토나 검사가 필요한 코드 섹션을 상기시키기 위해 임시적인 코드 주석 마크업 규칙을 널리 사용합니다. 마크업의 예로는 FIXME, TODO, XXX, BUG 등이 있지만, 기존 소프트웨어에서 널리 사용되는 다른 많은 것들이 있습니다. 이러한 마크업은 앞으로 코드태그(codetags)라고 불릴 것입니다. 이 코드태그는 애플리케이션 코드, 유닛 테스트(unit tests), 스크립트, 일반 문서 또는 적합한 모든 곳에 나타날 수 있습니다.

코드태그는 수년 동안 여러 곳(예: c2)에서 논의되고 사용되어 왔습니다(Python 2.4 소스에는 수백 개의 코드태그가 있습니다). 추가적인 역사적 및 현재 정보는 “참고 자료(References)”를 참조하십시오.

철학

이러한 가치들 대부분에 동의한다면, 코드태그는 여러분에게 유용할 것입니다.

  • 가능한 한 많은 정보가 소스 코드(애플리케이션 코드 또는 유닛 테스트) 내에 포함되어야 합니다. 이는 코드태그 사용과 함께 중복을 방지합니다. 대부분의 문서는 해당 소스 코드에서 생성될 수 있습니다. 예를 들어, help2man, man2html, docutils, epydoc/pydoc, ctdoc 등을 사용해서 말입니다. 정보는 거의 중복되어서는 안 됩니다. 단일 원본 형식으로 기록되어야 하며, 다른 모든 위치는 원본에서 자동으로 생성되거나 단순히 참조되어야 합니다. 이것은 유명한 단일 진실 공급원(Single Point Of Truth, SPOT) 또는 반복하지 마세요(Don’t Repeat Yourself, DRY) 규칙으로 알려져 있습니다.
  • 고객에게 전달되는 문서는 단일 소스에서 모든 다른 출력 형식으로 자동 생성되어야 합니다. 사람들은 다양한 형태의 문서를 원합니다. 따라서 이 모든 것을 생성할 수 있는 문서 시스템을 갖는 것이 중요합니다.
  • 개발자가 문서화 팀입니다. 그들은 코드를 작성하고 코드를 가장 잘 알아야 합니다. 매우 큰 프로젝트가 아닌 이상, 전담적이고 분리된 문서화 팀은 없어야 합니다.
  • 평문(비침습적 마크업 사용)이 무엇이든 작성하는 데 가장 좋은 형식입니다. 다른 모든 형식은 평문에서 생성되어야 합니다.

코드태그 설계는 다음 목표들의 영향을 받았습니다.

  • 주석은 가능한 한 짧아야 합니다.
  • 코드태그 필드는 선택 사항이며 최소한의 길이를 가져야 합니다.
  • 기본값과 사용자 정의 필드는 개별 코드 작업장에서 설정할 수 있습니다.
  • 코드태그는 미니멀리스트여야 합니다. 무언가를 기록하는 것이 빠를수록 기록될 가능성이 높아집니다. 코드태그의 가장 일반적인 사용은 0개에서 2개의 필드만 지정하는 것이며, 이들은 가장 쉽게 입력하고 읽을 수 있어야 합니다.

동기

코드태그를 중심으로 다양한 생산성 도구를 구축할 수 있습니다. “도구(Tools)” 섹션을 참조하십시오.

  • 일관성 장려: 역사적으로, 이러한 코드태그의 하위 집합은 Python이든 다른 언어이든 존재하는 대부분의 소스 코드에서 비공식적으로 사용되었습니다. 태그는 다른 철자, 의미, 형식 및 배치로 일관성 없는 방식으로 사용되었습니다. 예를 들어, 일부 프로그래머는 날짜 스탬프 및/또는 사용자 식별자를 포함하거나, 단일 라인으로 제한하거나, 다른 사람들과 다른 방식으로 코드태그를 철자화할 수 있습니다.
  • SPOT/DRY 원칙 준수 장려: 예를 들어, 별도의 로드맵 문서와 TODO 목록을 동기화하는 대신 코드태그에서 동적으로 로드맵을 생성하는 것입니다.
  • 기억하기 쉬움: 모든 코드태그는 간결하고 직관적이며 다른 것들과 의미적으로 겹치지 않아야 합니다. 형식 또한 단순해야 합니다.
  • 사용이 요구/강요되지 않음: 이미 코드태그를 사용하지 않는 경우, 시작할 의무가 없으며 코드에 영향을 미칠 위험도 없습니다(그러나 “반론(Objections)”을 참조하십시오). 작은 하위 집합을 채택할 수 있으며 도구는 여전히 유용할 것입니다(몇몇 코드태그는 어쨌든 이미 임시적으로 채택되었을 것입니다). 또한 더 이상 유용하지 않다고 판단되는 코드태그를 식별하고 제거하는(그리고 possibly 기록하는) 것은 매우 쉽습니다.
  • 코드에 대한 전역적인 관점 제공: 도구를 사용하여 문서와 보고서를 생성할 수 있습니다.
  • CRC/스토리/요구사항을 캡처하기 위한 논리적 위치: XP 커뮤니티는 종종 스토리를 전자적으로 캡처하지 않지만, 코드태그는 스토리를 배치하기에 좋은 장소처럼 보입니다.
  • 극도로 가벼운 프로세스: 모든 생각에 대해 추적 시스템에 티켓을 생성하는 것은 개발 속도를 저하시킵니다. 티켓 시스템이 사용되더라도 코드태그는 해당 티켓에 대한 링크를 포함하는 데 유용합니다.

예시

다음은 흔히 볼 수 있는 간단한 코드태그의 예시입니다(끝에 <>가 추가됨).

# FIXME: Seems like this loop should be finite. <>
while True:
    ...

다음 조작된 예시는 코드태그의 전형적인 사용법을 보여줍니다. 이는 사용 가능한 필드 중 일부를 사용하여 담당자(MDE 및 CLE 이니셜을 가진 두 명의 프로그래머), 예상 완료 날짜(14주), 그리고 항목의 우선순위(2)를 지정합니다.

# FIXME: Seems like this loop should be finite. <MDE,CLE d:14w p:2>
while True:
    ...

이 코드태그는 작성자, 발견(기원) 날짜, 기한, 우선순위를 설명하는 필드를 가진 버그를 보여줍니다.

# BUG: Crashes if run on Sundays.
# <MDE 2005-09-04 d:14w p:2>
if day == 'Sunday':
    ...

다음은 코드태그를 잘못 사용하는 방법을 보여주는 예시입니다. 이것은 여러 가지 문제가 있습니다.

  1. 코드태그는 코드와 한 줄을 공유할 수 없습니다.
  2. 니모닉(mnemonic) 뒤에 콜론이 누락되었습니다.
  3. 코드태그를 참조하는 코드태그는 일반적으로 쓸모가 없으며, 더 나아가 완료될 수 없습니다.
  4. 사소한 코드태그에 대해 많은 필드를 가질 필요가 없습니다.
  5. 알 수 없는 값( t:XXX )을 가진 필드는 사용되어서는 안 됩니다.
i = i + 1 # TODO Add some more codetags.
# <JRNewbie 2005-04-03 d:2005-09-03 t:XXX d:14w p:0 s:inprogress>

사양 (Specification)

이 섹션은 형식: 구문, 니모닉 이름, 필드 및 의미론, 그리고 별도의 DONE 파일을 설명합니다.

일반 구문 (General Syntax)

각 코드태그는 주석 내에 있어야 하며, 여러 줄일 수 있습니다. 코드와 한 줄을 공유해서는 안 됩니다. 주변 코드의 들여쓰기와 일치해야 합니다. 코드태그의 끝은 선택적 필드를 포함하는 한 쌍의 꺾쇠괄호 <>로 표시되며, 이는 여러 줄로 나눌 수 없습니다. 문자열 주석보다는 # 주석에 코드태그를 사용하는 것이 선호됩니다. 각 코드태그에 여러 필드가 있을 수 있으며, 이 모든 필드는 선택 사항입니다.

요약하자면, 코드태그는 니모닉, 콜론, 설명 텍스트, 여는 꺾쇠괄호, 선택적 필드 목록, 그리고 닫는 꺾쇠괄호로 구성됩니다. 예:

# MNEMONIC: Some (maybe multi-line) commentary. <field field ...>

니모닉 (Mnemonics)

관심 있는 코드태그는 다음 형식으로 아래에 나열되어 있습니다.

권장 니모닉 (및 동의어 목록) 정규 이름: 의미론

  • TODO (MILESTONE, MLSTN, DONE, YAGNI, TBD, TOBEDONE)
    • 할 일: 완료를 기다리는 비공식적인 작업/기능.
  • FIXME (XXX, DEBUG, BROKEN, REFACTOR, REFACT, RFCTR, OOPS, SMELL, NEEDSWORK, INSPECT)
    • 수정 필요: 리팩토링(refactoring) 또는 정리(cleanup)가 필요한 문제가 있거나 지저분한 코드 영역.
  • BUG (BUGFIX)
    • 버그: 버그 데이터베이스에 추적되는 보고된 결함.
  • NOBUG (NOFIX, WONTFIX, DONTFIX, NEVERFIX, UNFIXABLE, CANTFIX)
    • 수정하지 않을 것: 잘 알려져 있지만 설계 문제 또는 도메인 제한으로 인해 해결되지 않을 문제.
  • REQ (REQUIREMENT, STORY)
    • 요구사항: 특정, 공식 요구사항의 충족.
  • RFE (FEETCH, NYI, FR, FTRQ, FTR)
    • 기능 개선 요청(Requests For Enhancement): 아직 구현되지 않은 로드맵 항목.
  • IDEA
    • 아이디어: 가능한 RFE 후보이지만, RFE보다 덜 공식적입니다.
  • ??? (QUESTION, QUEST, QSTN, WTF)
    • 질문: 오해된 세부 사항.
  • !!! (ALERT)
    • 경고: 즉각적인 주의가 필요함.
  • HACK (CLEVER, MAGIC)
    • 핵: 융통성 없는 기능을 강제로 적용하기 위한 임시 코드, 또는 단순히 테스트 변경, 또는 알려진 문제에 대한 해결책.
  • PORT (PORTABILITY, WKRD)
    • 이식성: OS, Python 버전 등에 특정한 해결책.
  • CAVEAT (CAV, CAVT, WARNING, CAUTION)
    • 주의사항: 비직관적인 구현 세부사항/함정.
  • NOTE (HELP)
    • 참고: 코드 검토자가 논의 또는 추가 조사가 필요하다고 생각한 부분.
  • FAQ
    • 자주 묻는 질문: 외부 설명이 필요한 흥미로운 영역.
  • GLOSS (GLOSSARY)
    • 용어집: 프로젝트 용어집의 정의.
  • SEE (REF, REFERENCE)
    • 참조: 다른 코드, 웹 링크 등으로의 포인터.
  • TODOC (DOCDO, DODOC, NEEDSDOC, EXPLAIN, DOCUMENT)
    • 문서화 필요: 아직 문서화가 필요한 코드 영역.
  • CRED (CREDIT, THANKS)
    • 기여: 외부적으로 제공된 통찰력에 대한 공로.
  • STAT (STATUS)
    • 상태: 이 파일의 성숙도를 나타내는 파일 수준 통계 지표.
  • RVD (REVIEWED, REVIEW)
    • 검토됨: 검토가 수행되었음을 나타내는 파일 수준 지표.

파일 수준 코드태그는 버전 관리 시스템의 속성으로 더 적합할 수 있지만, 코드태그로 적절하게 지정될 수도 있습니다.

이들 중 일부는 임시적(예: FIXME)인 반면 다른 일부는 영구적(예: REQ)입니다. 니모닉은 설명력, 길이(짧을수록 좋음), 일반적으로 사용되는지 여부의 세 가지 기준을 사용하여 동의어보다 선호되었습니다.

FIXME와 XXX 사이에서 선택하는 것은 어렵습니다. XXX가 더 일반적이지만, 설명력이 훨씬 떨어집니다. 게다가, XXX는 알 수 없는 값을 가진 코드 조각에서 유용한 플레이스홀더(placeholder)입니다. 따라서 FIXME가 선호되는 철자입니다. Sun은 XXX와 FIXME가 약간 다르며, XXX가 더 높은 심각도를 갖는다고 말합니다. 그러나 이 주제에 대한 수십 년간의 혼란과 Sun의 영향을 받지 않을 수백만 명의 개발자들을 고려할 때, 이들을 동의어라고 부르는 것이 옳습니다.

DONE은 항상 완료된 TODO 항목이지만, 이는 버전 관리 시스템 및/또는 완료 기록 메커니즘(DONE 파일 참조)을 통해 표시되어야 합니다.

NOTE 태그의 수를 세는 것은 유용한 지표가 될 수 있습니다. 높은 수는 설계(또는 기타) 문제를 나타낼 수 있습니다. 그러나 물론 대부분의 코드태그는 주의가 필요한 코드 영역을 나타냅니다.

FAQ는 사용자가 더 쉽게 보고 기여할 수 있는 위키에 문서화하는 것이 더 적절합니다.

필드 (Fields)

모든 필드는 선택 사항입니다. 제안된 표준 필드는 이 섹션에 설명되어 있습니다. 대문자 필드 문자는 대체될 의도입니다.

작성자/담당자 및 작성 날짜/주 필드는 가장 일반적이며 일반적으로 접두사가 필요하지 않습니다.

이 긴 필드 목록은 사람들이 코드태그 채택을 꺼리게 만들 수 있지만(의도된 미니멀리스트), 이들은 다음 두 가지 경우의 프로그래머를 지원하기 위해 존재한다는 점을 명심하십시오.

  1. BUG 또는 RFE 코드태그를 완전한 형태로 유지하기를 좋아하는 경우.
  2. 코드태그를 완전하고 유일한 추적 시스템으로 사용하는 경우.

다시 말해, 이 필드들 중 많은 수가 매우 드물게 사용될 것입니다. 이들은 주로 업계 전반의 규칙에서 수집되었으며, 예시 소스에는 GCC Bugzilla 및 Python의 SourceForge 추적 시스템이 포함됩니다.

  • AAA[,BBB]...
    • 작성자 또는 담당자 이니셜 목록 (컨텍스트가 둘 중 어느 것인지 또는 둘 다 존재해야 하는지 결정합니다). 이니셜 대신 MicahE와 같은 사용자 이름을 사용하는 것도 괜찮습니다. 이니셜(대문자)이 선호되는 형식입니다.
  • a:AAA[,BBB]...
    • 담당자 이니셜 목록. 이는 코드태그에 담당자와 작성자가 모두 있고 서로 다른 (드문) 경우에만 필요합니다. 그렇지 않으면 a: 접두사는 생략되며, 컨텍스트가 의도를 결정합니다. 예를 들어, FIXME는 일반적으로 담당자를 가지며, NOTE는 일반적으로 작성자를 가지지만, FIXME가 검토자에 의해 시작(및 이니셜이 추가)된 경우 담당자의 이니셜에는 a: 접두사가 필요합니다.
  • YYYY[-MM[-DD]] 또는 WW[.D]w
    • 작성 날짜(Origination Date): 주석이 추가된 시점을 나타내며, ISO 8601 형식(숫자와 하이픈만)입니다. 또는 작성 주차(Origination Week): 작성 날짜를 지정하는 대체 형식입니다. 요일은 선택적으로 지정할 수 있습니다. w 접미사는 날짜와 구별하기 위해 필요합니다.
  • d:YYYY[-MM[-DD]] 또는 d:WW[.D]w
    • 기한(Due Date, d): 예상 완료 목표. 또는 기한 주차(Due Week, d): 기한을 지정하는 대체 형식.
  • p:N
    • 우선순위(Priority, p) 수준. 범위(N)는 0..3이며, 3이 가장 높습니다. 0..3은 낮음, 중간, 높음, 심각/치명적에 해당합니다. 심각도 필드는 이 단일 숫자로 통합될 수 있으며, 둘 다 갖는 것은 해석이 다양할 수 있으므로 권장됩니다. 범위와 순서는 사용자 정의할 수 있어야 합니다. 이 필드의 존재는 코드태그를 항목화하는 모든 도구에 중요합니다. 따라서 (사용자 정의 가능한) 기본값이 지원되어야 합니다.
  • t:NNNN
    • 추적기(Tracker, t) 번호: 별도의 추적 시스템에 있는 관련 티켓 ID에 해당합니다.

다음 필드도 사용 가능하지만 덜 일반적일 것으로 예상됩니다.

  • c:AAAA
    • 범주(Category, c): 이 항목의 영향을 받는 특정 영역을 나타냅니다.
  • s:AAAA
    • 상태(Status, s): 항목의 상태를 나타냅니다. 예시는 “unexplored”, “understood”, “inprogress”, “fixed”, “done”, “closed” 등입니다. 항목이 완료되면 코드태그를 제거하고 DONE 파일에 기록하는 것이 더 좋습니다.
  • i:N
    • 개발 주기 반복(Iteration, i). 코드태그를 완료 목표 그룹으로 묶는 데 유용합니다.
  • r:N
    • 개발 주기 릴리스(Release, r). 코드태그를 완료 목표 그룹으로 묶는 데 유용합니다.

요약하면, 접두사가 없는 필드는 이니셜과 작성 날짜이며, 접두사가 있는 필드는 담당자(a), 기한(d), 우선순위(p), 추적기(t), 범주(c), 상태(s), 반복(i), 릴리스(r)입니다.

그룹이 자체 필드를 정의하거나 추가하는 것이 가능해야 하며, 이들은 표준 세트와 구별하기 위해 대문자 접두사를 가져야 합니다. 사용자 정의 필드의 예로는 운영 체제(O), 심각도(S), 영향받는 버전(A), 고객(C) 등이 있습니다.

DONE 파일

일부 코드태그는 완료될 수 있습니다(예: FIXME, TODO, BUG). 완료된 항목을 완료 날짜 스탬프와 함께 기록하여 보존하는 것이 종종 중요합니다. 이러한 완료된 항목은 프로젝트(또는 패키지)에 전역적인 단일 위치에 저장하는 것이 가장 좋습니다. 제안된 형식은 예를 들어 ~/src/fooproj/DONE와 같이 가장 쉽게 설명될 수 있습니다.

# TODO: Recurse into subdirs only on blue # moons. <MDE 2003-09-26>
[2005-09-26 Oops, I underestimated this one a bit. Should have used Warsaw's First Law!]

# FIXME: ...
...

코드태그가 원본 소스 파일에서 그대로 복사되는 것을 볼 수 있습니다. 그런 다음 날짜 스탬프가 다음 줄에 선택적인 사후 분석 주석과 함께 입력됩니다. 항목은 빈 줄(\n\n)로 끝납니다.

항목이 완료될 때마다 코드태그 줄을 삭제해야 하는 것이 부담스럽게 들릴 수 있습니다. 그러나 실제로 Vim이나 Emacs 매핑을 설정하여 이 형식으로 코드태그 삭제를 자동 기록하는 것은 아주 쉽습니다(주석 제외).

도구 (Tools)

현재 프로그래머(때로는 분석가)는 일반적으로 grep을 사용하여 단일 코드태그에 해당하는 항목 목록을 생성합니다. 그러나 다양한 가상의 생산성 도구는 일관된 코드태그 형식을 활용할 수 있습니다. 몇 가지 도구 예시는 다음과 같습니다.

  • 문서 생성기 (Document Generator): 가능한 문서: 용어집, 로드맵, 맨페이지(manpages).
  • 코드태그 히스토리 추적 (Codetag History Track): (버전 관리 시스템 인터페이스와 함께) 코드 섹션에서 BUG 태그(또는 모든 코드태그)가 언제 시작/해결되었는지 추적.
  • 코드 통계 (Code Statistics): 프로젝트 Health-O-Meter.
  • 코드태그 린트 (Codetag Lint): 코드태그의 잘못된 사용을 알리고, 코드태그로의 포팅(porting)을 돕습니다.
  • 스토리 관리자/브라우저 (Story Manager/Browser): XP 노트 카드(notecards)를 대체할 전자적 수단. MVC 용어로, 코드태그는 Model이며, 스토리 관리자는 시각적 재배치, 우선순위 지정 및 할당, 마일스톤 관리를 수행하는 그래픽 뷰어/컨트롤러가 될 수 있습니다.
  • 모든 텍스트 편집기 (Any Text Editor): 코드태그를 변경, 제거, 추가, 재배치, 기록하는 데 사용됩니다.

더 작은 수의 의사 코드태그를 활용하는 일부 도구는 이미 존재합니다(참고 자료 참조). 또한 코드태그 프로젝트로 알려진 코드태그 구현 예시도 진행 중입니다.

반론 (Objections)

  • 반론: 익스트림 프로그래밍(Extreme Programming, XP)은 코드가 곧 문서이므로 그러한 코드태그는 코드에 존재해서는 안 된다고 주장합니다.
    • 반박: 대신 유닛 테스트 파일에 코드태그를 넣을 수도 있습니다. 게다가, 주석 없는 소스 코드에서 문서를 생성하는 것은 어렵습니다.
  • 반론: 너무 많은 기존 코드가 제안된 가이드라인을 따르지 않았습니다.
    • 반박: [간단한] 유틸리티(ctlint)가 기존 코드를 변환할 수 있습니다.
  • 반론: 추적 시스템과 중복을 야기합니다.
    • 반박: 필드가 남용되지 않는 한 그렇지 않습니다. 추적기에 항목이 존재한다면, 코드태그 추적기 필드에 간단한 티켓 번호만으로 충분합니다. 아마도 중복된 제목은 허용될 것입니다. 게다가, 개발자가 즉석에서 떠오르는 모든 항목에 대해 티켓을 발행하는 것은 너무 번거롭습니다. 또한, 관련 데이터를 코드태그에 합리적으로 담을 수 있는 간단하거나 작은 프로젝트의 경우 추적 시스템이 불필요해질 수도 있습니다.
  • 반론: 코드태그는 보기 흉하고 코드를 지저분하게 만듭니다.
    • 반박: 좋은 지적입니다. 하지만 저는 그런 정보가 다양한 다른 문서에 중복되거나 잊혀지는 것보다 단일 위치(소스 코드)에 있는 것을 선호합니다. 완료된 코드태그는 DONE 파일로 보내거나 버릴 수 있습니다.
  • 반론: 코드태그(및 모든 주석)는 구식이 됩니다.
    • 반박: 다른 소스(외부에 보이는 문서)가 코드태그의 정확성에 의존한다면 그렇게까지 구식이 되지 않습니다.
  • 반론: 코드태그는 어떤 종류의 예상 완료 날짜도 드물게만 가집니다. 알겠습니다, 필드는 선택 사항이지만 실제로 널리 사용될 필드를 제안하고 싶습니다.
    • 반박: 항목을 추정할 수 없다면 날짜 필드를 지정하는 데 신경 쓰지 마십시오. 기한 및/또는 우선순위에 따라 항목을 정렬 및/또는 색상으로 표시하는 도구를 사용하면 추정치를 만들기가 더 쉽습니다. 로드맵이 코드태그를 동적으로 반영하도록 하면 코드태그를 정확하게 유지할 가능성이 훨씬 높아집니다.
  • 반론: <> 안의 필드 매개변수에는 암호 같은 한 글자 접두사 대신 명명된 변수를 사용해야 합니다. 즉, <MDE p:3>보다는 <author=MDE, priority=3>여야 합니다.
    • 반박: 필드를 모두 쓰는 것은 너무 많은 타이핑/장황함입니다. 저는 p:3 i:2가 priority=3, iteration=2만큼 읽기 쉽고, 훨씬 더 많이 입력되고 기억될 가능성이 높다고 주장합니다(철학의 C 항목 참조). 이 경우 실용성이 순수성을 이깁니다. 추적해야 할 필드가 많지 않으므로 한 글자 접두사가 적합합니다.
  • 반론: 무언가를 한 가지 방식으로 철자하는 것이 더 좋으므로 동의어는 사용하지 않아야 합니다.
    • 반박: 많은 프로그래머는 특히 주석에서 짧은 니모닉 이름을 선호합니다. 이것이 짧은 니모닉이 기본 이름으로 선택된 이유입니다. 그러나 다른 사람들은 명시적인 철자가 덜 혼란스럽고 오류가 발생할 가능성이 적다고 생각합니다. 이 주제에 대해서는 항상 두 가지 입장이 있을 것입니다. 따라서 동의어(및 완전하고 전체적인 철자)는 계속 지원되어야 합니다.
  • 반론: [니모닉에 대해] 모호한 약어와 모음이 생략된 축약어를 사용하는 것은 잔인합니다. 이런 것들을 알아내는 것은 어렵습니다. 그런 이유로 저는 MLSTN, RFCTR, RFE, FEETCH, NYI, FR, FTRQ, FTR, WKRD, RVDBY를 싫어합니다.
    • 반박: 니모닉은 기억하기 쉽고 공간을 덜 차지하므로 선호됩니다. 프로그래머가 모음 생략을 싫어한다면 한 줄에 아주 적은 코드만 넣을 수 있을 것입니다. 한 줄에 맞는 주석을 작성하는 사람들에게는 공간이 중요합니다. 그러나 어디에서나 캐논(canon)을 사용할 때는 한 줄에 맞는 것을 얻기가 훨씬 어렵습니다.
  • 반론: 필드를 입력하는 데 너무 오래 걸립니다.
    • 반박: 그렇다면 (대부분 또는 어떤 필드도) 사용하지 마십시오. 특히 당신이 유일한 프로그래머라면 더욱 그렇습니다. 코드태그를 <>로 끝내는 것은 작은 수고이며, 그렇게 함으로써 제안된 도구의 사용을 가능하게 합니다. 편집기의 코드태그 자동 완성도 유용합니다. 몇 번의 키 입력만으로 편집기가 템플릿(예: # FIXME . <MDE {date}>)을 찍어내도록 프로그래밍할 수 있습니다.
  • 반론: 작업 주(WorkWeek)는 모호하고 흔하지 않은 시간 단위입니다.
    • 반박: 그렇습니다. 하지만 추정/목표 설정 목적에 매우 적합한 세분화 단위이며, 매우 간결합니다. ISO 8601은 널리 이해되지만 특정 날짜(제한적) 또는 월(광범위)만 지정할 수 있습니다.
  • 반론: 빈 필드 경우에 주석이 <>로 끝나는 것이 미학적으로 마음에 들지 않습니다.
    • 반박: 코드태그 뒤에 코드태그가 아닌 주석이 올 수 있으므로 종료자가 필요합니다. 또는 코드태그를 단일 라인으로 제한할 수도 있지만, 이는 너무 제한적입니다. <>보다 적절하고 훨씬 나은 단일 문자 종료자를 생각할 수 없습니다. @가 종료자가 될 수 있지만, 그렇다면 대부분의 코드태그에 불필요한 @가 붙을 것입니다.
  • 반론: HTML 또는 더 구체적으로 XML을 작성할 때 코드태그를 사용할 수 없습니다. <fields> 대신 @fields@가 구분자로 더 나을 수 있습니다.
    • 반박: 당신이 옳을 수도 있지만, 적용 가능한 경우 <>가 더 보기 좋습니다. XML/SGML은 @를 사용할 수 있고 더 일반적인 프로그래밍 언어는 <>를 고수할 수 있습니다.

참고 자료 (References)

일부 다른 도구는 코드태그를 정의/활용하는 데 접근했습니다. http://tracos.org/codetag/wiki/Links를 참조하십시오.

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.

Comments