제거된 주석 달기 코드 [닫기]

Question

제거된 코드를 주석 처리하는 것이 좋은 습관입니까?예를 들어:

// Code to do {task} was removed by Ajahn on 10/10/08 because {reason}.

동료 검토 중에 내 개발자 그룹의 누군가가 제거할 코드 줄에 주석을 달아야 한다고 메모했습니다.나는 이것이 쓸모없는 주석으로 코드를 복잡하게 만들기 때문에 끔찍한 제안이라고 생각했습니다.우리 중 누가 옳은가?

Answer 1

일반적으로 제거 된 코드는 코드베이스를 막기 때문에 정확하게 주석을 주어서는 안됩니다 (그리고 존재하지 않는 것에 대해 왜 의견이 있습니까?).

결함 추적 시스템 또는 소스 제어 관리 도구는 그러한 주석에 속하는 곳입니다.

Answer 2

(삭제하는 대신) 코드를 댓글을 달 때 몇 가지 (드문) 상황이 있습니다. 여기 하나가 있습니다.

나는 좋고 필요한 것처럼 보이는 코드 라인이있었습니다. 나중에 나는 그것이 불필요하고 유해하다는 것을 깨달았습니다. 라인을 삭제하는 대신, 나는 그것을 언급하면서 다른 의견을 추가했다. 왜요?

코드의 다음 독자가 먼저 생각할 것이라고 확신하기 때문에 ~ 아니다 이 줄을 갖는 것은 오류이며 다시 추가하려고합니다. (독자가 지금부터 2 년 후에도) 더하더라도 소스 컨트롤을 먼저 상담 할 것으로 기대하지 않습니다. 이 까다로운 상황에 대해 경고하기 위해 의견을 추가해야합니다. 그리고 잘못된 선과 그것이 잘못된 이유를 갖는 것이 가장 좋은 방법이되었습니다.

Answer 3

코드를 댓글로 제거하는 것이 좋은 생각이 아니라는 데 동의합니다.

코드 기록은 이전 코드를 찾을 수있는 버전 제어 시스템과 제거 된 이유를 통해 조회해야합니다.

Answer 4

항상 코드를 삭제해야합니다.

오래된/제거 된 코드를 볼 수있는 것은 개정 제어가 무엇인지입니다.

Answer 5

제거 이유에 따라 다릅니다.

나는 코드가 있었지만 제거 된 정보가 코드를 유지하는 사람에게 도움이 될 수 있다면 (아마도 "하지 말아야한다"라는 서명으로) 앞으로 코드를 유지하는 사람들을위한 힌트로 생각을 생각합니다. 거기있어.

그렇지 않으면 모든 코드 변경에 이름과 날짜가있는 자세한 주석을 추가하면 모든 것을 읽을 수 없습니다.

Answer 6

나는 그것이 쓸모없고 코드를 덜 읽기 쉽게 만듭니다. 한 달이 지난 후에는 어떻게 될지 생각해보십시오 ....

// removed because of this and that
/* 
      removed this stuff because my left leg...
*/
 doSomething();
// this piece of has been removed, we don't need it...

무슨 일이 일어나고 있는지 알아 내기 위해 30 분을 보낼 것입니다.

Answer 7

문제는 왜 코드를 제거합니까?

쓸모가 없습니까? 처음에 거기에 두는 것이 실수였습니까?

내 관점에서 댓글이 필요하지 않습니다.

Answer 8

디버깅 할 때 유용하지만 이유가 없습니다. 체크인 그런 식으로 코딩합니다. 소스 컨트롤의 요점은 주석이있는 코드로 코드를 혼란스럽게하지 않고 이전 버전을 복구 할 수 있습니다.

Answer 9

예, 제거 된 코드에 대해 의견을 제시하는 것이 좋습니다. 코드 자체가 아닙니다.

이 위치를 더 명확히하려면 SCC (Source Coder Control System)를 사용하여 어떤 형태의 체크인 주석을 허용해야합니다. 그곳에서 코드가 제거 된 이유에 대한 의견을 배치해야합니다. SCCS는 제거 된 내용을 포함하여 코드에 일어난 일에 대한 전체 맥락 기록을 제공 할 것입니다. 체크인 댓글을 추가하면 해당 역사를 더 명확히합니다.

