지금 진행하는 프로젝트의 coding idiom에는 가독성(readability)에 대한 부분이 정의되어 있다.
많은 사람들이 관리해야 할 코드에는 가독성이 필요하다는 것에는 의문이 없다. 하지만 무엇이 더 가독성이 좋은가에 대한 의견에는 의문이 많다.
1. if 문 뒤에 딱 한 라인이 올 때의 처리
(1) if (cond)
return false;
(2) if (cond)
{
return false;
}
위의 둘 중에 무엇을 택해야 하는 가에는 항상 논란이 많았다. (1)안을 택하게 되면 2개의 라인으로 내용을 모두 볼 수 있다는 장점이 있고 (2)안의 경우에는 indentation에 대한 예외를 두지 않는 규칙이라는 장점이 있다. (코딩에 실수를 할 우려가 있다 등등은 하수를 위한 것이므로 논외)
현재 내가 진행하는 과제에서는 (2)안이 채택되어 있지만 나는 (1)안을 주장했다. 가독성의 가장 큰 장점이 빨리 코드를 파악해야 한다는 것인데 (1)안처럼 쓰면 한 눈에 코드 2줄-(2)안을 쓰면 화면 아래에 있을-을 더 볼 수 있다는 장점이 있기 때문이다
2. 가로로 긴 줄을 잘라서 개행하기
(1) 가로로 라인이 길어도 개행 하지 않기.
(2) 128자 등의 기준을 두고 기준 라인이 넘을 경우 개행 권고
이것도 논란이 많은 이슈 중에 하나다. Linux 쪽의 유명한 사람은 아예 길게 코드를 짤 수 없게 하라는 말도 하였으나 현실과는 좀 맞지 않고, 최근에는 변수 이름을 길게 쓰거나 template을 파라미터로 쓰고 있기 때문에 가로줄이 계속 길어지고 있다.
현재는 가로로 스크롤을 하지 않고도 모든 코드를 다 볼 수 있는 (2)안이 채택되어 있으나 나는 (1)안을 주장하였다. (2)안을 쓰면 코드가 바뀔 때마다 개행 해야 하는 위치를 바꿔야 하는 것이 불편한데다가, 가로로 긴 코드를 실제로 끝까지 봐야 할 일은 거의 없다는 이유에서다.
가로로 줄이 길게 나오려면 주로 파라미터가 많거나 파라미터를 표시하는 방법이 길다는 것인데, 보통 코드를 분석할 때는 앞의 함수 이름을 보고 내가 관심이 있을 때만 뒤의 파라미터까지 보는 것이 대부분이라 나는 (1)안이어도 문제가 없다는 생각이다.
3. 매크로에 대한 것
(1) 매크로가 유리할 때는 써야 한다.
(2) 매크로는 최대한 쓰지 말자.
이 주제는 goto를 써야 하나 말아야 하냐의 오랜 주제처럼 의견이 많은 내용이다. 하지만 회사의 프로젝트에는 나름대로의 규칙이 존재해야 하기 때문에 이것에 대한 결론도 내어야 하였다. 결론은(2)안이 채택되었으나 나는 아주 예전부터 이것에 관해서는 (1)안을 주장해 왔다. C++ 책에 보면 매크로를 잘 못 썼을 때의 폐혜를 나열하면서 inline template으로 만들라고 한다. 하지만 그것은 ‘매크로를 잘 못 짜거나 잘 못 사용한 경우’에 대한 것이므로 제대로 만들었을 때는 문제가 없다는 것이다. 사실 규칙이 (2)안으로 정해졌기 때문에 나도 매크로를 inline template으로 바꾸는 작업을 하였는데, 주로 한 일이 1줄 짜리 매크로를 동일한 기능을 하는 7줄 짜리로 만드는 일이었다.
그리고 각 method 마다 객체의 validity를 체크 하는 것이 method 제일 앞에 매크로로 들어가 있었다. 매크로만 신뢰한다면 항상 해당 method는 매크로 이후에는 객체 상태가 valid 하다는 것을 보장하는 코드이다. 게다가 수시로 바뀌는 validity 조건을 딱 한군데에서 제어할 수 있기 때문에 큰 장점이 있는 구조였다. 하지만 매크로를 없애야 하는 일이 생기면서 이 부분도 수정을 해야 하게 되었는데 이 매크로 안에는 return과 같은 제어문이 들어 가기 때문에 inline template으로도 만들 수가 없다. 그래서 결국은 매크로를 모두 풀어서 각 method 제일 앞에 넣는 수 밖에 없는 것이다. (물론 이건 안 하고 있다)
그래서 나는 (1)안을 주장한다.
Posted by 안영기
CubeSampleViewActivity.zip
