다른 사람이 볼 수있는 소스 코드를 공개 할 때 코딩 스타일이 잘 정의되어 있지 않을 때 (의도적 인 말장난 없음) DEBUG 파트 #ifdef을 제거합니까? 정말 누군가가 내가 디버깅 것을 알고 싶어 - 릴리즈를 위해 #ifdef 디버그 부분을 제거 하시겠습니까?
(즉, DEBUG가 정의 된 경우에만 컴파일되는 부분입니다) 그리고 어떻게했는지), 디버그 부분을 잃어 버리거나 2 개 (또는 그 이상)의 코드를 유지해야합니다.
무엇을해야합니까?
디버깅 코드가 깨끗하고 모든 로깅 문에서 "전문적인"언어를 사용하고 있다면 괜찮다고 생각합니다. 디버그 코드가 엉망이거나 "여기 있습니다 ..."와 같은 디버그 메시지가있는 경우, ""나는 지금 여기있다 ... "당신은 그것을 꺼내야합니다.
디버그 진술서에는 알아낼 수없는 문제가 있다는 사실이 반영되어있는 경우 소프트웨어를 다른 사람에게 "판매"하려는 경우 디버그 진술서를 꺼내는 것이 가장 좋습니다. (잘하면 나중에 해결할 수 있기를 바랍니다 ...)
해설에 추천 할 수없는 언어를 사용하지 않는 한 코드를 그대로 두어야합니다. 누군가 당신의 코드를 사용한다면, 코드를 필요로하거나 코드를 이해하는 데 도움이 될 것입니다. (이것은 논평에도 해당됩니다.)
편집 : 나는 과거에 종종 다른 스튜디오 코드를 사용했습니다. 디버그 코드, 죽은 경로 및 기타 많은 것들을 보았습니다. 여전히 싫어하는 것은 디버그 및 주석 코드를 제거하는 사람들이었습니다. 따라서 코드를 유지하기가 어렵습니다.
제거하기로 결정하면 , 코드를 내보낼 때 스크립트로 필터링하면 두 버전을 유지할 필요가 없습니다.
좋은 생각입니다! –
첫 번째 패치에서 작업을 시작하면 그 디버그 차단 된 조각이 필요할 것입니다. 또한 지시문에서 차단 된 경우에도 코드를 삭제했다고 QA는 좋아하지 않습니다.
소스 코드 관리 시스템의 모든 것을 기본 버전으로 유지하십시오.
그런 다음 하나 이상의 방법으로 필터링 된 소스 코드를 배포하려면 소스 코드의 릴리스 버전을 만드는 스크립트를 만드십시오.
이러한 2 차 필터링 리포지토리를 유지 관리하지 마십시오. 항상 생성되어야합니다.
하지만 시간이 가치가 있습니까? 아마도 #ifdef DEBUG 부분을 포함한 모든 것을 배포해야 할 것입니다.
ANYTHING의 여러 버전을 유지 관리하는 것은 바람직하지 않습니다.
은이어야합니다.
비전문적 인 디버그 코드를 모두 살펴본 다음에는 전문화하고 남겨 둘 수 있습니다. –
다니엘에게 +1하십시오. 감사. – Otis