C# - 들여쓰기

• 들여쓰기에는 TAB 을 사용한다. SPACE를 사용하지 않는다. TAB사이즈는 4로 정의한다.

들여쓰기를 TAB 을 사용하는 것 까지는 공감하나, TAB 사이즈의 크기는 프로젝트를 진행하기전에 공통된 룰을 설정 하는게 좋다.

Github 의 Gist 의 경우는 TAB 사이즈가 2로 기본 초기화 되어있다. 또 한, 많은 오픈소스들이 2 또는 4로 TAB 사이즈로 되어 있다.

• 주석은 코드와 같은 레벨에 있어야 한다. (들여쓰기의 레벨을 같이 사용한다.)
  
• 누군가 슈퍼 개발자가 그랬다. 주석이 없어도 이해되는 소스가 가장 좋은 소스라고... 하지만 이슈 형상관리 차원에서 주석은 중요한 역할을 한다.
• 주석에 코드 레벨에 위치가 중요한 것이 아니라 JIRA 이슈 번호나, MANTIS 이슈 번호를 넣어서 해당 이슈를 왜수정 했는지 추후 문제가 생겼을 때 파악 할 수 있는 수단을 제공하는 것이 좋다고 생각한다.
• 주석에 날짜를 기록하는 것도 이슈 파악에 도움이 된다고 생각한다.
• 나쁜 예)
• 좋은 예)
• 이슈, 날짜 추가 된 예)

• 중괄호는 중괄호 밖에 있는 코드와 같은 레벨에 있어야 한다.

• 논리적인 코드 그룹은 다른 코드와 한칸 띄어서 구분한다.

• 중괄호는 다른 라인과 분리되어 있어야 하며 라인을 같이 쓰면 안 된다.
  
• 해당 룰은 프로젝트를 진행하는 팀과 공통 된 룰을 정하고 진행 해야 한다. 개발자 마다 스타일이 다르고 가독성을 바라보는 차이가 다르기 때문에 어떤 것이 좋다고 단정 할 수 없다.

• 중괄호 분리 예)
• 중괄호 분리 하지 않은 예)

• 지시자(operator)와 괄호 앞, 뒤로는 한칸의 공간을 남긴다.
  
• 가독성을 위해서 필요 하다. 조건 문내부에서  논리 연산자를 사용하는 경우에 큰 힘을 발휘 한다.
• 해당 룰을 적용해도 보기 어렵다는 개발자도 있는데, 이런 개발자들은 개발언어의 폰트를 바꿔서 사용한다. 소문자 l(엘) 과 대문자 I(아이) 그리고 논리 연산자 |(OR 연산자) 구분하기에는 확실히 폰트 변경이 가독성이 더 좋다.
• 예)

• 연관된 코드를 묶을때는 #region을 사용해라. #region을 사용해서 묶는다면 그 페이지는 훨씬 간략해질 것이다.
• 코드를 감추기 위해서 사용하는 용도이며 더 이상 수정을 진행하지 않는 메소드에 사용하는 것이 좋다. 문제점 수정에 빈도가 높은 메소드에는 불필요 하다.
• 원칙적으로 수정이 많은 메소드는 설계 단계에서 요구사항을 정확히 파악하지 못한 문제도 크다.

• private 멤버 변수, 속성, 메소드는 파일의 상단에 그리고 public 멤버들은 파일의 하단에 위치 하도록 한다.
  
• 이것도 중요하다. private 에 위치가 위 아래가 중요한게 아니라 지속적으로 유지 되는지가 중요하다. 필요할 때 마다 룰을 어기는 경우가 많다.
• 지속적인 코딩 교육 및 리뷰를 통하여 진행해야 하는 부분이다.