유익한 주석을 주석 처리 된 코드와 구별하는 방법이 있습니까?


36

프로그래밍 과정 동안 코드를 설명하는 주석과 코드를 제거하는 주석이 생깁니다.

// A concise description 
const a = Boolean(obj);
//b = false;

어느 것을 빨리 파싱하는 좋은 방법이 있습니까?

나는 3을 사용 /하고 /** */설명적인 의견을 가지고 놀았습니다 .

또한 VSCode 플러그인을 사용하여 강조 표시 //TODO:하고//FIXME:


2
참고로, ///및 /** ... */의견은 또한 Doxygen을 또는 JSDoc 같은 일부 문서 발전기에 의해 사용된다. 도구 나 이와 유사한 도구를 사용하는 경우 설명서에 포함되지 않은 설명 주석에는 해당 종류의 주석을 사용하지 못할 수 있습니다.
— 저스틴 타임 2 복원 모니카

1
자바 스크립트에서 대부분의 코드 줄은 아마도 세미콜론으로 끝날 것입니다. 당신의 의견이 아니라면, 그것은 매우 간단 해 보입니다. 그리고 당신은 그것을 쉽게 확인할 수있는 스크립트를 작성할 수 있습니다;
— Artemis Fowl

답변:


187

이에 대한 매우 간단한 해결책이 있습니다. 주석 처리 된 코드를 제거하십시오.

실제로 코드를 주석 처리해야하는 이유는 두 가지가 있습니다. 무언가를 테스트하거나 수정하거나 나중에 사용할 수있는 코드를 저장하는 것입니다. 무언가를 테스트하거나 수정하는 경우 테스트 나 수정 작업을 마치면 주석 처리 된 코드를 제거하십시오. 나중에 사용할 수있는 코드를 저장하는 경우에는 일류 코드로 만들어서 잘 사용할 수있는 라이브러리와 같은 곳에 두십시오.


108
또한 코드가 체크인 된 경우 제거하십시오. 만약 당신이 그것을 다시 필요로한다면, 소스 제어는 당신을 다루게 할 것입니다
— marstato

38
코드가 제거되면 아무도 존재하지 않습니다. 복구가 더 어려워집니다. 주석 처리 된 코드를 남겨두면 특히 미래에 사용될 가능성이 높은 경우에 가치가 있습니다.
— usr

76
@ usr : 코드가 제거되면 아무도 실제 코드의 존재를 알지 못합니다. 내 경험에 따르면 모든 실제 사례의 99 %가 옳습니다. 주석 처리 된 코드가 몇 주 또는 몇 개월 (또는 더 긴 시간) 동안 머무르면 활성 코드의 리팩토링으로 인해 더 이상 컴파일되지 않을 가능성이 높습니다. 코드 라인. "나중에 사용하기위한 잠재적 가치"논증은 종종 몇 시간의 두뇌 작업에 투자 한 코드베이스에서 사물을 제거하는 정서적 문제가있는 사람들의 잘못된 변명으로 사용됩니다.
— Doc Brown

21
추가 설명 없이는 주석 처리 된 코드를 커밋하지 않습니다. 단기간에 코드를 다시 원할 수있는 상황은 드물지만 그 중 하나는 예외적이며 미래 개발자 (또는 미래의 개발자)에게 설명이 필요합니다. 내 의견의 90 %가 "사용하지 않은 것으로 보이므로 제거되었습니다. 문제가없는 경우 2021 년 11 월 이후 삭제"
— James Beninger

30
우리 동료는 한동안 "X를 수행 한 코드가 있었지만 제거했습니다"라는 문구를 한 번 넣었습니다. 그것은 정말 잘 작동했습니다. 파일의 소스 히스토리에 있다는 것을 알고 있었지만 귀찮게하지 않았습니다.
— 에릭

45

에 추가 RobertHarvey의 훌륭한 대답 @ 의 경우 : 나는 내가 심지어 일시적으로, 소스 제어에 주석 코드를 저장하기 위해 만난 하나의 정당한 이유가 생각 하거나 어떤 이유로 지금은 사용할 수 없습니다 안 비 명백한 교체 코드 . 그럼에도 불구하고 대부분의 주석은 대체 코드가 아닌 설명 이어야합니다 . 이것은 아직 안정되지 않은 버그 또는 언어 기능 일 수 있습니다. 다음과 같이 보일 수 있습니다.

# TODO: Replace with `foo = frobnicate(bar)` once <link.to/bug> is fixed
foo = [some complex workaround]

이 경우 작업이 이미 완료되었지만 아직 활용할 수 없으므로 삭제하면 나중에 다시 검색해야합니다. 동일은 간다 그것의 얼굴에 우수한 것처럼 보일 수 있습니다 최적의 솔루션 또는 유사한 솔루션에 대한 의식이 절충 .

