소스코드의 들여쓰기를 Tab과 Space 중에 무엇으로 하는가에 대한 이야기가 있다. 설문조사도 있고, github의 현황을 통계낸 자료도 있다. 업무로 개발중인 소스코드에서는 표준없이 마구 개발하다보니 통일되어 있지 않은데, 관련해서 생각을 정리해본다.
왜 통일하려고 하는가?
- 머지 리퀘스트 diff 중에 공백문자로 인한 불필요한 diff를 보기 싫어서
- 에디터 설정에 따라서 인덴트가 둘쑥날쑥하면 소스 보기 어려워서
- 마음속 깊은 곳의 불편함을 없에고 싶어서
- 그냥 해보고 싶어서
통일작업시 고려할 것은?
- Tab과 Space중 무엇으로 할 것인가? (개발팀의 의견 중요)
- Space로 하면 몇 칸으로 할 것인가? (2 or 4)
- Space를 Tab으로 바꾸면 Space 몇 칸을 Tab 1개로 할 것인지?
- Space 나머지는 어떻게 할 것인지? (ex: Space 4이 Tab1개인데, Space가 14칸일때 Tab은 몇개?)
- 바꾸고 나면 인덴트가 틀어지는데, 파일 전체의 자동 인덴트를 할 수 있을지?
통일작업 이외에 고려할 것은?
- 언제 BigBang 날짜를 잡을 것인가?
- 작업중인 feature 들은 어떻게 할지? (머지 리퀘스트 할때 conflict 날텐데 ㅠㅠ)
- 하는 김에 줄끝의 공백문자도 같이 지워주면 좋다.
- 하는 김에 줄바꿈 문자도 통일하면 좋다.
- 공백문자만 변경된 머지 리퀘스트는 공백문자만 바뀌었는지를 어떻게 보장할지?
- development에서 작업하고나서, 다음 master 머지전까지 master에서 변경되는 hotfix는 develoment로 어떻게 (자동으로) 머지할지?
통일작업 완료되면 할일은?
- 개발표준 문서/위키 변경 및 공지
- 모든 개발자의 에디터의 Save Action 설정 통일
- 커밋 훅 추가해서 안지켜진 소스는 reject
- 머지 리퀘스트에서는 머 해줄거 없을까....
- 작업 일지 남기기
댓글 없음:
댓글 쓰기