첫 프로젝트를 완료하고 여러가지로 부족한 것들을 깨우쳤는데, 그중 하나가 규칙적이지 않은 코딩이었다.
주먹구구식으로 개발을 시작한 프로젝트는 처음 설계와 다르게 조금씩 살이 붙기도, 완전히 없어지기도 하였는데.
덕분에 정말 복잡한 구조의 스크립트들이 탄생했다.
그래서 읽게된 책 (쉽게 배우는 소프트웨어 공학 - 김치수)
https://product.kyobobook.co.kr/detail/S000001743818
쉽게 배우는 소프트웨어 공학 | 김치수 - 교보문고
쉽게 배우는 소프트웨어 공학 | 소설처럼 술술 익히는 소프트웨어 공학 중요하지만 다소 뜬구름 잡는 얘기 같았던 소프트웨어 공학 이론을 핵심만 추려 명쾌하게 정리해줍니다. 일상에서 흔히
product.kyobobook.co.kr
( 사실 코딩 규칙이나 UML같은 내용이 많이 적혀있겠거니 하고 읽기 시작했지만 기대와 다른 책이었다. 정말 전공 이론 느낌, 혼자 개발만 해본 초보 개발자인 내게는 먼 내용이었다. 하지만! ) Chapter7 구현 파트는 정말 기대만큼 좋았다 😁
이 책에서는 표준 코딩 스타일을 행정안전부가 발간한 '프로그램 표준 코딩 규칙'을 기반으로 설명한다.
규칙의 장점
- 가독성이 높아진다.
규칙없는 코딩에서 설계와 조금이라도 벗어나는 추가 사항이 생긴다면? 점점 알기 어려운 내 코드를 볼 수 있을 것이다
가독성이 높아짐으로써 연관된 여러 기능들의 관계가 한 눈에 들어오고, 추가 및 수정 또한 쉬워진다. - 간결하고 명확한 코딩이 가능하다.
뒤에 나오는 규칙을 살펴보면 필요하지않은 것들을 굳이 넣어두었던 과거가 떠오른다..
간결하고 명확하게 작성함으로써 가독성을 높이고, 이어서 1번과 같이 유지보수가 쉬워지는 장점이 따라온다 - 개발 시간을 단축시킨다.
간결하고 명확한 코딩으로 가독성을 높인다면 당연한 결과인 것 같다.
규칙 ( 전부 가져오면 너무 늘어지니.. 중요한 포인트만 가져왔다 - 게다가 c#해당만!! )
- 한줄의 길이는 80자 이내
- 함수의 내용은 70줄 이내
- 두줄로 넘어가는 코드가 있다면 쉼표를 기점으로, 둘째 줄은 ' ( ' 선에 맞춘다
- 코드의 첫 주석에는 다음 내용을 담는다
- 최초 작성자 , 최초 작성일, 최초 변경일, 목적, 개정 이력(변경자, 변경 일자, 변경 내용), 저작권 - 매서드 정의 앞에 다음 내용을 주석으로 추가하기
- 목적, 매개변수, 반환 값, 변경 이력
4.5번은 협업시에 하면 좋은 것 같다. 사실 안해도 깃으로 확인 가능해서 회사에 따라 달라질듯! - 용도가 같은 변수는 한 줄에 작성한다.
- 필요한 변수만 선언한다, (매번 유니티에 경고문이 뜨는 그것)
- 배열 초기화시, 차수에 따라 중괄호를 적절히 사용한다. ㅡ 가독성을 위해
- 8진수는 사용하지 않는다. 10진수나 16진수 표기법 사용하기
- 이항 연산자( + , - , * , / )는 전후에 공백을 넣는다.
- 삼항 연산자( ? : )는 맨 앞 수식을 괄호 '()'로 묶어준다.
- 증감 연산자는 다른 연산자와 섞어 사용하지 않는 것이 좋다.
- 연산자가 3개 이상인 경우, 괄호로 묶어주는 것이 좋다.
- 수식을 sizeof 함수의 인자에 사용하지 않는다.
- switch 문에서 case 문을 빠져나오기 위해 break문을 사용한다.
만약 break문이 없다면 다음 case문을 수행하게 됨.
그렇기 때문에 break문이 없다면 다음 case문으로 넘어간다는 사실을 주석으로 달기! - goto문을 사용하지 않는다.
- for문을 제어하는 수식에 실수 값을 사용하지 않는다.
- break문은 가능하면 한번만 사용한다. (동작 예측이 어려움)
여기까지 책에 적힌 표준 코딩 규칙을 알아봤다.
꽤 고민했던 내용들이 담겨있어서 진작 읽었으면 좋았겠다는 생각이 든다.. 그렇다면?
이참에 한걸음 나아가서 마이크로소프트에 올라와있는 c# 이름 지정 규칙에 대해 알아보자!
(Microsoft Learn - csharp - coding style)
https://learn.microsoft.com/ko-kr/dotnet/csharp/fundamentals/coding-style/identifier-names
C# 식별자 이름 - 규칙 및 규칙 - C#
C# 프로그래밍 언어에서 올바른 식별자 이름에 대한 규칙을 알아봅니다. 또한 .NET 런타임 팀과 .NET 문서 팀에서 사용하는 일반적인 명명 규칙을 알아봅니다.
learn.microsoft.com
우선 링크를 타고 들어가보면
" 컴파일러는 이를 강제하지 않습니다. 프로젝트에서 다양한 규칙을 자유롭게 사용할 수 있습니다."
라고 적혀있다. 굳이 지키지 않아도 되는 (권장사항인) 규칙이라고 하지만, 어느정도 일반적인 규칙을 따른다면 그 코드는 훨씬 명확해 질 것이라 생각하며 이어나가본다!!
- class, interface, struct 또는 delegate 형식의 이름을 지정할 때 파스칼 표기법을 사용
- 필드, 속성, 이벤트 등 형식의 public 멤버 이름을 지정할 때 파스칼 표기법을 사용
- 모든 메서드와 로컬 함수에 대해 파스칼 표기법을 사용
- private 또는 internal 필드 이름을 지정할 때 카멜 표기법을 사용하고, 프로퍼티의 경우 앞에 _을 붙입니다.
- 메서드 매개변수를 작성시 카멜 표기법을 사용
- interface 이름 앞에 I 를, enum 이름 앞에 E 를 붙힌다.
- const를 사용하는 경우 대문자 스네이크 표기법을 사용
- [클래스 내 멤버 변수와 메서드의 순서]
- public 멤버변수/프로퍼티
- internal 멤버변수/프로퍼티
- protected 멤버변수/프로퍼티
- private 멤버변수
- 생성자
- public 메서드
- internal 메서드
- protected 메서드
- private 메서드
- 코드 줄의 끝이 아닌 별도의 줄에 주석을 배치
- 마침표로 주석 종료
- 주석 기호와 텍스트 사이에 하나의 공백을 삽입
- 클래스, 인터페이스, 생성자의 이름은 명사
- 매서드의 이름은 동사 or 동사구 (동사 + 명사)
- Bool 반환 메서드의 동사 부분은 최대한 Is, Can, Has, Should를,
부자연스러운 경우에는 상태를 나타내는 다른 3인칭 단수형 동사를 사용한다. - 변수의 이름은 의미가 전달돼야함, 축약 XX
- Bool 변수 앞에 is
- 중복 이름 방지 (중복 예시) class : Player, 매서드 : PlayerScore, PlayerTarget
(나의 경험 기준으로 적은 내용이라 많은 것이 생략되었으나..)
여러 코딩 규칙들에 대해 알아보았다. 위의 규칙들을 활용해 나의 코딩 규칙을 정립해나간다면
언젠가는 코딩 고수가 되어있지않을까 생각해보며 글을 마친다😎
ps. 가장 많이 들여다볼 게시글이 될 것 같다.