코드에 댓글을 추가하면 직접적으로 혼란이 발생합니다.

Answer 10

최근의 합의 (여기에 대한 다른 토론에서)는 코드를 제거해야한다는 것입니다.

나는 개인적으로 코드를 댓글을 달고 날짜 나 이유와 태그를 지정할 것입니다. 그것이 오래/오래되고 파일을 통과한다면, 나는 그것을 벗겨냅니다. 버전 제어는 쉽게 되돌아 갈 수 있지만 타협하지 않는 것만 큼 쉽지는 않습니다 ...

Answer 11

코드를 버전으로 가져 가려고하는 것처럼 들립니다. 이론적으로는 좋은 생각처럼 들리지만 실제로는 매우 빠르게 혼란스러워 질 수 있습니다.

다른 테스트를 디버깅하거나 실행하기 위해 코드를 댓글을 달리는 것이 좋습니다. 그러나 최종 결정이 이루어진 후 파일에서 완전히 제거하십시오!

좋은 버전 관리 시스템을 확보하면 변경 사항을 언급하는 관행이 지저분하다는 것을 알게 될 것입니다.

Answer 12

여기에 아무도 많이 썼습니다 왜 지저분 해 보이는 것 외에는 주석을 남겨 두지 말아야합니다. 가장 큰 이유는 코드가 작동을 멈출 가능성이 높기 때문입니다. 아무도 그것을 컴파일하지 않습니다. 아무도 단위 테스트를 통해 그것을 실행하지 않습니다. 사람들이 코드의 나머지 부분을 리팩토링하면 리팩토링되지 않습니다. 너무 빨리, 그것은 쓸모 없게 될 것입니다. 또는 쓸모없는 것보다 더 나쁘다 - 누군가가 그것을 맹목적으로 믿을 수있다.

거기 ~이다 우리가 여전히 프로젝트에서 무거운 설계/개발을하고 있다면 코드를 주석 할 때. 이 단계에서 저는 보통 여러 가지 다른 디자인을 시도하여 올바른 접근 방식을 찾고 있습니다. 그리고 때로는 올바른 접근법이 이미 이전에 시도한 접근법입니다. 따라서 소스 제어의 깊이에서 해당 코드가 손실되지 않으면 좋습니다. 그러나 일단 디자인이 해결되면 이전 코드를 제거하겠습니다.

Answer 13

일반적으로 나는 코멘트를 매우 드물게 하는 경향이 있습니다.나는 좋은 코드는 많은 주석을 달지 않고도 읽기 쉬워야 한다고 믿습니다.

또한 내 코드를 버전화합니다.특정 라인이 특정 이유로 변경되었는지 확인하기 위해 지난 20번의 체크인에 대해 diff를 수행할 수 있을 것 같습니다.그러나 그것은 대부분의 변경에 있어서 시간 낭비가 될 것입니다.

그래서 나는 내 코드에 현명하게 주석을 달려고 노력한다.매우 명백한 이유로 일부 코드가 삭제되는 경우 삭제에 대해 언급하지 않겠습니다.그러나 미묘한 이유로 코드 조각이 삭제되는 경우(예: 현재 다른 스레드에서 처리 중인 기능을 수행한 경우) 코드를 주석 처리하거나 삭제하고 그 이유에 대한 배너 설명을 추가합니다.

   // this is now handled by the heartbeat thread
   // m_data.resort(m_ascending);

또는:

   // don't re-sort here, as it is now handled by the heartbeat thread

바로 지난달에 특정 문제를 해결하기 위해 1년 전에 변경한 코드 조각을 발견했지만 그 이유를 설명하는 설명은 추가하지 않았습니다.원본 코드는 다음과 같습니다.

   cutoff = m_previous_cutofftime;

다음은 중단된 상태를 재개할 때 올바른 차단 시간을 사용하도록 처음에 수정된 코드입니다.

   cutoff = (!ok_during) ? m_previous_cutofftime : 0;

물론 또 다른 관련 없는 문제가 발생하여 동일한 코드 줄을 건드리게 되어 이 경우 원래 상태로 되돌렸습니다.이제 새로운 문제는 해결되었지만 이전 문제는 갑자기 다시 깨졌습니다.맙소사!

이제 체크인 코드는 다음과 같습니다.

   // this works for overlong events but not resuming
// cutoff = m_previous_cutofftime;
   // this works for resuming but not overlong events
