컴파일러 경고

많은 컴파일러는 잠재적 인 런타임, 로직 및 성능 오류에 대해 프로그래머에게 경고하기위한 경고 메시지를 가지고 있습니다.

수정 불가능한 경고를 어떻게 처리합니까? 코드의 일부를 다시 쓰거나 "길고 해킹없는 방식"으로 다시 쓰거나 경고를 모두 비활성화합니까? 가장 좋은 방법은 무엇입니까?

다른 사람의 코드를 편집하고 있고 그의 코드에 경고가있는 경우 어떻게해야합니까?

다음은 좋은 예입니다. jQuery에는 Mozilla 클래스 브라우저가 감지 한 것처럼 많은 JavaScript 경고가 있습니다. 왜 jQ 개발자가이를 수정하지 않습니까? jQuery에 기여한다면, 그것들을 고치겠습니까?

일부 경고는 일반적으로 무시해도 안전 하지만 시간이 지남에 따라 시간이 지남에 따라 소음에 숨겨져있어 실제로 중요한 경고를 놓치게 될 날이 너무 많아 질 때까지 그 수가 곱해질 것입니다.

경고를 즉시 수정하십시오 ( 상황과 관련 이 없다고 생각되면 개별 규칙을 사용하지 못할 수도 있음 ).

내 의견은 당신이 자신에 대해 엄격해야한다는 것입니다. 이 컴파일러는 언어 전문가들에 의해 작성되었습니다. 그들이 뭔가 이상한 것을보고하는 경우 (코드 냄새를 생각) 코드를 검토해야합니다.

오류없이 경고없이 컴파일되는 코드를 작성하는 것은 전적으로 가능합니다.

C 및 C ++로 작성할 때 컴파일러에 어떤 의미가 없는지 알고 싶었 기 때문에 가능한 가장 엄격한 설정을 사용했습니다. 반환 값을 캐스팅하고 확인하면 코드가 정확하기 때문에 기쁠 것입니다.

때때로 경고를 흘리는 다른 사람으로부터 코드를 얻었습니다. 소스를 확인한 결과 C에서 좋은 프로그래밍 관행 인 것을 무시하고 코드를 깨지기 쉬운 것으로 나타났습니다.

따라서 엄격함을 활성화하고 문제를 해결하는 데 시간이 걸리는 좋은 이유가 있다고 생각합니다. 그렇지 않으면 조잡합니다. 내가 경고를 끄는 동료가 있다면 나는 그들과 시간을 보내고 관리자가 왜 그렇게 나쁜지를 설명 할 것입니다.

경고를 고칠 것입니다. 당신이 그들을 무시하고 축적하자면, 당신은 실제로 중요한 것을 놓칠 수 있습니다.

일반적으로 새로운 경고가 더 많이 표시되도록 컴파일러를 자동으로 만드는 데 노력해야합니다. 이러한 경고는 미묘한 버그를 나타낼 수 있으므로 적절히 처리해야합니다.

다른 사람들의 코드를 수정하는 것과 관련하여 직장 문화와 코드의 현재 상태에 크게 의존합니다. 테스트 단계 또는 프로덕션 단계의 코드와 마찬가지로 전체 테스트주기를 트리거하는 코드 만 변경할 수는 없습니다.

상사에게 물어보고 그에 따라 행동하십시오.

컴파일러 경고가 표시 될 때마다 고객 사이트에서 실제로 대기하는 것이 문제인지 아니면 무시할 수있는 문제인지 생각해야합니다. 더군다나, 오늘 무시할 수있는 것은 외관상 관련이없는 코드 변경이 발생한 후 몇 년 안에 고객의 사이트에서 폭발 할 수 있습니다.

경고를 수정하십시오. 기간. 그것이 위험하지 않다는 것을 증명하는 데 필요한만큼의 설명 페이지와 함께 좋아하는 여자 친구 (또는 포르노 보관소)에 판매 주문서가 첨부 된 것으로 판명되거나 위험이 있었다.

일반적으로 빌드에는 경고가 없어야합니다. 경고는 이유가 있으며 종종 실제 문제를 지적합니다. 컴파일러 경고를 무시하는 습관을들이는 경우 결국에는 빌드에 많은 경고가 발생하며 회사에 막대한 비용이 소요되는 치명적인 문제로 인해 발생하는 경고를 놓치게됩니다. 반면에 프로그램이 일반적으로 경고없이 컴파일되면 모든 새 경고가 즉시 확인되고 신속하게 해결할 수 있습니다.

