읽기 쉬운 코드 작성 방법
읽기 쉬운 코드 작성은 정말 어렵다.
다른 사람이 작성한 코드는 모두 읽기 어렵다.
본인이 작성한 것도 몇 달이 지나면 읽기 어렵다.
그래서 우리는 본인을 위해서 그리고 함게 일하는 개발자를 위해서 몇가지 규칙을 정해보자.
간략하게 요약 정리해 보았는데, 쉬운 소재는 아니다.
하단의 참고 문서와 도서가 많은 도움이 되리라 생각된다.
IDE 발전으로 인해 주석을 통해 얻을 수 있는 이득이 더욱 많아 졌다.
주석 문법을 확인하여 작성하고 일반 텍스트 에디터를 사용하여 개발하고 있다면 에디터를 바꿔라.
그러나 명확하게 명시된 이름이거나 간단한 코드에 주석을 다는 건 피해라.
꼭 달고 싶다면 적당히 코드를 그룹화하여 작성하자.
어떤 스타일이 좋다라고 할 수 없지만 일관성 있는 들여쓰기 규칙을 정하자.
팀 혹은 프로젝트의 일부 코드만 수정 시 이미 작성된 규칙을 따르자. 이건 지키자.
들여쓰기 시 Tab 혹은 Space 중 어떤 것을 사용할지도 정하라.
그러나 깊은 우물 속은 알수 없듯 코드도 깊어 질 수록 이해하기 힘들어진다.
최대 3뎁스로 규칙을 정하자.
일관성 있는 이름 규칙은 코드 분석 시 많은 도움이 된다.
그리고 임시 변수의 경우 일관성있는 접두사 사용으로 일반 변수와 구분하자.
다른 곳에서 재사용되지 않는 변수 명을 구분하면 리팩토링시 편하다.
연관성 있는 코드와 그렇지 않은 코드를 블럭으로 구분하자.
프레임워크를 사용하고 있다면 어느 정도 하고 있다고 본다.
우리는 적당한 줄 바꿈 글에 익숙해져있다. 코드도 적정 길이를 지키자.
과거 80열이 표준이었으나 최근엔 모니터가 평균적으로 커짐에 따라 100열 정도가 표준이 된듯하다.
오류 발생 시 SQL 문법 오류 인지 컬럼 명 오류 인지 찾기도 편하다.
중복된 코드는 시간이 지날 수록 유지보수 리소스를 많이 차지하며 잠재적 버그 요소다.
재 사용될 코드는 한 곳에서 관리하고 참조하여 쓰자.
이러한 코드를 살펴보는건 좋은 학습 효과가 있을 것이다.
어제보다 오늘, 3시간 전보다 현재 코드 질이 좋아지면 된다. 분명 다시 보면 수정해야될 부분이 생각 날 것이다.
기능 추가나 버그 수정은 리팩토링이 아님을 명심해라.
다른 사람이 작성한 코드는 모두 읽기 어렵다.
본인이 작성한 것도 몇 달이 지나면 읽기 어렵다.
그래서 우리는 본인을 위해서 그리고 함게 일하는 개발자를 위해서 몇가지 규칙을 정해보자.
간략하게 요약 정리해 보았는데, 쉬운 소재는 아니다.
하단의 참고 문서와 도서가 많은 도움이 되리라 생각된다.
01. 주석
코드와 소통하기 위해서는 주석은 필수다.IDE 발전으로 인해 주석을 통해 얻을 수 있는 이득이 더욱 많아 졌다.
주석 문법을 확인하여 작성하고 일반 텍스트 에디터를 사용하여 개발하고 있다면 에디터를 바꿔라.
그러나 명확하게 명시된 이름이거나 간단한 코드에 주석을 다는 건 피해라.
꼭 달고 싶다면 적당히 코드를 그룹화하여 작성하자.
02. 일관성 있는 들여쓰기
들여쓰기는 개인적인 취향이 강하다.어떤 스타일이 좋다라고 할 수 없지만 일관성 있는 들여쓰기 규칙을 정하자.
팀 혹은 프로젝트의 일부 코드만 수정 시 이미 작성된 규칙을 따르자. 이건 지키자.
들여쓰기 시 Tab 혹은 Space 중 어떤 것을 사용할지도 정하라.
그러나 깊은 우물 속은 알수 없듯 코드도 깊어 질 수록 이해하기 힘들어진다.
최대 3뎁스로 규칙을 정하자.
03. 일관성 있는 이름 규칙
PHP가 가지고 있는 문제점 일수도 있다.일관성 있는 이름 규칙은 코드 분석 시 많은 도움이 된다.
- camelCase: 각 단어의 첫 글자는 대문자를 사용(첫 단어는 소문자 사용)
- underscores: 각 단어를 밑줄로 구분한다.
그리고 임시 변수의 경우 일관성있는 접두사 사용으로 일반 변수와 구분하자.
다른 곳에서 재사용되지 않는 변수 명을 구분하면 리팩토링시 편하다.
04. 코드 그룹화
연관된 코드가 연속적으로 한 줄 씩 작성하게 되는 일이 있다.연관성 있는 코드와 그렇지 않은 코드를 블럭으로 구분하자.
05. 파일/디렉토리구성
모든 코드가 한 파일에 존재하면 읽기 어렵듯 파일도 적당한 디렉토리로 분류하자.프레임워크를 사용하고 있다면 어느 정도 하고 있다고 본다.
06. 줄 길이 제한
긴길은 쉽게 이해되지 않으며 읽기도 불편하다.우리는 적당한 줄 바꿈 글에 익숙해져있다. 코드도 적정 길이를 지키자.
과거 80열이 표준이었으나 최근엔 모니터가 평균적으로 커짐에 따라 100열 정도가 표준이 된듯하다.
07. SQL 문자는 대문자 사용
SQL 문자와 함수 이름을 대문자로 작성하면 테이블 명과 컬럼 명을 구분지어 이해하기 쉬워진다.오류 발생 시 SQL 문법 오류 인지 컬럼 명 오류 인지 찾기도 편하다.
08.중복된 코드 제거
코드를 작성하다보면 반복적으로 사용되는 코드가 발생한다.중복된 코드는 시간이 지날 수록 유지보수 리소스를 많이 차지하며 잠재적 버그 요소다.
재 사용될 코드는 한 곳에서 관리하고 참조하여 쓰자.
09. 오픈 소스 코드 보기
협업으로 진행되는 오픈 소스 프로젝트는 많은 개발자들이 쉽게 이해하고 참여할수 있도록 효율적인 관리 방법과 가독성을 유지하기 위해서 노력한다.이러한 코드를 살펴보는건 좋은 학습 효과가 있을 것이다.
10. 코드 리팩토링
리팩토링은 어려운게 아니다.어제보다 오늘, 3시간 전보다 현재 코드 질이 좋아지면 된다. 분명 다시 보면 수정해야될 부분이 생각 날 것이다.
기능 추가나 버그 수정은 리팩토링이 아님을 명심해라.