빌드 및 분석이 완벽하지 않은 것을 여러 번 읽었습니다. 코드를 실행하면 유용한 정보가 나오고 코드가 확실히 향상되었지만 문제가 아닌 결과도 얻을 수 있습니다. 분량에 상관없이 문제가 있는지 여부에 관계없이 모든 분석기 결과를 제거하기 위해 코드를 변경하고 있습니다. 경고와 마찬가지로 문제가 있는지 쉽게 확인 할 수 있거나, 분석기가 완벽하지 않고 정품 문제가 발견되지 않는 한 코드를 변경하지 않는다는 것을 인식해야합니까?빌드 및 분석을 실행할 때 분석기를 사용하지 않아야합니까?
우선 모든 컴파일러 경고는 런타임에만 표시되는 오류입니다. 그들은 편집을 막지는 않지만 결국에는 심각한 문제를 야기 할 것입니다. 빌드 설정으로 가서 "경고를 오류로 처리"를 확인하고 결과 오류를 수정해야합니다. 그렇지 않으면 결국에는 문제를 해결하기 위해 열심히 노력할 것입니다.
분석기가 완벽하지는 않지만 발견 된 문제를 면밀히 검사해야합니다. 코드에서 발견 된 문제는 수정해야합니다. 때로는 API에서 오류를보고하기 때문에 API에 대한 오류가있을 수 있습니다.
대부분의 경우 컴파일러 단계의 오류를 무시하면 "페니는 현명하고 시간이 절약됩니다". 선행을 저장할 때마다 나중에 디버깅을 잃게됩니다.
그래, 나는 컴파일러가 보지 못하는 경고/오류를 제공하는 uber-compiler로 정적 분석기를 생각하고 싶다. 그것이 완벽하다고는 말할 수 없으며 거짓 긍정 또는 2 번을 보았지만 99 %의 시간을 보았습니다. – Alex
예 - 이상적으로 분석 프로세스에서 제기 된 모든 문제를 수정하고자합니다.
그러나 clang은 훌륭하지만 완벽하지는 않습니다. 때로는 위양성을 높일 수도 있습니다. 이러한 경우가 확실하고 진단에 오류가있는 경우 오류를 나타내는 가능한 가장 작은 테스트 사례를 다시 작성하고 http://clang-analyzer.llvm.org/filing_bugs.html에 제출하여 분석 엔진을 향상시킬 수 있도록해야합니다.
오탐 (false positive)보고 제안에 +1. –
위의 답변에 대한 예외는 가비지 수집을 사용할 때입니다. 이 경우 분석기는 여전히 누출 가능성을 보여 주지만 자연스럽게 가비지 수집을 사용할 때는 적용 할 수 없습니다.
GC 지원 (필수 아님) 또는 보유 해제 모드 또는 유지 모드의 앱으로 프레임 워크를 컴파일하는 경우 잠재적 누출에 대해서만 경고합니다. 그래도 GC로 컴파일 된 앱의 경우 해당 컨텍스트에서만 코드를 평가합니다. –
"유용"하고 "불필요한 문제"라고 할 때의 의미를 보여주는 예를 제공 할 수 있습니까? –