주의 : 대체 솔루션으로 코드를 버리지 마십시오. 모든 작업은 다양한 방법으로 무한대로 수행 될 수 있으며, 변경 될 때마다이 공간을 오랫동안 탐색하는 것은 비용 효율적이 아닙니다. 코드 검토는 동료가 이미 최적이 아닌 것으로 밝혀진 개선 사항을 제안 할 때 그러한 누락 된 주석을 발견하기에 좋은 장소가 될 수 있습니다.


2
이것의 반대 측면은 때때로 당신이 왜 사용하지 않는지 를 설명해야하기 frobnicate(bar)때문에 아무도 와서 "고급스러운"코드를 "고정"하려고하지 않을 것입니다. 그래서 당신은 완벽한 세상에서 frobnicate기능이 갈 길임을 알지만 고통스러운 경험으로는 제대로 작동하지 않는다는 것을 알 수 있습니다. 제 3자가 버그를 버그로 간주하여 수정해야 할 가치가 훨씬 적다는 기대는 없을 것입니다. 왜 분명한 접근 방식을 취하지 않은지에 대해서는 미래 프로그래머 (자신 포함)에게 의견을 남겨야합니다.
— Monty Harder

3
관련 상황은 두 가지 방법으로 무언가를 수행 할 수 있는데, 그 중 하나는 다른 방법보다 훨씬 더 유효한 데이터를 처리하고 다른 방법은 어떤 이유로 든 유효하지 않은 데이터를 수신하면 더 유용한 진단을 제공합니다. 프로그램이 유효하다고 "보증 된"데이터 만 제공해야하는 프로세스의 일부인 경우 프로세스의 무언가가 제대로 작동하지 않아서 더 느린 버전을 사용할 수 있지만 더 나은 진단을 제공 할 수있는 경우 무엇이 잘못되었는지 쉽게 판단 할 수 있습니다.
— supercat

20

흠, 코드를 주석 처리해야한다고 올바르게 주장하는 Robert 와이 질문을 약간 다르게 읽었습니다.

그러나 나중에 제거하기 위해 코드를 표시하는 규칙을 찾고 있다면 가장 좋아하는 것은 다음과 같습니다.

//b = false; //TODO: remove

일부 IDE의 깃발은 //TODO:논평하거나 가르 칠 수 있습니다. 그렇지 않은 경우 일반적으로 검색 가능한 문자열입니다. 여러 가지 방법으로 상점에서 설정 한 규칙을 따르는 것이 가장 좋습니다. 모든 코드베이스는이 방법을 사용해야합니다. 검색 가능하게 유지합니다.

어느 것을 빨리 파싱합니까?

그 마크가 없으면 자동으로 컴파일러를 사용하는 것입니다. 주석을 제거하면 컴파일되는 코드가 생성되고 주석이 달린 코드 여야합니다. 어렵지 않은지 확인하는 IDE 플러그인 작성. 그러나 버그가있는 주석 처리 된 코드는 남겨 둡니다.

그렇기 때문에 주석 처리 된 코드를 주석 처리하는 순간 코드로 표시하는 것이 좋습니다. 이를 통해 비파괴 적으로 작업 할 수 있으며 실제로 원하는 것을 결정할 수 있습니다. 우리 모두가 방해를 받고 다소 잊혀지기 때문에, 그 상태에있는 동안 일부 회선이 체크인 되어도 놀라지 마십시오. 그들이 그렇게하면 적어도 명확하게 표시되고 검색 가능한 것이 좋습니다. 키보드 매크로는 과거에 도움이되었습니다. 한 번의 키 입력으로 할 수 있다면 중간에 중단되기가 어렵습니다.

지속적인 통합 테스트에서 마크를 밝힐 때까지 이것을 취할 수 있습니다. 죄송합니다. 뛰어난 TODO를 다시 확인하려고합니다.


주석이 코드로 레이블링되도록 주석이 컴파일되는지 확인하는 대신 자연 언어 프로세서를 통해 주석을 실행하고 팀에서 사용하는 언어의 문장 또는 명사구로 구문 분석하는 주석을 레이블링 할 수 있습니다.
— The Hansinator

3
@TheHansinator는 잘 들리지만 휴대폰에 대한 나의 경험은 코더 전문 용어와 자동으로 올바른 관계를 맺게되므로주의가 필요합니다.
— candied_orange

코드 주석을 구문 분석하는 데 사용 된 NLP는 자동 수정 기능을 제공하는 NLP보다 훨씬 낫습니다. 단순히 컴퓨터에는 전체 문장이 작동하고 철자 오류를 수정하려고 시도하지 않기 때문입니다. 사람이 삭제하기 전에 주석을 검토 할 수있는 한, 허위 부정이 더 낫다는 것은 말할 것도없고, 쓸모없는 구글 곡에 대해 경고를받지 않는 대신 주석을 다시 작성할 수 있습니다.
— The Hansinator

