데드 코드 작성이 유용한가요?

데드 코드 작성이 유용하다고 생각하십니까?

일부는 "일부 작업을 수행 할 논리가 2 개인 경우 다른 논리 코드에 주석을 달거나 코드를 제거하는 대신 작업에 영향을 미치지 않으므로 코드를 데드 코드로 만듭니다"라고 말합니다.

예:-

if(true){
    // logic - 1
} else {
    // logic - 2  // dead code
}

사실인가요?

나는 보통 데드 코드를 쓰지 않고 두 번째 논리를 제거합니다.

IMO, 그것은 무의미한 것보다 더 나쁘다.

시간 낭비 일뿐만 아니라, 당신 (또는 다음 사람에게) 당신은 당신이 변경하는 경우 작동하는 몇 가지 코드를 가지고 있다는 환상 제공 true에를 false. 테스트하지 않는 한 환상 일뿐입니다.

그리고 물론, 코드를 읽기 어렵게 만드는 것은 복잡합니다.

SCM 데드 코드를 사용하면 거의 유용하지 않습니다. 대신이를 삭제해야하며 로직 2의 코드를 볼 필요가있는 경우 SCM 저장소에서이를 검색하십시오.

편집하다:

데드 코드가 있고 코드의 다른 부분을 유지 관리하는 경우 데드 코드를 켤 수있는 일부 코드를 사용하려고 시도 할 수 있습니다. 다른 사람이 유지 관리를 수행하는 경우 실제로 죽은 코드를 알지 못할 수도 있고 코드를 작성하더라도 그 이유가 무엇인지 알 수 없습니다.

"라이브"코드가 아니라 데드 코드에서만 사용되므로 메소드를 삭제할 수 있다고 생각되면 데드 코드를 변경 (및 대부분 중단)하거나 다른 메소드를 데드 코드 자체로 만들어야합니다.

결국 어떤 형태의 유지 보수 지옥으로 끝나게 될 것입니다.

따라서 최상의 결과는 잘못된 결과를 생성하거나 관리자를 산만하게 할 수 없기 때문에 삭제 된 코드입니다. :)

아니요, 코드가 복잡해지고 유지 관리 성이 떨어지기 때문에 나쁩니다.

일반적으로 대체 "논리"중 하나를 선호하는 분명한 이유가 있습니다. 이 이유 (및 거부 된 대안의 존재)는 코드 주석에 문서화해야합니다. 이유가 유효하지 않은 비교적 드문 경우에, 대체 코드는 저장소 히스토리 (이전에 선호되고 구현 된 솔루션 인 경우)에서 검색되거나 현재의 전체 지식 및 요구 사항 (모호한 경우)을 사용하여 구현 및 구현 될 수 있습니다. 생각).

작동에는 영향을 미치지 않지만 유지 관리에는 영향을줍니다. 유지 관리하기 쉽도록 코드를 최대한 깔끔하게 유지하려고합니다.

나는 당신이하는 일에 정직하게 혼란 스럽습니다.

내림차순으로 :

1. 새 코드가 작동하지 않으면 비교할 수 있도록 코드 변경 기록을 어딘가에 보관해야 합니다. 이것은 항상 소스 제어에 있어야합니다. 나는 당신이 이미 이것을 가정합니다. 그렇지 않은 경우 소스 제어의 일부 형태를 얻기 위해 가능한 모든 작업을 수행하십시오. 당신이없이 절대적으로해야 할 경우 (그리고 이것이 좋은 생각 일 때를 들어 본 적이없는 경우) 최소한 소스의 상태를 정기적으로 백업하여 쉽게 액세스 할 수 있도록하십시오.

2. # 1을하고 있다고 가정하면 필요한 경우 데드 코드를 복구 할 수 있으므로 라이브 코드를 장기적으로 유지하지 마십시오. 혼란스럽고 가치가없는 추가 복잡성을 추가하고 유지 보수가 필요하며 라이브 코드와 동기화되지 않고 미래의 사람들을 오도하는 등

3. 즉, 두 코드 경로 사이의 컴파일 타임 전환이 합리적인 특정 상황이 있습니다. 새 코드를 개발하는 중이 자 곧바로 두 코드를 모두 사용하는 것이 불편할 수 있으므로 쉽게 전환 할 수 있습니다. 다시 전환하거나 외부 구성 옵션을 추가해야 할 경우 상수를 기반으로 한 if는 합리적인 업그레이드 경로를 제공합니다. 따라서 많은 문제가 있습니다. 특정 문제를 해결하는 경우 해결하십시오. 그렇지 않으면 피하십시오.

내가 사람들에게 너무 많은 일을한다고 생각하는 이유는 : 사람들이 문제가있는 경우 실제로 소스 제어 기록을 읽게 될 것이라는 의심 (종종 정확하게)으로부터; 새로운 코드가 작동하지 않고 쉽게 복귀 할 수있는 옵션을 원 할까봐 두려워했습니다. 두 가지를 모두 충족시키려는 타협은 "(날짜) 변경 계산 ... (날짜). 문제가 있으면 소스 컨트롤의 이전 버전을 참조하십시오."

