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


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.