3
wrt 파싱 : double buffer (flip on)-> C 프로토 타입 또는 초급 영어? 문맥없이 말할 수 없으며, 어느 언어로든 올바른 전체 구성이 아닙니다. 본질적으로 주석이 내용의 형식을 어느 방향 으로든 제한하지 않는 경우 일부 오탐과 부정은 불가피합니다.
— Leushenko

8

전 처리기 지시문을 사용하여 주석이 아닌 코드를 제거합니다.

//comment
active_code();
#if FALSE
inactive_code();
#endif

이것은 검색하기가 매우 쉬우 며 구문 강조 표시는 주석으로 처리합니다. 심지어 한 줄로 접을 수도 있습니다.#if FALSE(...)

이 아이디어를 확장하여 몇 가지 옵션을 가질 수 있습니다.

#if OPTION == 0
code_for_option_0();
#elif OPTION == 1
code_for_option_1();
#else
code_for_all_other_options();
#endif

그리고 컴파일 타임 오류 검사 :

#if FOO >= 5
#error FOO should be less than 5!
#endif

물론, 당신은 이것에 대해 넘어 가고 싶지 않거나 실제로 무엇이 컴파일되고 있고 무엇이 그렇지 않은지를 말하기가 어려워집니다. 그러나 아이디어를 얻으면 정적으로 만 사용하는 한 주석 처리 된 코드와 동일한 문제입니다. 당신의 조건이 역동적이라면 더 나쁘다.


기존 코드베이스 에서이 문제를 전혀 고려하지 않은 것을 결정하기 위해 보편적 인 솔루션이 있다고 생각하지 않습니다. 패턴을 직접 찾아서 정규식을 코딩하여 패턴을 찾아야 할 것입니다.


이것이 세상에 무엇이 좋을까요? 여러 버전을 컴파일해야합니까?
— Tvde1

@ Tvde1 그것은 하나의 가능성이며, 실제로 관리하지 않으면 악몽이 될 수 있습니다. 그러나 대안은 더 나쁠 수 있습니다. 공통 테마의 각 변형마다 하나씩 거의 동일한 코드의 사본이 여러 개있는 경우 별도로 유지 관리하고 동기화 상태를 유지해야합니다.
— AaronD

이를 수행하는 방법에는 여러 가지가 있지만 복잡한 구성 문제 나 독립 복사 문제의 변형이 있습니다. 버그 수정이 모든 독립 복사본에 적용 되었습니까? 그렇지 않은 경우 다른 기능이 추가되면 기능 이전에 알려졌지만 지금까지 포팅되지 않은 버그 수정에 의해 손상됩니까?
— AaronD

3
C와 같은 사전 처리 단계 가 있는 경우에만 작동합니다 javascript. 질문은에 관한 것 입니다. 일부 전처리를 수행 할 수 있지만 빌드 시스템의 기능을 확장 할뿐만 아니라 비표준이기도합니다. 빌드 시스템이 없거나 빌드 시스템이 코드 구문 분석 및 실행을 전혀 지원하지 않으면이 솔루션을 구현할 수 없습니다. 마지막으로, 그것은 질문조차도 다루지 않습니다. 주석 처리 된 코드는 조건부로 활성화 된 코드와 완전히 같지 않습니다. 활성화되어 있지 않은 남은 것일 수 있습니다.
— VLAZ

조건부 활성화는 답변 자체의 확장이 아니라 답변의 확장 일뿐입니다. 그렇지 않으면 나는 그것을 더 확장시키는 주석을 포함하도록 편집 할 것입니다.
— AaronD

4

가능한 경우 주석 처리되지 않고 오래된 코드를 제거해야한다는 답변에 동의하지만 주석 처리 된 코드가 필요한 경우에 대한 규칙을 준수했습니다.