아니요, 유용하지 않습니다. 그 else블록은 어떤 목적도 달성하지 못합니다. 어떤 구현을 사용해야할지 확실하지 않은 경우 주석 처리하거나 별도의 클래스를 만들거나 다른 곳에 저장하십시오. 또한 대부분 소스 파일의 로컬 또는 원격 히스토리가 있거나 최소한 있어야합니다.

조건이 컴파일 시간 상수에 의존하는 경우 컴파일러가 죽은 코드를 제거해야하므로 기술적으로 유지하는 데 아무런 문제가되지 않습니다. 그러나 코드의 가독성을 향상시키기 때문에 주석 처리하는 것이 좋습니다.

두 코드 대안을 빠르게 전환하려면 다음과 같은 편리한 주석 구성을 사용할 수 있습니다.

//*
alternative 1 is active
/*/
alternative 2 is commented out
//*/

/첫 번째 주석 행에서 첫 번째 행만 제거하면 다음 과 같이됩니다.

/*
alternative 1 is commented out
/*/
alternative 2 is active
//*/

이를 통해 /코드에서 단일 을 추가하거나 제거하여 대안을 전환 할 수 있습니다 .

처음에는 조금 이상하게 보일지 모르지만 일단 익숙해지면 일종의 패턴으로 쉽게 인식 할 수 있습니다.

이것을 연결하여 단일 문자로 여러 블록을 한 번에 전환 할 수도 있습니다.

//*
first block of code for alternative 1
/*/
first block of code for alternative 2
/*/
second block of code for alternative 1
/*/
second block of code for alternative 2
//*/

나는 이런 식으로 사용하지 않지만 작동합니다.

이전 코드와 대체 된 사실은 아주 드문 경우이며, 미래의 프로그래머에게 반 직관적 인 것에 대해 경고 할 수 있도록 소스 코드를 그대로 유지해야합니다. 어떤 경우에, 왜 여전히 존재하고 어떤 일이 일어 났는지 설명하는 일종의 해설이 필요합니다.

항상 그렇듯이 유지 관리가 쉬운 프로그램을 작성하는 것은 어렵고 빠른 규칙을 따르는 것이 아니라 더 명확하게 만드는 것입니다. 데드 코드를 그대로두면 진행 상황을보다 쉽게 ​​이해할 수 있으며 그대로 두십시오. 그렇지 않은 경우 꺼냅니다.

컴파일러에서 무시됩니다. 그러나 나는 당신에게 동의하고 else 문을 제거합니다. 버전 관리를 사용한다고 가정하면 파일의 기록을 보면 이전 코드를 계속 볼 수 있습니다.

이것은 개인적인 견해 일 수도 있지만 코드를 유지할 때 데드 코드가 산만 해집니다. 주어진 작업에 대해 항상 여러 가지 방법으로 수행 할 수 있으므로 하나를 선택해야합니다. 연구를 수행하고 알고리즘을 평가 한 후 하나를 선택하십시오. 그 후에 코드에는 다른 대체 메소드가 포함될 필요가 없습니다.

매우 강력한 두 가지 경쟁자가있는 경우 대안에 대한 작은 메모를 작성하고 프로젝트 위키 또는 프로젝트 문서가 포함 된 다른 곳에 배치하십시오. 원하는 경우이 문서를 참조하는 한 줄짜리 주석을 달고 왜 읽고 싶은지 간략하게 설명 할 수 있습니다.

데드 코드 작성이 유용한 상황을 즉시 생각할 수는 없습니다. 대체 알고리즘이 있으면 다음을 수행하십시오.

• 가장 유용한 것을 유지하고 다른 것을 제거하거나
• 또는 알고리즘이 다른 환경에 적용 가능한 경우 두 알고리즘을 모두 유지하고 조건부에서 첫 번째 알고리즘을 사용할 때 상황을 식별합니다.

어느 쪽이든, 죽은 코드가 없습니다.

죽은 코드를 삭제하거나 주석을 달지 않으면 컴파일러 오류를 피하기 위해 코드를 유지해야합니다. 시간 낭비입니다. SCM이 있으면 삭제하십시오.

아니

일부 프로그래머는이 스타일을 주석의 대안으로 사용하고 우아하게 생각합니다.

if (1 == 0) 
{
    std::cout <<"I am a dead code capable of resurrection, once a programmer changes the condition!";
}

간단한 대답은 간단합니다. 데드 코드는 혼란과 버그 발생 기회를 끌어냅니다. 코드에 문자를 입력하자마자 위험이 있습니다. 따라서 더 이상 추가하지 마십시오.

비슷한 것을 작성해야 할 때 컴파일러 버그에 대한 해결 방법으로 컴파일러 공급 업체 가이 해결 방법을 사용하도록 권장했습니다.