// cutoff = (!ok_during) ? m_previous_cutofftime : 0;
   // this works for both
   cutoff = (!resuming || !ok_during) ? m_previous_cutofftime : 0;

물론, YMMV.

Answer 14

고독한 반대 의견을 말하면서, 나는 특별한 상황에서 코드를 언급 할 곳이 있다고 말할 것입니다. 때로는 이전 코드를 통해 실행되는 데이터가 계속 존재하는 데이터가 있으며 가장 분명한 일은 이전 코드를 소스와 함께 남겨 두는 것입니다. 그러한 경우에 나는 아마도 이전 코드가 단순히 댓글을 달았는지를 나타내는 작은 메모를 남기지 않을 것입니다. 이후에 오는 모든 프로그래머는 오래된 버전을 확인할 필요성을 정신적으로 감지하지 않고도 여전히 현존하는 데이터를 이해할 수 있습니다.

그러나 일반적으로 코드가 완전히 불쾌한 코드를 발견하고 가로 질 때 종종 삭제합니다.

Answer 15

코드를 제거하는 경우. 당신은 그것을 제거했다고 언급해서는 안됩니다. 이것은 소스 컨트롤의 전체 목적이며 (소스 컨트롤을 사용하고 있습니까? 맞습니까?), 의견을 말하면 코드를 막습니다.

Answer 16

나는 그것이 끔찍한 제안이라는 데 동의합니다. 그렇기 때문에 개정판이있는 소스 제어가 있습니다. 돌아가서 두 개정판 사이에 변경된 내용을 확인 해야하는 경우 두 개정판이 차정됩니다.

Answer 17

나는 주석 아웃 코드로 어수선한 코드를 보는 것이 싫다. 코드를 삭제하고 제거 된 이유를 나타내는 커밋 메시지를 작성하십시오. 당신은 소스 제어를 사용하지 않습니까?

데드 코드로 활성 코드를 쓰지 마십시오.

Answer 18

합의에 내 목소리를 추가하겠습니다. 코드가 아닌 소스 제어 저장소에서 코드가 삭제 된 이유에 대한 의견을 넣습니다.

Answer 19

이것은 컴파일러 힌트/경고와 같은 "깨진"Windows Thinkgs 중 하나입니다. 그것은 언젠가 당신을 아프게하고 팀의 경사를 촉진합니다.

버전 제어의 체크인 댓글은이 코드가 제거 된 이유를 추적 할 수 있습니다. 개발자가 메모를 남기지 않으면 추적하고 스로틀을 스로틀합니다.

Answer 20

약간의 일화, 재미를 위해 : 나는 몇 년 전에 회사에 있었고 소스 코드 버전 제어에 대해 아무것도 알지 못했습니다 (나중에 도구를 얻었습니다 ...).
그래서 그들은 우리의 C 출처에서 규칙을 가졌습니다.

#ifdef OLD /* PL - 11/10/1989 */
void Buggy()
{
// ...
}
#else
void Good()
{
// ...
}
#end

말할 필요가 없습니다. 우리의 출처는 빨리 읽을 수 없었습니다! 유지하는 것은 악몽이었습니다 ...
그렇기 때문에 중첩 된 #ifdef / #else / #end 사이를 점프 할 수있는 용량을 스카이트하기 위해 추가 한 이유는 ... 더 일반적인 경우에도 여전히 유용 할 수 있습니다.
나중에, 나는 우리가 VC를 얻었을 때, 기존 코드를 행복하게 제거하기 위해 Visual Studio 매크로를 썼습니다!

이제 Buti-Oxa와 마찬가지로 언젠가는 코드를 제거한 이유를 나타낼 필요성을 느꼈습니다. 같은 이유로, 또는 더 이상 필요하지 않다고 생각하는 오래된 코드를 제거하기 때문에 너무 확실하지 않습니다 (유산, 유산 ...). 분명히 모든 경우에!
나는 실제로 그런 의견을 남기지 않지만 필요를 이해할 수 있습니다.
더 나쁜 것은 한 버전으로 댓글을 달고 다음 버전의 모든 것을 제거 할 것입니다 ...
현재의 작업에서 중요한 로컬 변경을 위해 기존 코드를 떠나지 만 응급 상황의 경우 속성으로 재 활성화 할 수 있습니다. 생산 시간을 테스트 한 후 결국 구 코드를 제거합니다.

