얼마 전 “‘다른 개발자는 어떻게 쓸까?’ 사소하고 재미있는 9가지 프로그래밍 관례“라는 제목의 흥미로운 기사가 올라왔다. 공감하기 어려운 것들도 있겠지만 세상 대부분 일이 그러하듯 많은 사람들이 선택하는데는 그만한 이유가 있기 때문이다. 그 중 좀 더 많은 개발자들이 공감하기 어려울 것 같은 코드 한 줄의 길이를 80자 이내로 하는 부분에 대해 내 생각을 적어보고자 한다.

요즘은 모니터 크기가 커지고 폰트 크기도 자유롭게 설정할 수 있기 때문에 옛날 텍스트 모드에서나 맞을 법한 80자 제한이 필요한 이유를 떠올리기 쉽지 않을 수 있다. 하지만 80자 제한이 필요한 이유는 작업용 모니터 크기에만 달린 문제가 아니다.

  1. 오픈 소스의 경우 개발자 환경을 예상하기 어렵다.

    극단적으로 말해 박물관에서나 볼 법한 컴퓨터로 개발을 하는 개발자들도 있을 수 있다. 또한 라이브 환경 하에 작업을 해야 하는데 IDC 내 콘솔에서 작업을 하는 경우 텍스트 모드에서 코드를 열어봐야 하는 상황에 놓인 개발자가 있을 수도 있다. 이런 극단적인 환경까지 감안을 한다면 80자 제한은 최악의 환경에서도 코드를 열어 볼 수 있도록 하는 공동체의 최소한의 배려일 것이다.

  2. 코드 한 줄이 길어진다는 것은 나쁜 징후일 수 있다.

    if 문의 단계가 깊어졌거나 함수가 여러 기능을 포함하면서 더 잘게 쪼개져야 할 함수가 쪼개지지 않은 상황에서 코드 길이가 길어지는 현상이 나타날 수 있다. if 문의 단계를 줄이고 함수를 최소의 크기로 잘게 나누다 보면 길어졌던 코드 한 줄이 80 자 이내로 짧아지는 경우를 자주 경험했다.

    또한 불필요하게 함수나 변수명을 길게 쓰는 경우가 있다. 지역성을 높이고 결합도를 충분히 낮춘 경우 짧게 쓰는 것이 오히려 더 가독성이 높을 수도 있다. 길어진 함수명/변수명으로 인해 80자가 넘어간다면, 길게 쓰지 않고 짧게 쓸 경우 혼돈이 생길 수 있는 상황에 놓인 것이 아닌가 고민 해보고, 별도의 함수로 분리하여 길이를 줄이는 것도 고려 해 볼 필요가 있다.

  3. 종이로 출력하거나 빔프로젝터로 보는 경우도 있다.

    가끔 종이로 출력해 코드를 읽어 본다던지, 코드 리뷰를 위해 여럿이 빔프로젝트를 통해 코드를 보는 경우가 있다. 종이는 크기가 한정되어 있고, 빔프로젝트는 해상도 및 폰트 크기의 제한이 있다. 이런 상황에서는 80 자가 넘어가는 경우 넘치거나 수평 스크롤을 하면서 봐야 하기 때문에 코드를 읽기 불편해진다.

세상 사람들이 나와 다른 선택을 했다면 그 선택을 따르지 않더라도 그 이유 정도는 살펴두는 것이 좋다.