# PHP - PSR
- https://www.php-fig.org/psr/
- 한국어(비공식): https://psr.kkame.net
코딩 컨벤션과 몇가지 구조의 인터페이스 규격이 정의되어 있죠.
인터페이스 규격은 많지는 않고 사용할 일은 사실 많지 않지만 프레임워크류에서는 광범위하게 사용하고 있습니다.
주로 보면 좋을건 역시 코딩 컨벤션이죠. https://psr.kkame.net/accepted/psr-12-extended-coding-style-guide
# PHPDoc
- https://phpdoc.org
이미 많이 사용하고 있는 `/** ... */` 형태로 사용하는 주석 블럭이죠.
각종 에디터에서도 지원하고 위 링크의 phpDocumentor 등의 도구를 통해 자동으로 API 문서를 만들어줍니다. 유사한 다른 툴도 있고요.
에디터에서 phpdoc 에 파라미터 타입이나 리턴타입 등을 정의해두면 에디터에서 타입 검사를 해주기도 하고요. 이미 오래된 규칙입니다.
PSR에서도 이를 표준화를 진행하고 있기는한데 꽤 오래전에 시작된 건데도 아직 정식 표준안으로 채택되지는 않았습니다.
# JavaScript
- https://standardjs.com/rules-kokr
이 역시 광범위하게 사용되는 JS 코딩 컨벤션입니다.
# CSS
CSS는 딱히 공통된 규칙보다는 제각각이긴한데 보통 들여쓰기는 공백 2개, 하이픈(`-`) 사용 정도가 보편적인 것 같네요.
# EditorConfig
- https://editorconfig.org
단순하지만 유용한 규칙들을 가지고 있죠.
들여쓰기 문자와 갯수, 줄끝 공백제거 같은 간단한 규칙을 제공하고 각종 에디터에서도 기본으로 이 룰을 사용하거나 플러그인을 제공하고 있죠.
# Prettier
- https://prettier.io
CSS, JS, HTML 등의 코드 포맷터입니다.
위에 있는 각종 권장되는 규칙을 기반으로 코드를 포맷해주는 도구입니다.
이것도 여러 에디터에서 플러그인으로 사용할 수 있죠.
# PHP CS Fixer
- https://cs.symfony.com
PHP는 Prettier로만 사용하기는 조금 부족해서 이걸 사용해도 좋습니다.
규칙을 매우 상세하게 정할 수 있어서 라이믹스의 코딩 컨벤션도 맞추는데 도움이 될 수 있습니다.
PSR 등 내장된 룰셋을 이용할 수도 있고요.
경로를 지정하여 대량으로 파일을 자동으로 고칠 수도 있죠. 주로 그렇게 사용하는 툴이고요.
# PHPStan
- https://phpstan.org
PHP 정적 분석도구입니다.
보통 에디터에서도 경고나 오류를 잡아주지만 이런 도구들은 조금 더 상세한 리포트를 보여줍니다.
리포트 레벨을 정할 수 있고 세부 규칙도 커스텀 할 수 있습니다.
저는 보통 6 레벨로 사용하는데 타입이 지정되지 않은 파라미터나 리턴타입을 지정하도록 경고하고 체크도 해줍니다.
CLI에서 사용할 수 있지만 이 역시 에디터 플러그인으로 사용할 수도 있습니다.
이와 유사한 Psalm 같은 툴도 있습니다.
- https://psalm.dev
# 유의적 버전(Semantic Versioning. semver)
- https://semver.org/lang/ko/
버전명 표기 규칙이 정의되어 있습니다.
아주 광범위하게 이 규칙을 따르고 있죠.
# Conventional Commits
- https://www.conventionalcommits.org/ko/v1.0.0/
커멧 메시지를 명확히하고 semver 규격에 맞춰 자동으로 버전 번호를 올려주는 도구도 활용할 수 있습니다.
커밋 메시지 앞에 `fix: 버그 수정`처럼 fix, feat 같은 타입을 지정하는 방식으로 아주 간단한 규칙입니다.
아래 툴을 사용하면 커밋 메시지를 추려서 CHANGELOG.md 파일에 커밋 목록을 만들어 줍니다.
- https://github.com/conventional-changelog/standard-version
- https://cluster-taek.tistory.com/entry/Git-Versioning-및-CHANGELOGmd-생성-자동화
이것과는 관계 없지만 이모지를 활용한 재밌는 커밋메시지를 작성하는 방법도 있습니다.
- https://gitmoji.dev
- https://inpa.tistory.com/entry/GIT-⚡%EF%B8%8F-Gitmoji-사용법-Gitmoji-cli
재미로 잠시 사용해봤는데 이모지 고르는거 은근히 귀찮네요^^
---
이것들은 반드시 따라야 할 표준 규칙은 아닙니다.
권장사항 정도로 생각하면 좋고, 표준은 아니지만 많은 프로젝트에서 이런 규칙을 사용하고 있기 때문에 사실 표준, 보편적인 규칙이라서 적용이 어렵지 않다면 이런 규칙을 적용하면 많은 사람들이 알아보고 쉽게 따를 수 있겠습니다.
더 있을텐데 일단 기억나는 것만 적어봤습니다.
네, 규칙은 아니고 권장사항인데... 전혀 다른 성격과 중요도를 가진 여러 권장사항과 관습들이 마치 동급인 것처럼 묶여서 통용되고, 이를 교조적으로 강요하는 사람들이 커뮤니티에서 큰 목소리를 내는 것은 어느 프로그래밍 언어에서나 큰 폐해라고 생각합니다.
링크하신 문서 중 JS 표준 스타일의 예를 들어 보겠습니다.
1그룹: 중괄호 없이 if문 아랫줄에 코드 한 줄만 던져 놓거나, 등호인지 조건부 할당인지 헷갈리는 문법, 중복되는 키값이나 case문 같은 것은 심각한 오작동을 일으킬 수 있으니, 이런 도구를 사용해서 철저하게 걸러내는 것이 좋겠지요.
2그룹: 클래스 생성자에서 반드시 부모 생성자를 호출하라거나, getter와 setter를 항상 쌍으로 사용한다는 규칙은 일반적으로 바람직한 코딩 습관이지만, 필요에 따라 예외가 있을 수 있습니다. 규칙을 지킨다는 명목으로 무조건 따른다면 오히려 더 지저분한 코드가 나올 수도 있지요.
3그룹: 공백이나 중괄호 위치 등에 대한 뿌리깊은 논쟁인데, 사실 이런 얘기를 하는 것 자체가 시간낭비입니다. 웬만큼 변태적인 취향을 가진 사람이 등장하지 않는 한, 그런 사소한 차이 때문에 내가 코드를 읽는 데 방해가 된다면 오히려 나의 경험이나 독해력이 부족한 것은 아닌가 고민하는 것이 훨씬 더 생산적이예요.
이 중에서 보따리 싸들고 다니며 강조해야 할 것은 1그룹뿐입니다. 만약 학생들에게 2그룹을 가르친다면 반드시 단서를 달아서, 재수없는 교조주의자를 양성하지 않도록 주의해야 하지요. 3그룹은 다양한 코드를 다뤄보며 사람마다, 팀마다, 회사마다 각각 일관성있는 스타일을 정하면 그만이고요.
그런 면에서는 PHP 커뮤니티가 무척 인간적이라고 생각합니다. 코딩 스타일도 중요한 것부터 PSR-1과 PSR-12로 나누어 놓았고, 그 안에서도 MUST, SHOULD, MAY 등의 표현을 사용하여 얼마나 엄격하게 따라야 하는지에 차등을 둡니다. 그 와중에 PHP 생태계에서 압도적인 지분을 차지하는 워드프레스는 자기만의 코딩 스타일을 고수하고 있는데, PSR-1과 PSR-12이 사실상 다수결로 정해진 것임을 감안하면, 워드프레스 스타일을 머릿수로 밀어붙여도 딱히 할 말은 없죠. 그래도 PHP끼리는 서로 사이좋게 잘 지냅니다. 시비는 항상 다른 언어 쓰는 사람들이 먼저 걸더라구요.
아이언맨과 캡틴 아메리카 중 누가 더 센지를 놓고 아이들이 서로 감정 상해가며 논쟁할 때, 어른들은 진짜 아이언맨 같은 기술을 개발하느라 그런 논쟁을 할 시간이 없습니다.^^