코딩을 할 때 인덴트를 탭(Tab)으로 할 지 공백(Space)으로 하는지에 대한 논쟁은 중괄호 위치 문제와 함께 유명한 고전 떡밥(?)중 하나입니다. 서로 장단점이 있지만, 정답은 '프로젝트의 코딩 컨벤션에 따라 일관되게 적용'이 되겠죠. 물론 개인 프로젝트일 때는 마음대로 해도 상관이 없겠지요.
제가 선호하는 인덴트 방법은 Tab을 사용하는 것입니다. 특별히 컨벤션을 규정하지 않은 개인 프로젝트에서는 가급적 인덴트를 Tab으로 처리합니다.
Space를 쓰면 어떤 에디터에서도 일관되게 보이게 할 수 있다는 점이 최장점으로 꼽힙니다. 하지만, Vim과 Emacs를 포함한 오늘날 대부분의 에디터에서는 화면에 표시되는 Tab 문자의 크기를 설정할 수 있는 기능을 제공하므로, 오늘날 들어서 그닥 의미있는 장점은 아니라고 생각합니다. 더불어 의미있는 구문들의 줄을 맞추려고 할 때는 Space보다는 Tab이 편하다는 점은 부정할 수 없는 사실입니다.
아무래도 인덴트를 Tab으로 함으로써 얻을 수 있는 가장 큰 장점은 줄의 시작 부분에 라인 주석(//)을 쓸 때가 아닌가 합니다. Tab을 쓰면 주석을 쓰기 전후에 코드부분의 줄이 어긋나지 않습니다. 예를 들면,
공백(Space)을 쓸 때:
탭(Tab)을 쓸 때:
예시에서는 한 줄만 주석을 처리해서 별로 차이가 없어 보이지만, 디버깅 과정에서 여러 줄을 주석 처리해놓고 하나씩 지워가면서 제대로 동작하는지를 확인할 때는 2칸씩 어긋나 있는 것이 상당히 거슬려 보입니다.(이런 방식의 디버깅은 JTAG을 사용할 수 없는 임베디드 보드의 펌웨어를 작성할 때 자주 사용합니다.)
이런저런 계기로 인해 중괄호 위치 등 제가 선호하는 코딩 컨벤션이 지속적으로 바뀌어 왔지만, 이 인덴트 방법만은 처음부터 계속 Tab만 사용해 왔던 것 같습니다. 개발자들의 전체적인 추세로는 인덴트로 Space를 더 많이 사용하는것 같던데, 그래서인지 제가 오픈소스등을 가져다 쓸 때 가장 먼저 하는 작업이 인덴트를 다 Tab으로 바꾸는 작업입니다. 오늘날에는 에디터에서 한큐에 해결할 수 있으므로 그닥 시간과 노력이 드는 작업도 아니게 된 것이 천만 다행입니다.ㅎㅎ
어제 개인 Git Repository로 사용하고 있는 GitLab의 대대적인 업데이트 작업을 강행하였습니다. 무려 7.4 에서 8.9 버전으로 업데이트 했는데, Major버전이 바뀐 만큼 눈에 띄는 많은 변화가 있었습니다. (심지어 로고까지 바뀌었습니다.. 적응(?)하려면 시간이 좀 걸릴..)
GitLab 자체에서 제공하는 자동 업데이트 기능을 사용했으면 쉽게 했을텐데, 이게 64bit 에서만 가능하다보니 아직 32bit에서 벗어나지 못하고 있는[...] 제 개인 서버에서는 그 과정을 모두 수동으로 진행해야만 했습니다. (어제 빌드만 전부 몇 번을 했는지... 현 시점까지 무려 8년째 가동중인 코어2듀오노인학대에 애도를..)
우여곡절 끝에 업데이트를 완료했는데, (당연한 현상이지만) 제가 임으로 바꿔서 쓰고 있던 4칸 Tab크기가 도로 8칸으로 돌아와 있었습니다. 예전에 한 번 고쳐놨었는데, 그게 업데이트를 하면서 전부 초기화 된 것입니다.
▲ Tab 크기가 8로 기본설정되어 있는 GitLab 코드리뷰 화면
안타깝게도?아쉽게도? GitLab에서는 설정에서 코드리뷰 페이지에 보이는 Tab문자의 크기를 조정하는 기능을 제공하지 않습니다. 이걸 바꾸려면 GitLab의 FrontEnd를 직접 고쳐야만 합니다. 하지만, 흔히 이럴 때 쓰는 방법을 적용해서 브라우저의 개발자 도구([F12])로 찾은 CSS파일(application-xxx...xxx.css)을 서버의 파일시스템에서 찾아 수정하면 아무 일도 일어나지 않을 것입니다.[...]
이유는 GitLab의 FrontEnd에서 CSS파일을 그대로 전송하는 것이 아니라, 해당 파일을 압축한 application-xxx...xxx.gz를 전송하기 때문입니다. 따라서 application-xxx...xxx.css를 찾아서 수정하고 이를 압축해서 같은 디렉토리에 application-xxx...xxx.gz로 생성해 놓아야 비로소 변경사항이 적용됩니다.
위 방법이 제가 지난번에 사용했던 방법이고, 이번에는 조금 더 깔끔한(?) 방법을 사용했습니다. 사실 위의 application-xxx...xxx.css나 application-xxx...xxx.gz는 상위 CSS Template으로부터 일종의 컴파일 과정을 거쳐 생성된 결과물로, 본디 이를 직접 수정하는것은 권장되지 않습니다. 이를 수정하는것은 한마디로 임시방편이라 할 수 있고, 변경사항이 내부적인 동작으로 인해 언제든지 날아갈 가능성이 있습니다. 한마디로 프로그램을 수정하는데 소스코드를 수정해서 다시 빌드하는게 아니라 바이너리를 직접 뜯어고치는[...]것과 같다고 할 수 있습니다.
GitLab의 FrontEnd를 구성하는 CSS는 Sass(Syntactically Awesome Style Sheets)를 사용해 제작되었습니다. 기존의 CSS는 문법이 지저분하고 중복이 많아 작성 과정이 비효율적이므로, 이를 상위 레벨의 Template에서 깔끔하게 정의해놓고 이를 컴파일해서 CSS파일을 자동으로 생성해 내는 것입니다. Template 파일(*.scss)의 문법은 CSS와 비슷하지만 보다 높은 수준의 추상화와 확장 문법을 제공합니다.
이 글에서는 CSS파일을 직접 수정하기보다는, Sass의 CSS Template파일을 찾아서 수정하고 이를 컴파일해서 CSS파일을 생성해내는 방법에 대해 설명합니다. 비록 Tab 크기를 8에서 4로 바꾸는 내용에 대한 설명이지만, 혹여 추후에 FrontEnd를 커스터마이징할 경우에도 유용하게 활용할 수 있을 것입니다.
GitLab 정지
sudo service gitlab stop
CSS Template파일 수정
/home/git/gitlab/app/assets/stylesheets/application.scss 파일을 열고 맨 아래에 다음 구문을 추가합니다.
pre.code, table.code { -moz-tab-size: 4; -o-tab-size: 4; tab-size: 4; }
pre.code와 table.code는 각각 코드리뷰 페이지와 Commit View 페이지의 소스코드 영역에 해당하는 CSS Selector입니다.
Asset 재컴파일 수행
변경사항을 적용하기 위해 Asset을 다시 컴파일합니다. 이 과정에서 scss파일로부터 css파일이 생성되고, 이를 압축한 gz파일이 생성됩니다.
이 명령은 /home/git/gitlab 디렉토리에서 실행해야 합니다.
cd /home/git/gitlab sudo -u git -H bundle exec rake assets:clean RAILS_ENV=production sudo -u git -H bundle exec rake assets:precompile RAILS_ENV=production
GitLab 시작
sudo service gitlab start
GitLab을 재시작하고 코드리뷰 화면에 접속해보면 다음과 같이 Tab 크기가 4로 바뀐 것을 확인할 수 있습니다.
▲ Tab 크기를 4로 바꾼 이후 GitLab 코드리뷰 화면