물론 VCS 댓글은 최선의 선택이지만, 변경이 다른 변경 사항이있는 큰 파일의 몇 줄이면 작은 제거를 참조하는 것은 어려울 수 있습니다 ...

Answer 21

당신이 주요 변화의 중간에 있고 기존 기능을 해결 해야하는 경우, 미래의 코드를 언급하는 것은 적어도 미래의 기능이라고 말하면, 최소한 우리가 선물 친화적 인 소스 제어를 할 때까지 미래의 기능이라고 언급하는 것이 합리적인 일입니다. 시스템.

Answer 22

나는 당신이 고대 코드에서 언제 떨어질 것인지 알지 못하기 때문에 사용되지 않은 코드에 대해 의견을 말하며, 오래된 코드는 다른 사람들이 그 당시 더 간단하다면 다른 사람들이 그것을 이해하는 데 도움이 될 것입니다.

Answer 23

나는 당신에게 앤드류와 동의합니다. IMO 이것이 버전 제어를 사용하는 이유입니다. 체크인/커밋 주석과 DIFF 도구를 사용하면 라인이 제거 된 이유를 항상 알 수 있습니다.

Answer 24

어떤 형태의 소스 제어를 사용하는 경우이 접근 방식은 다소 중복됩니다 (설명 로그 메시지가 사용되는 한)

Answer 25

나는 또한 그것이 끔찍한 제안이라고 생각합니다 :)

소스 컨트롤을 사용해야하며 코드를 제거하면 커밋시 주석을 추가 할 수 있습니다. 그래서 당신은 원한다면 여전히 코드 기록이 있습니다 ...

Answer 26

일반적인 "클린 코드"관행이 있습니다.이 관행은 댓글을 달고 CVS/SVN이 어쨌든 보관하기 때문에 댓글을 달린대로 제거하지 않아야한다는 말이 있습니다.

나는 원칙에 동의하지만 모든 개발 상황에서 그것이 수용 가능한 접근법이라고 생각하지 않습니다. 내 경험상 코드의 모든 변경 사항과 모든 체크인을 추적하는 사람은 거의 없습니다. 결과적으로, 댓글을 달린 코드가 없으면 코드가 존재하지 않았다는 것을 결코 알지 못할 수 있습니다.

코드를 언급하는 것은 그것이 제거 될 것이라는 일반적인 경고를 제공하는 방법 일 수 있지만 물론 이해 당사자가 그 경고를 볼 수 있다는 보장은 없습니다 (그 파일로 자주 일한다면, 그들은 그 경고를 자주 할 것입니다. 참조).

개인적으로 올바른 접근 방식은 해당 코드를 다른 개인 방법으로 고려한 다음 관련 이해 관계자에게 연락하여 실제로 기능을 제거하기 전에 보류중인 제거를 알리는 것이라고 생각합니다.

Answer 27

내가있는 곳에 우리는 하나의 릴리스주기에 대한 오래된 코드를 언급 한 다음 그 후 주석을 제거합니다. (새 코드 중 일부가 문제가 있고 이전 코드로 대체 해야하는 경우 빠른 수정 능력을 제공합니다.)

Answer 28

거의 모든 경우에 구식 코드는 물론 RC에서 제거 및 추적해야합니다.

그러나 모든 것들과 마찬가지로, 나는 '모든 삭제 된 코드가 항상 제거 될 것입니다'라는 진술을 만드는 것은 잘못된 접근법이라고 생각합니다.

이전 코드는 이유가 많은 이유 때문에 남겨두고 싶을 수도 있습니다. 코드를 남겨 두어야 할 주요 이유는 앞으로 해당 코드 섹션에서 일하는 개발자가 이전 코드를보기를 원하기 때문입니다.

소스 추적에 의존한다고해서 분명히 이것을 제공하지는 않습니다.

따라서 정답은 다음과 같습니다.

-Delete Old Code를 남기지 않는 한 코드의 다음 개발자가 요구하는 중요한 정보를 제공합니다. 즉, 시간의 99%를 제거하지만 상황이 보증 할 때 다음 개발자에게 필요한 문서를 제공 할 수있는 능력을 제거 할 수있는 드라코 니아 규칙을 만들지 마십시오.