작성한 죽은 코드를 테스트합니까? 그것이 좋은지 확인하기 위해 무엇을해야합니까? 그렇지 않은 경우 제거하십시오.

향후 코드 변경을 위해 데드 코드가 여전히 작동하는지 확인 하시겠습니까? 그렇지 않은 경우 제거하십시오.

사용하지 않더라도 프로그램에서 잘못된 코드를 원하지 않습니다. 거기에 있으면 사용할 수 있다고 제안됩니다. 두 가지를 모두 사용하지 않으면 두 가지 버전의 코드를 유지하고 싶지 않습니다. 왜냐하면 여분의 작업이므로 대부분의 사람들이 죽은 코드에서 잘 작동하지 않을 것입니다.

주석 처리 된 코드 (또는 C 또는 C ++에서는 #ifdef코드가 제거 된 코드) 를 유지해야하는 이유가있을 수 있지만, 이것이 여전히 존재하는 이유와 코드의 목적에 대한 주석과 함께 제공되어야합니다.

Java에서는 도달 할 수없는 코드로 인해 다음도 컴파일되지 않습니다.

int someFunc() {
    return 10;
    int x = 12;
    return x;
}

이상적으로, 코드에 문제가있는 경우 코드를 프로덕션으로 이동하여 사용자가 찾을 수 있도록하는 것이 아니라 가능한 빨리 찾기를 원합니다.

컴파일러에서 오류 클래스를 찾을 수 있으면 컴파일러가이를 찾아 보도록하십시오. 사용자가 설명하는 방식으로 죽은 코드를 작성하여 누군가가하고있는 IMHO는 컴파일러 오류를 피하려고 시도하여 런타임에 발생할 수있는 문제를 허용합니다.

데드 코드에 도달 할 수 없으므로 문제를 일으킬 수는 없지만 설명, 브레이스 및 들여 쓰기에 문제가 생길 수 있습니다.

사람들이 오래된 논리를 언급하는 이유는 코드를 크게 변경하기를 두려워하기 때문입니다. 사실, 일주일 후 이전 코드가 실제로 정확하다는 것을 깨달았으므로 이제 처음부터 작성해야합니다. 그러나 이것이 소스 제어의 목적입니다. 일부 논리를 변경하기로 결정한 경우 다소 작동하는 현재 코드가 손실되는 것을 두려워하지 마십시오. 이를 제거하고 SVN / Git / TFS가 버전 관리를 담당하게하십시오.

그렇지 않은 경우 YAGNI 또는 DRY에 신경 쓰지 않기 때문에 두 가지 논리를 만들어 무언가를 수행하는 경우 사람들이 사용할 수있는 곳에 두십시오. 기분이 좋으면 전략 패턴을 던져보세요. 이 "만약 .."일을하지 않으면 디자인이 나쁘고 유지하기가 어렵습니다. 일부 코드가 존재할 권리가 있다고 생각되면 사용할 수 있도록하십시오.

기본적으로 대부분의 전문 프로그래머는 코드의 크기가 적이라는 데 동의합니다. 이 블로그 게시물을 살펴보십시오 . 최고의 코드는 코드가 전혀 없습니다. Steve Yegge 의 코드의 가장 큰적인 Jeff Atwood의 코드는 더 많습니다.

사람들은 코드 간결성을 유지하기 위해 많은 일을하고 있으며, 종종 성능을 떨어 뜨려도 코드베이스가 너무 커지는 것을 방지합니다. 100 줄의 데드 코드가 좋은 것이라고 생각하십니까?

내가 유용하다고 본 곳은 무언가를 신속하게 비활성화하고 테스트 / 백필을 수행하려는 경우에만 해당됩니다 (프로그램은 A, B, C 단계를 수행합니다-모두 오랜 시간이 걸립니다. 백필 중에 B 및 C를 비활성화하도록 선택할 수 있습니다 그들이 필요하지 않다는 것을 알면 시간을 내야합니다.
그러나 진실은 모든 경우에 이것이 매우 해킹 적이라는 것입니다. 백필 코드에 장기간 사용되는 경우 hack을 사용하는 대신 config를 사용하여 선택 항목을 선택하는 방식으로 코드를 작성해야합니다.
내 빠른 규칙은 이런 종류의 코드를 체크인하지 않는 것입니다. 체크인 / 버전 제어가 필요한 경우 곧 다시이 기능을 사용할 수 있으며 요구 사항이 변경 될 때 항상 나쁜 점입니다.

실제로, "죽은 (dead)"코드를 갖는 유용한 방법이 있습니다. 이것은 컴파일러 오류이거나 라인 위의 누군가가 사용중인 테스트의 논리를 변경하고 망친 경우입니다. 어느 쪽이든, 당신의 "다른 사람"은 불꽃 놀이를 보냅니다. 이 경우 릴리스하기 위해 ifdef를 만들고 싶습니다.

오류 메시지에 "Panic : % s 파일의 % d 줄에 있지 않아야합니다"와 같은 오류 메시지가 표시되어야합니다.