(내 기초는 C #이지만 Java와 같은 모든 C 구문 언어에 적용될 수 있습니다)

// An explanatory comment has a space between the comment marker and the content.

// The following lines are commented out code so do not have the space (except where indented).
//var a = something();
//if(a==2) {
//   doSomethingElse();
//}

2
이것은 스타일에 전적으로 달려 있습니다. 코드를 주석 처리 할 때 일반적으로 //첫 번째 열에를 추가하고 사실상 모든 코드가 들여 쓰기되므로 주석이 일부 탭으로 시작하는 결과가 거의 항상 나타납니다. 주변에 선행 공백이있는 다른 주석이없는 한 일반 주석에는 선행 공백이 없습니다. 따라서 귀하의 방법은 내가 작성한 의견에 대해 심하게 실패 할 것이며, 내 의견 패턴을 인식하도록 설계된 모든 방법은 귀하의 방법에 의해 실패 할 것입니다.
— cmaster

@ cmaster 아, 나는 질문을 오해 한 것 같아요. 필자는 형식에 따라 쉽게 구문 분석 할 수있는 방식으로 주석의 형식을 지정하는 간단한 방법을 제공했지만 요청하지 않았습니다.
— IanF1

2

주석이 달린 코드를 찾으려고 생각하면서 여전히 다른 질문을 해석하고 있습니다.

C 스타일 코드에는 세미콜론이 포함되어 있지만 주석에는 세미콜론이 포함되어 있지 않습니다. 따라서 한 줄 주석 처리 된 코드의 경우이 정규 표현식을 사용할 수 있습니다.

\s*\/\/[\s\S]*;

여러 줄 주석 처리 된 코드의 경우

\/\*[^\;]*;[^\;]*\*\/

참고 Visual Studio는 정규 표현식의 줄 바꿈에 대해 약간 특이하며 공백으로 계산되지 않으므로 명시적인 \ n을 지정해야합니다.


2

Xcode 및 Clang과 같이 백그라운드에서 실행되는 컴파일러에서 편집기를 사용하는 경우 주석 텍스트를 컴파일하면됩니다. 예를 들어 "간결한 설명"은 "b = false;"오류를 제공합니다. 그런 다음 다른 구문 강조를 사용할 수 있습니다.

더 간단한 방법은 키워드 포인트 주석, 중괄호 포인트 코드 간 일치 등 여러 행의 여러 단어와 같은 휴리스틱을 사용하는 IDE 플러그인입니다.


1

다른 답변은 "코드 주석 처리 안 함"테마에 대한 변형을 다루었습니다. 그러나 때로는 참조를 위해 여전히 원합니다.

코드를 진정으로 유지해야하는 경우 더 나은 해결책은 코드를 "#if 0 ... #endif"로 묶는 것이 이상적입니다. MISRA를 포함한 다양한 코딩 표준에서 권장되는 전략입니다.


-3

최소한 나에게는 간단하고 C / C ++에서는 간단합니다. / * * /에 포함 된 주석은 유익합니다. 일시적으로 제거 된 테스트 코드는 //로 주석 처리됩니다.

그리고 테스트 코드를 파일에 남겨 두어야 할 이유가 있지만 적어도 내가하는 일에서 주석 처리했습니다. 조만간 누군가가 변경을 원할 것인데, 그 코드가 필요합니다. 블록의 주석 처리를 제거하면 완료된 위치에서 주석 처리를 해제하는 것처럼 하나의 편집기 명령이 필요합니다.


또한 #ifdef __DEBUG ... #endif사용하려는 맞춤 정의가 있습니다. __DEBUG그래도 프로젝트 구성을 변경하기 만하면되기 때문에 좋습니다. 그러나 대부분의 IDE를 사용하면 자체 구성을 정의 할 수 있으므로 그 자리에서 무엇이든 얻을 수 있습니다.
— AaronD

“테스트 코드”는 무엇을 의미합니까? 단위 테스트? 그것들은 전혀 주석 처리되어서는 안되며 누군가가 필요하다고 생각하는지 여부에 관계없이 테스트 스위트에 보관 하고 가능한 한 자주 실행해야합니다. 물론, 그것은 다시 취소 코멘트에 쉽게 코드의 조각이다, 그러나 ... 더 쉽게 그것을하고 자리에 이미 테스트 스위트를 전혀 아무것도하고 있지 않다
— leftaroundabout

1
아아, 하지 않는 그렇게. "무언가를 테스트하기 위해"코드를 주석 처리하면 100 회 중 99 회가 완벽하게 작동합니다. 단 하나의 경우 코드를 제거하거나 (더 이상 필요하지 않은 경우), 심지어는 주석 처리를 제거하는 것을 잊어 버리게됩니다 ( 필요한 경우) 상황이 나빠질 수 있습니다.
— CharonX

@ leftaroundabout : 아니요, printf 문과 같은 값을 확인하는 것을 의미합니다.
— jamesqf

@ jamesqf 그런 종류의 것들이 필요하지 않아야합니다. 디버거가 있습니다. 그러나 새로 작성된 코드를 올바르게 작성하기 위해 printf/ cout또는 이와 유사한 것을 사용하더라도 (이전에 내가 한 일을 인정할 것입니다), 실제로 두는 것이 효과적이지 않습니다. 누군가가 변화를 원하고 정보가 필요한 변수를 알고 printf있다면, 새로운 것을 빠르고 쉽게 작성할 수 있습니다. 반면에 개발자 가 필요한 것을 알지 못하고 모든 printf진술을 주석 처리 하지 않으면 거대한 텍스트가 있습니다. 터미널도 도움이되지 않을 것입니다.
— 왼쪽
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.