[병아리 C 프로그래밍, 카드뉴스] 3. 포스트 잇이 없다면 주석달자!
안녕하세요. 병아리 C 프로그래밍 강의를 진행하고 있는 Chan입니다.
오늘 포스팅은 주석처리에 관한 내용입니다.
설명 없는 코드는 사용 설명서 없는 제품과 같습니다.
심지어 자신이 쓴 코드도 시간이 지나면 알아보지 못하는 경우가 많으니 주석처리에 습관을 들여봅시다!
픽토그램 출처 (Source of Pictograms)
Slide 5
Men : Created by Hea Poh Lin from Noun Project
참고한 도서
윤성우 저 열혈 C 프로그래밍
다음 시간에는 printf 함수에 대해 다룰 예정입니다.
많은 보트와 코멘트, 팔로우 부탁드려요!! Please One Vote, Comment & Follow!!
또한 제가 정리한 내용에 대한 정정이나, 카드뉴스 디자인에 관한 피드백들도 언제나 환영입니다 :D
주석을 다느냐 마느냐는 Tab 을 4로 하느냐 8로 하느냐 만큼 이견이 많습니다.
저는 주석은 안달 수 있으면 안다는 것이 좋다는 주의입니다. (API 개발자는 예외)
주석을 봐야지 코드를 이해할 수 있다면, 코드를 이해하기 어렵게 작성한 것일수 있습니다.
그리고 추후에 코드를 업데이트 할 경우, 주석은 업데이트 하지 않아서 코드와 주석이 맞지 않는 경우가 종종 있습니다. 무척 해깔립니다.
주석도 코드의 일부입니다.
모든 코드는 잠재적 결함이 있다는 점을 이해한다면,
주석도 없는 것이 낫지 않나 생각해 봅니다.
주석을 봐야지 코드를 이해할 수 있다면, 코드를 이해하기 어렵게 작성한 것일수 있습니다. 이 의견은 정말 공감이 갑니다.
깔끔하게 잘 짜여진 코드는 알아보기도 쉽더라고요
너무 긴 주석처리는 좋지 않다는 내용을 슬라이드에 넣었어야 했는데, 그게 빠졌네요ㅠㅠ
좋은 의견 감사합니다!
외부에 공개되는 코드인 경우나 굉장히 많은 수의 인원이 같이 개발하는 경우 문서화를 위해서 주석을 다는 경우는 많습니다.
하지만 오히려 최근의 정석은 주석은 가능한한 최대한 달지 않는 것입니다.
그래서 함수의 이름이나 변수의 이름을 지을 때 최대한 이해하기 쉬운 방향으로 지어야 합니다.
주석을 달지 않아야 하는 이유는 코드를 수정하다보면 주석도 같이 수정해야할 필요성이 생기기 때문에 비효율적이고, 실수로 주석을 수정하지 않게 되면 코드 리딩에 혼란만 주게 되기 때문입니다.
생각해보니 저도 팀프로젝트 할때만 주석을 꼼꼼히 달았던 것 같네요!
나중에 Camel Case에 대해서도 한 슬라이드 만들어 봐야겠어요
좋은 의견 감사합니다ㅎㅎ
눈에 쏙쏙 들어옵니다 !! 저 태그해주셔도 되욤 : )
앞으로 많이 들러주세요ㅎㅎ