Default constructor는 꼭 만들어야할까?

문제

팀원과 코드리뷰를 하다가 이런 이야기가 나왔다.

팀원: “Default constructor가 아무 행동도 하지 않는거라면 (i.e. 초기화만 하는거라면), 굳이 Class() = default라고 적어야할까요? 이거 굳이 코드 줄만 잡아먹는거 같은데요”

적자니 코드 줄을 잡아먹고, 안적자니 뭔가 이상하다.

그래서 ‘적는다’ vs ‘안 적는다’에 대한 의견을 찾아봤다.

 

---

결론

‘취향에 따라서… ㅋㅋ‘
나는 안 적는 쪽으로 골랐다.

적었을 때의 이점도 있고, 안 적었을 때의 이점도 있다.

 

적었을 때의 이점 + 단점

Default constructor를 명시적으로 적지 않으면, 추후에 누군가 다른 constructor를 만들었을 때 default constructor가 사라지면서 코드가 터질 수 있다. 물론 제대로 test code를 작성했다면 이 버그는 production으로 가지 않을 것이고, test code가 터지는 걸 보고 그때 가서 default constructor를 추가해주면 된다.

Class() {}를 적어주면 (컴파일러에 따라 다르지만) 컴파일러가 최적화 된 방식을 사용하지 않는다고 한다. 대신 이는 Class() = default를 적어줌으로써 최적화 된 방식을 사용할 수 있다.

어떠한 형태로던지 default constructor를 명시적으로 적으면, 아주 짧지만 적는시간 + 읽는시간이 소요된다. 하지만 반대로, default constructor가 있는 방식을 선호하는 프로그래머들은 이걸 찾느라 시간을 더 쓰게 된다.

 

그래서 안적는 방향으로 고른 이유

우리 팀은 TDD 개발 방식을 선호한다.

그러다보니, default constructor를 명시적으로 적지 않은 상태에서 누군가 다른 constructor를 만들어도 code review 전에 test가 터지는 코드를 다 잡아낼 수 있을 거란 자신이 있다.

또, 어차피 코드 리뷰를 할 때 테스트 코드부터 읽으면서 시작한다. 테스트 코드에서 parameterless constructor가 필요하다고 생각된다면, 그렇게 제안을 할 것이다. 그 때 가서 default constructor가 필요한지, 아니면 paramterless constructor가 필요한지 결정할 수 있다. 그 후, 안쓰는 constructor는 CI에서 도는 static-analysis가 제거하라고 알려줄 것이다.