우리는 코드를 하나 열어볼 때 깔끔하고, 일관적이고, 꼼꼼하고, 질서정연하다면 나머지 코드들도 똑같이 깔끔할 것이라 기대한다.
반대로 술에 취한 사람들이 짜 놓은 것 같은 코드를 봤다면 프로젝트에 대한 다른 측면도 동일하게 생각하게 될 것이다.
프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다.
코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다.
팀으로 일한다면 팀이 합의해 규칙을 정하고 그 규칙을 따라야 한다..!
코드 컨벤션은 시작 시에 맞추는 컨벤션과 모든 코드가 동일하게 적용되는 비인지적인 부분이 있는 것 같다.
생각나는게 여러개 있는데 등장하는 목차에 따라 연결지어서 나열해본다.
코드 형식은 중요하다.
너무나도 중요하므로 융통성 없이 맹목적으로 따르면 안 된다.
코드 형식은 의사소통의 일환이다.
의사소통같은 느낌으로 생각하니 같은 언어라도 지역마다 사투리 정도로 생각된다.
팀 by 팀, 프로젝트 by 프로젝트별 컨벤션이 조금씩 상이하니 읽을 순 있지만 사투리 정도로 들리는게 아닌가.. 생각이 든다.
오늘 구현한 기능은 다음 버전에서 바뀔 가능성이 높다.
하지만 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다.
맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수성과 용이성에서 계속 마이너스를 불러온다.
그럼 원활한 소통을 장려하는 코드 형식은 어떤 것이 있을까?
소스 파일의 크기, 코드의 줄 수는 몇줄이 적당할까?
대부분 개발 서적에서도 같은 맥락으로 100줄을 넘어가면 의심을 시작하라고 하는데 사실 주관적인 부분이라 다른 책에서도 절대적이진 않다고 한다.
하지만 그에 대한 반증으로 잘 짜여진 대형 애플리케이션의 소스코드를 본다면 좋은 방향인 것은 명백하다.
따라서 약 65~100줄 정도가 적당하다고 생각한다.
클래스 단위에서 이 줄을 넘어가면 한 가지 기능보다 더 많은 것을 수행하게 된다.
행 길이를 유지하는 것 또한 하나의 토템으로 작동할 수 있다.
아주 좋은 신문 기사를 떠올리면 우리는 표제를 보고 읽을지 말지를 결정한다.
첫 문단은 전체 기사를 요약한다.
세세한 사실은 숨기고 그림을 보여준다.
쭉 읽으며 내려가고 세세한 사실이 조금씩 드러난다.
소프 파일도 비슷하게 작성한다.
이름은 간단하면서도 설명이 가능하게 짓는다.
이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 수 있어야 한다..
소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다.
아래로 내려갈수록 의도를 세세하게 묘사한다.
마지막에는 가장 저차원 세부 사항이 나온다.
한 마디로 모든 정보를 정리하는게 아닌 개발자 측면에서 읽기 유리하게 코드를 작성해야 한다는 것이다.
코드는 왼쪽 위 정렬로 읽는다.
각 행은 수식이나 절을 나타내고, 일련의 행 묶음은 완결된 생각 하나를 표현한다.
빈 행은 새로운 개념을 시작한다는 시각적 단서다.
빈행 또한 코드의 일부이다.
이런 부분들이 조금 비인지적인 컨벤션이라고 생각된다.
괄호의 위치같은게 아닌 당연시 되는 부분이라고 생각한다.
줄바꿈이 개념을 분리한다면 세로 밀집도는 연관성을 의미한다.
즉, 서로 밀집한 코드 행은 세로로 가까이 놓여야 한다는 뜻이다.
바뀐 코드를 봐도 눈이나 머리를 거의 쓸 필요가 없다.
타고 타고 위 아래로 반복하게 하는 코드는 절대 좋은 코드가 아니다.
서로 밀접한 개념끼리는 세로 거리를 강한 밀집도를 지녀야 한다.
나름의 우선순위와 이해가 가능한 규칙으로 구성해야 한다.
이 이유가 상속과 protected 변수를 멀리해야 하는 이유와 같은 맥락이다.
변수는 사용하는 위치에 최대한 가까이 선언한다.
인스턴스 변수는 클래스 맨 처음에 선언한다.
논쟁에 대한 가위 규칙에 대한 부분은 처음보는 부분이라..
저런 규칙이 있다는 정도만 알고 넘어간다.
한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다.
또한, 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다.
어떤 코드는 서로 끌어당긴다.
개념적인 친화도가 높기 때문이다.
친화도가 높을수록 코드를 가까이 배치한다.
예로는 함수가 다른 함수의 종속성을 가지고 있을 때, 변수와 그 변수를 사용하는 함수 정도가 있다.
예제처럼 오버로딩과 관련된 부분도 모아두는 것이 바람직하다.
일반적으로 함수 호출 종속성은 아래 방향으로 유지한다.
따라서 호출되는 함수를 호출하는 함수보다 나중에 배치한다.
그러면 소스 코드 모듈이 고차원에서 저차원으로 자연스럽게 내려간다.
신문 기사와 마찬가지로 중요한 개념을 가장 먼저 표현한다.
세세한 사항은 최대한 배제하고 가장 마지막에 표현한다.
여기서 세세한 사항조차 래핑을 하면 그 함수를 볼려고 어차피 눈이 이동해야 하는게 아닌가?
라고 생각을 한다면 2장을 다시 읽어야 한다.
간단한 제곱을 하는 Math함수를 동작과정을 이해하기 위해 내부 정의로 들어가지 않는 것과 같은 맥락이다.
하나 더 조심해야하는 부분은 코드 계약으로 3장 함수의 내용처럼 오용될 수 있는 함수나 기능을 예상하여 작성하는 함수들이다..
다시 강조하지만 이름은 해당 함수의 기능을 명확하게 나타내고 해당 함수는 그 기능만을 수행한다면 코드는 글처럼 동작한다.
세로 형식과 마찬가지로 가로또한 완성도 있는 프로젝트를 조사해보니 약 10자 미만, 20~60자 정도까지 나온다.
프로그래머는 명백하게 짧은 행을 선호한다.
가로로는 공백을 사용해 밀접한 개념과 느슨한 개념을 표현한다.
할당 부분은 공백으로 구분하고 함수와 이어지는 부분은 구분하지 않는다.
이 처럼 밀접한 개념 그리고 느슨한 개념을 공백으로 표현할 수 있다.
가로 정렬은 오히려 코드를 읽기 어렵게 만든다.
따라서 패스.
소스 파일은 윤곽도와 계층이 비슷하다.
파일 전체에 적용되는 정보가 있고, 파일 내 개별 클래스에 적용되는 정보가 있고, 클래스 내 메서드에 적용되는 정보가 있고, 블록 내 블록에 재귀적으로 적용되는 정보가 있다.
이렇듯 범위로 이루어진 계층을 표현하기 위해 들여쓴다.
들여쓰기 정도는 계층에서 코드가 자리잡은 수준에 비례한다.
선호의 차이일까? 람다정도는 들여쓰기를 무시하고 작성하는 편이다.
실제로 C#컨벤션에서 프로퍼티나 한줄 람다는 많이 사용하는 편인 것 같다
하지만 한줄에 가로 10줄 이상 길어지는 로직은 들여쓰기가 반드시 필요해보인다.
이건 닌자코드같은 느낌이라..
패스으
가장 우선시 되는 규칙이 바로 팀 규칙이다.
회사에 들어가 자신이 올바르다고 하며 해당 팀 규칙을 무시하는 신입사원은 없을 것이다.
좋은 소프트웨어는 읽기 쉬운 문서로 이뤄진다.
대괄호 위치를 제외하고 자바 자체가 C#과 매우 비슷해서 어색하지 않게 느껴진다.
지식을 다시 한번 정리하는 느낌의 챕터였다.
자신만의 컨벤션이 있을까요?
저는 유니티로 작업할 때 하이어라키에서 중요도에 따라 우선순위로 작업하고 코드도 해당 순위를 따라가는 편입니다.
코드레벨이 아니라 유니티에선 컴포넌트 단위에서도 컨벤션이 어느정도 (비인지적인)부분이 존재하는 것 같습니다.
순위가 없을 땐 솔류션 뷰에서 정렬된 순서로 작업하는 것 같습니다.