본문 바로가기

기타

Warning 무시하지 맙시다.

많은 프로그래머들이 컴파일러가 내는 경고(Warning)를 무시하고는 합니다.
가장 큰 이유는 경고가 있더라도 바이너리를 만들 수 있기 때문이겠지요.
또 나중에 고치지 하면서 미루다 보니, 프로젝트가 커지면서 점점 더 경고들이 많아 지기 시작하고, 나중에는 주루룩 쏟아 지는 경고들을 아예 보지도 않게 됩니다.
하지만 컴파일러 경고를 무조건 무시하면 안됩니다.
프로그래머들이 디버깅을 할 때 가장 어려운 케이스가 디버깅 툴이 전혀 힌트를 주지 않는 경우 입니다. 컴파일러 경고는 거저로 컴퓨터가 알려주는 디버깅 힌트입니다.
또한 경고를 잡다 보면, 마음가짐 때문이라도  전체적인 버그 발생 빈도가 줄어듭니다.

컴파일러 경고

우리가 주로 접하는 컴파일러 경고들은 다음과 같습니다.
unreferenced local variable: 변수를 선언하고 한번도 사용하지 않았습니다. 아주 위험하지는 않지만 다른 스코프에서 같은 이름의 변수를 설정하는 경우 등에 혼란이 생길 수 있습니다.
uninitialised variable: 변수를 초기화 하지 않고 사용했습니다. 이는 아주 위험합니다. 심각한 런타임 에러를 낼 가능성이 큽니다. 특히 VC++에서 디버그 모드와 릴리즈 모드의 실행이 다른 경우 이러한 문제에 기인 하는 경우가 많습니다.
conversion from 'XXX" to 'YYY': 묵시적 캐스팅을 하였으나 좌항에 있는 변수의 표현 능력이 우항보다 떨어지는 경우 입니다. 이 경우 역시 심각한 문제를 종종 일으킵니다.
이 외에도 컴파일러에 따라 if (a = 3) {} 과 같은 경우, 경고를 통해 (a == 3)의 오기(誤記)가 아닌지를 확인해 주기도 합니다.
깨진 창문 이론

범죄학자 제임스 윌슨(James Q. Wilson)과 조지 켈링(George Kelling)의 '깨진 창문 이론 (Broken Window Theory)'에 따르면, 깨진 창문을 수리하지 않고 놓아 두면, 그 근처를 지나는 사람들이 '이 집에는 아무도 책임지는 사람이 없구나'라고 결론을 내리게 되고, 이 결과 더 많은 창들이 깨지기 시작하면서 마침내 거리 전체가 무정부 상태가 된다는 것입니다.
이른바 낙서, 무질서, 구걸과 같은 사소한 문제들이 심각한 범죄를 일으킨다는 것이지요.
소프트웨어 개발에서도 이 이론이 적용될 수 있습니다. 컴파일러 경고와 같은 사소한 문제들이 심각한 소프트웨어의 불안정성을 일으킬 수 있다는 것이지요.
실천 방안
가장 쉬운 방법은 경고 에러가 보이면 보이는 즉시 고치는 것입니다. 미루다 보면 경고들이 쌓이게 되고, 나중에는 꽤 큰일이 됩니다.
그리고 이미 작업중인 코드에 경고들이 많이 나온다면 날을 잡아서 모두 해결하는 것이 좋습니다. 이 작업은 모든 팀원이 함께 하는 것이 좋으며, 같은 코드베이스에 대해 다른 개발 작업과 병행하지 않는 것이 좋습니다.
주의해야 할 것은, 경고를 모두 잡은 후에는 꼭 전체 제품에 대한 회귀 테스트(regression test)를 실시하여 새로운 문제가 나타나지 않았다는 것을 확인해야 합니다.
또한 컴파일러 옵션을 이용해, Warning이 있으면 컴파일을 중단하도록 하는 것도 좋습니다

 

--------------

프로그래밍 하면서 꼭 지켜야 할 부분인 것 같아서 가져왔습니다~

(주)이피파루스 Pdfpro의 대표님의 블로그에서 가져온 글입니다.

원본게시글링크 : http://www.pdfpro.co.kr/blog/jeong/13

여기에 가시면 더 좋은 글을 많이 보실 수 있습니다~