단계 · 미채택 · 한계
7. 구현 단계와 파급
| 단계 | 내용 | 골든 |
|---|---|---|
| 1 | Naming 섹션 — 왕복 검사(§3)와 방어선 검사 2종(§4) | 구현 완료. 불변 — 진단만 추가되었습니다 |
| 2 | MemberCase(§5)와 예약어 목록 전체화 | 구현 완료. 기본값 불변 · member-case 픽스처 신설 |
| 3a | DataFileCase(§6.2)와 데이터 파일 이름의 모델 정본화 | 구현 완료. 기본값 불변 · data-file-case 픽스처 신설 |
| 3b | FileCase(§6.1) — 코드 파일 이름 | 기본값 불변 · 옵션 지정 픽스처 신설 |
1단계만으로 §1의 문제가 검출되기 시작하므로 단계 사이에 배포 가능한 지점이 있습니다. 2 · 3단계는 생성기·템플릿을 만지므로 골든 재기록 → 전 언어 비교본 재생성 → 샘플 재생성 → 기록 없이 재검증의 기 존 절차를 따릅니다.
문서 갱신 대상:
doc/recipe.md— 공통 설정 표에Naming·DataFileCase, 「이름과 관련된 것」 표에MemberCase·FileCase. 기존OnXxx문서화 패턴(키 — 무엇인가헤딩 + 값 표 + 기본값 표시) 그대로.doc/sheets.md— 「Naming Rules」 절에 규약 선언과 충돌 검사 안내를 추가.doc/validation.md— 사용자 규칙 예시였던Naming.cs자리에 이 기능으로의 안내를 부기.
7.1 1단계를 켰을 때 실제로 나온 것
구현 직후 저장소의 두 코퍼스에 그대로 돌린 결과입니다. 설계가 예측하지 못한 것이 두 가지 있었고, 둘 다 설계를 고치는 근거가 되었습니다.
샘플 코퍼스 — 20건. 규약을 하나도 선언하지 않은 상태에서 §4의 두 검사만으로 표기 충돌
20건이 나왔고, 변환은 성공했습니다(경고 8 · 노트 12). 생성물이 갈라지는 8건에는
Id(66곳) 대 ID(1곳), Cooltime 대 CoolTime, enum 라벨 Exp 대 EXP ·
LEVEL 대 Level이 있습니다. 갈라지지 않는 12건은 Art_Path · ArtPath · artPath
같은 구분자 차이입니다. §1의 실측이 다른 프로젝트의 이야기가 아니라는 것이 이 숫자의
뜻입니다 — 이 저장소가 검증용으로 들 고 있는 시트도 같은 상태입니다.
테스트 픽스처 — 설계 오류 1건을 드러냈습니다. TreatWarningsAsErrors를 켠 픽스처에서
None 대 none 라벨 충돌이 경고로 승격되어 변환이 멈추고, 그 픽스처가 검사하려던 규칙이
실행되지 못했습니다. 두 표기는 정규화가 같아 생성물에 아무 영향이 없는데도 빌드를 멈춘
것입니다. 이것이 §4.1의 등급제(생성물이 갈라지지 않는 충돌은 한 단계 낮게)를 넣은 이유이고,
설계 시점에는 warn 하나로 충분하다고 적어 두었던 자리입니다.
규약의 판별 한계 1건. 「규약이 다수보다 우선」이 성립하지 않는 경우를 테스트를 쓰다가
발견했습니다. applypointId와 applyPointId는 둘 다 camel 왕복을 통과합니다 —
applypoint가 한 단어로 읽히기 때문입니다. 규약은 표기를 판정할 수 있지만 단어 경계를
판정할 수는 없으므로, 이 경우에는 다수 표기로 물러납니다(§9).
8. 미채택한 것
| 안 | 미채택 이유 |
|---|---|
| 자동 교정 — 도구가 어긋난 표기를 고쳐 변환을 계속 | 정본은 시트입니다. 경계가 소실된 표기의 교정은 교정이 아니라 추측입니다 |
사전 기반 경계 복원 — 단어 목록으로 maxhitpoints → MaxHitPoints | 어휘 목록의 유지 비용이 검사의 가치를 넘고, 오분할이 조용한 오생성이 됩니다 |
| 이름별 재정의 맵 — 레시피에서 시트 이름 → 코드 이름 개별 지정 | 표기 편차를 레시피에 영구 보존하게 됩니다. 시트 수정의 반대 방향입니다 |
멤버 표기 값 raw — 시트 표기를 그대로 출력 | 언어 유효성과 예약어 회피를 보장할 수 없습니다 |
파일 접두·접미 커스텀 (FilePrefix 등) | 표기 축과 다른 구조 축입니다. 필요가 실측되면 별도 설계입니다 |
9. 한계
단독으로 나타나는 경계 소실 이름은 어느 검사로도 검출되지 않습니다 — maxhitpoints가
모델에 한 번만 나타나면 camel 규약도 충돌 검사도 통과합니다. 완화는 둘입니다.
- 두 번째 표기가 나타나는 순간 §4.1이 검출합니다. 편차는 대개 복수 표기로 나타나므로 실질 사각은 좁습니다.
snake·upper-snake규약은 단어 경계가 표기에 명시되므로 이 사각이 구조적으로 없습니다. 경계 소실이 잦은 팀에는 이쪽 규약이 안내 대상입니다.
같은 사각이 권장 표기의 선택에도 있습니다. applypointId와 applyPointId는 둘 다 camel
왕복을 통과하므로 — applypoint가 한 단어로 읽힙니다 — 규약을 선언해도 어느 쪽이 맞는지
판별되지 않고, 이때는 다수 표기를 제시합니다. 규약은 표기를 판정하고 단어 경계는
판정하지 않습니다. 충돌 자체는 보고되므로 사람이 판단할 자리는 만들어집니다.
도구가 스스로 써넣은 이름은 검사 대상이 아닙니다. AutoInsertEnumNoneLabel이 넣는 None
라벨이 그것이고, 아무도 고를 수 없었던 표기를 규약에 대어 보고하면 고칠 셀이 없는 보고가
됩니다. 모델에 Synthesized 표시를 두어 제외합니다.
10. 게이트
- 규약 위반이 첫 건에서 중단되지 않고 셀 위치와 함께 일괄 보고되는지.
maxHitPoints·maxhitpoints·maxhitPoints세 표기가 진단 1건으로 묶여 보고되는지.my_flag와myFlag처럼 정규화 결과가 같은 표기 차이도 보고되는지, 그리고 진단이 생성물 분기 여부를 구분해 표시하는지.- 생성물이 갈라지는 충돌은 설정한 무게로, 갈라지지 않는 충돌은 한 단계 낮게 보고되는지 —
그리고
TreatWarningsAsErrors를 켠 빌드가 후자로 멈추지 않는지. snake선언에서a__b가 왕복 검사는 통과하되 연속 밑줄 검사로 보고되는지.Exempt에 오른 이름이 왕복 검사·표기 충돌·연속 밑줄 어디에도 걸리지 않고, 목록에서 지우면 다시 걸리는지.- 규약이 선언된 종류의 충돌 진단이 다수 표기가 아니라 규약에 맞는 표기를 제시하는지 — 그리고 여러 표기가 규약을 만족하면 다수로 물러나는지.
- 도구가 삽입한 enum
None라벨이 규약 검사에 걸리지 않는지. - 각 단계에서 옵션 미지정 레시피의 골든이 바이트 단위로 불변인지.
MemberCase: "camel"의 C#에서 예약 어와 겹치는 멤버가@회피로 출력되고 컴파일되는지.DataFileCase지정 시 익스포터 산출 파일 이름과 전 언어 리더가 여는 이름이 일치하는지 (컨포먼스).
EOD