그러나 컴파일러는 때때로 의미가없고 쉽게 고칠 수없는 경고를받을 수 있습니다. TI DSP를위한 개발 환경 인 TI CodeComposer와 함께 일하면서 매일 이러한 상황에 직면하고 있습니다. Visual Studio에서 경고없이 컴파일되는 C ++ 코드가 있지만 표준 C ++에 대한 TI의 지원이 더 좋기 때문에 CodeComposer에서 이상한 경고가 발생합니다. 운 좋게도 CodeComposer를 사용하면 특정 경고를 개별적으로 비활성화 할 수 있습니다. 이는 경고를 생성하는 코드를 수정할 방법이 없을 때해야 할 일입니다.

필자의 경우 PyLint 도구에서 경고가 발생하며 주석에 특수 텍스트를 추가하여 특정 줄에서 경고를 비활성화 할 수 있습니다.

대부분의 경우 그렇게하지 않습니다. 대부분의 경우 PyLint가 일반적으로 정확하기 때문에 PyLint가 제안하는 것을 따르도록 코드를 변경합니다. 그러나 싫어하는 경우 일반적으로 좋지 않은 아이디어이지만 특정 상황에서는 의미가있는 구문입니다. 예를 들어 가능한 모든 예외를 잡으면 불평합니다. 보통은 맞습니다. 나쁜 생각입니다. 그러나 어떤 경우에는 세부 정보가 포함 된 오류 보고서를 보내는 것과 같은 모든 예외를 포착하고 싶습니다.

거의 모든 경우에 해킹을 제거하십시오. 해킹이 실제로 정당화되면 PyLint에게 괜찮다는 의견을 추가하십시오.

엄격 성의 이점 중 일부는 다른 답변에서 명확하게 언급되지 않았습니다.

1. 쉽게 고칠 수있는 모든 경고가 수정되면 나머지 중요 / 관련 경고가 나타날 가능성이 높습니다.
2. 관련 경고가 발견되어 정시 (출시 전)에 처리되면 버그를 피할 수있어 최종 사용자 만족도가 향상됩니다
3. 경고를 해결하면 일반적으로 유지 보수가 쉽고 코드가 간단 해집니다 (예 : 항상 참인 조건 제거).
4. 경고의 양이 0에 가까워지면 팀의 제로 경고 정책에 동의하기가 쉬워 CI 시스템에서 자동화하기가 매우 쉽습니다.
5. 컴파일러 경고를 해결할 때 프로그램 코드에 대한 이해가 심화되어 구현에 대한 유용한 통찰력을 얻을 수 있습니다 (예 : 다른 버그를 발견하거나 코드를 더 개발하는 방법에 대한 아이디어를 얻음)
6. 빌드 속도가 빨라지고 매일 생산성이 향상됩니다. IDE / 컴파일러는 관리 및보고에 대한 문제가 적으므로 컴파일 속도가 빨라집니다 (이는 수천 가지 경고와 관련이 있습니다).

특정 종류의 경고에는 언어 별 차이가 있습니다. 나는 그 주제에 대해 생각하고 토론 한 다음 완전히 쓸모 없다고 느낄 때 개별 경고를 비활성화하는 것이 중요하다고 생각합니다. 이것은 내 경력의 여러 팀에서 이루어졌습니다. 주제에 대한 내 경험에 대한 추가 정보

경고와 오류는 컴파일러가 프로그래머에게 "당신이 작성한 것이 이해가되지 않았다"고 알리는 데 사용하는 메시지입니다. 경고와 오류의 차이는 컴파일러가 프로그래머의 의도를 추측 할 수 있다는 것입니다. 오류가 발생하면 컴파일러는 추측조차 할 수 없습니다.

컴파일러 오류가 해결 되지만 ( 고정 이라고 말하지 는 않겠지 만) 너무 자주 프로그래머 (심지어 숙련 된 프로그래머)도 경고를 무시합니다. 경고를 무시하는 문제는 때때로 컴파일러가 잘못 추측 하고 1000 개 이상의 경고 메시지가 표시되면 컴파일러가 잘못 추측한다는 경고 메시지를 놓치기 쉽다는 것입니다.

사회학적인 관점에서 경고 메시지가 많은 프로그램은 Broken Windows 입니다.