코드 스타일은 취향을 통일하는 규칙이 아니라 동료가 변경을 빠르게 읽고 오류를 찾도록 돕는 약속입니다. 포매터를 설치했다고 설계가 좋아지는 것은 아니며, 반대로 코드가 동작해도 읽기 어려우면 유지 보수가 힘들어집니다.
팀 규칙을 먼저 확인하기
기존 프로젝트에 참여할 때는 새 스타일을 들여오기 전에 저장소의 설정 파일과 주변 코드를 살펴보세요. Python PEP 8도 프로젝트 내부의 일관성을 강조합니다. 공통 규칙과 충돌할 때는 팀의 합의와 호환성을 확인한 뒤 변경합니다.
이름과 함수 범위
변수 이름은 데이터의 역할을 드러내고, 함수는 하나의 검증 가능한 책임을 맡도록 나눕니다. 예를 들어 data보다 pending_orders가 주문 상태를 더 잘 설명합니다. 긴 함수는 단순히 줄 수가 많아서가 아니라 입력·변환·저장처럼 다른 책임이 섞일 때 분리합니다. 주석에는 코드가 이미 말하는 “무엇”보다 예외적인 결정을 내린 “왜”를 적습니다.
자동 포맷과 코드 리뷰
들여쓰기와 공백은 팀에서 정한 도구로 자동 정리하면 리뷰 시간을 기능 변경에 쓸 수 있습니다. 단, 포맷 변경을 기능 수정과 한꺼번에 제출하면 실제 변경점을 읽기 어렵습니다. 풀 리퀘스트 안내처럼 변경을 작은 단위로 제안하고 검토하세요.
학습 과제
기존 함수 하나의 이름과 책임을 정리하되 동작 테스트가 그대로 통과하는지 확인합니다. 변경 전후의 읽기 쉬운 점과 아직 남은 예외를 기록하세요. 이 과정은 개발자 학습 순서에서 설명한 프로젝트 검증에도 연결됩니다.