호기심으로, 주석을 허용하지 않는 언어가 자체 주석 코드를 작성해야 할 때보 다 읽기 쉬운 코드를 생성하는지 궁금해하기 시작했습니다.

그런 다음 다시 신경 쓰지 않기 때문에 이전과 마찬가지로 나쁜 코드를 작성할 수 있습니다. 그러나 당신의 의견은 무엇입니까?

프로그래머가 의견을 추가하는 또 다른 방법을 알아낼 것이라고 생각합니다 ...

string aComment = "This is a kludge.";

나는 그것이 그렇게 간단하다고 생각하지 않습니다.

잘 작성된 자체 문서화 코드에서도 주석을 작성해야하는 합법적 인 상황이 있습니다.

당신이 완벽한 프로그래머라고 가정하십시오 (그렇지 않지만, 그냥 가정합시다) ...

작성하지 않은 것들과 인터페이스 할 때 코드에서 발생할 수있는 많은 명백한 효과가 있습니다. 예를 들어, 다른 사람의 라이브러리 또는 다른 사람의 하드웨어에 (커널 개발자 인 경우) 디자인 결함이있을 수 있습니다. 특정 장소에서 특정 kludge를 사용한 이유를 설명하는 의견을 갖는 것이 코드를 이해하고 kludge가 제거되지 않도록하는 데 필수적 일 수 있습니다.

언어에서 옵션을 제거하면 어떻게하면 해당 언어로 작성된 프로그램이 더 나아질 수 있다는 생각을 내 마음 속에 감추기가 어렵습니다. 주석은 필수 사항이 아니며 자체 문서화 코드 작성은 그다지 중요하지 않습니다.

좋은 개발 관행을 대신 할 수있는 것은 없습니다.

이론적으로 COBOL 은 원래 비 개발자 (예 : 감독자)조차 작성된 코드를 검토하고 진행중인 작업을 결정할 수있을 정도로 자체 문서화 할 수 있도록 설계되었습니다. 그러나 실제로 프로그램이 더욱 복잡 해짐에 따라 코드를 통해서만 진행되는 모든 것을 이해하기는 어렵습니다.

주석을 제거하면 자기의 문서에서 더 나은 코드를 작성하는 일부 개발자를 강제 수도 있지만, 거기 개발자가 쓰기 제대로 문서화 된 코드를 여전히있다 (의 예 변수 이름은 a, b, c, 등) 그것은 사람들이 밖으로 훈련을 필요로하는 습관이다 중 이러한 경우 주석을 제거해도 해당 개발자에게 영향을 미치지 않으며 복잡한 코드 조각을 설명하려는 다른 개발자의 노력을 방해 할 수 있습니다.

모든 프로그램은 서면 또는 다른 사람의 머리에 상관없이 프로그램 외부의 기능 요구 사항을 구현하도록 작성됩니다.

의견의 가장 중요한 기능은 요구 사항과 코드 사이의 매핑을 설정하는 것입니다. 매핑이 필요한 이유는 증분 변경을 허용하기위한 것입니다. 요구 사항이 변경 될 때 코드가 요구 사항에 대한 솔루션을 유지하려면 해당 코드를 변경해야합니다. 의견은 변경 사항의 로드맵 역할을합니다.

언어가 해결중인 문제에 완벽하게 적합한 이상적인 DSL (Domain-Specific-language) 인 경우 매핑은 단순한 동형이어야하며 주석은 필요하지 않습니다. 소스 코드는 단순히 문제를 나타내며 다른 말을 할 필요가 없습니다. 문제의 해결책은 언어의 구현에 묻힐 것입니다.

우리가 일하는 언어는 그러한 DSL이 아니며, 앞으로도 계속 유지 될 것이기 때문에 여전히 의견이 필요합니다 . 정도의 문제입니다. 때때로 문제는 해당 언어와 잘 맞지만 대개는 그렇지 않습니다.

또한보십시오...

인라인 주석을 허용하지 않는 곳에서 일합니다 (즉, 함수 상단에 주석 만 가질 수 있음). 아니요, 코드를 쉽게 읽을 수 없습니다. 그것은 수십 배의 질서를 떨어 뜨린다.

코드 주석 처리를 피하고 작동합니다.

docblock + 의미있는 변수 + 스파르타 프로그래밍 을 선호하는 모든 인 코드 (인라인 또는 스트림) 주석을 피 하십시오.

그리고 그렇습니다. docblocks는 기술적으로 주석이지만, 실제로는 코드를 보완하는 것이지, 방해가되지 않고 "표준화 된"것이 아니라 ... 일반적인 주석이 아닌 모든 것입니다.

내가 생각하는 것은 주석 대신에 표준화 된 docblock 언어 / 구문 / 관용구, 자바의 주석과 같이 작동 할 수 있다고 생각합니다.

다른 사람들이 관찰 한 것처럼 품질에 영향을 미치지 않을뿐만 아니라 실제로는 성가시다.

나는 우리 대부분이 때때로 이와 같은 일을했다고 확신한다.

foreach ( myObject obj in SomeList )
 {
    Debug.Writeline( obj.Name );
//  for some reason this isn't working
//  obj.SetArielPotency( setting );
//  obj.DoSomeProcess();       
 }

버그의 출처를 알아 내기 위해 몇 줄의 코드를 주석으로 처리 할 수 ​​없다면 얼마나 짜증이 나겠습니까?

코드 작동 방식에 대한 의견에 관계없이 이와 같은 간단한 실제 사항이나 편리한 TODO참고 사항은 사소한 문제를 쉽게 해결하고 코드 작성을 시작할 때 수행했던 작업을 기억하는 것입니다.

의견은 책 요약과 같습니다. 물론, 당신은 코드를 읽음으로써 모든 것을 이해할 수 있지만, 왜 지구상에서 한 줄로 요약 될 수있을 때 전체 페이지를 읽고 싶습니까?

자체 문서화 코드조차도 주석이 필요하다는 다른 답변에 동의하지만, 현재 언어 에만 해당 됩니다.

실제 질문은 " 주석이 필요 없는 새로운 프로그래밍 언어를 디자인 할 수 있습니까?"라고 생각합니다. 많은 추상화로 꽤 높은 수준이어야합니다. 모든 구문과 함수는 언어의 구문을 통해 읽을 수 있어야합니다.

훈련받지 않은 프로그래머는 언어에 상관없이 잘못된 코드를 작성합니다.

컨벤션 (_- 접두사)에 의해서만 개인을 가진 파이썬은 이것을 막기 위해 노력 하지 않으며 , 여전히 훌륭한 코드가 작성되고 있습니다.

Rant : 때로는 좀 더 관용적 인 언어가 더 많은 사람들이 반대로하는 대신 코드를 제대로 배우도록 강요 한다고 생각합니다.

나는 추측 할 것이다 : 아마 아닐 것이다. 왜? "왜"를 언어의 형식주의로 인코딩해야하고 "왜"가 언어 또는 언어로 인코딩되었는지에 상관없이 프로그래머가 사용하지 않기 때문입니다.

코드는 자신 이하는 일 을 설명 하는 데 있어 스스로 의견을 제시 할 수 있지만, 코드가 왜 그 일을 하는지 설명하는 것이 항상 가능한 것은 아닙니다 . 그것이 주석이 가장 필요한 곳입니다.

예를 들어 특정 규정을 준수하기 위해 코드 섹션이 필요한 경우 어떻게 주석없이 설명 할 수 있습니까? M. Matsumoto와 T. Nishimura가 1998 년에 작성한 논문에 특정 코드에서 사용 된 알고리즘이 설명되어 있다면 어떻게 설명하지 않습니까? 알고리즘이 최적의 기능을 정확하게 제공하지는 않지만 다른 코드가 변경 될 경우 향후 문제를 일으킬 수있는 매우 구체적으로 정당화 된 타협을하는 경우 주석없이이를 설명하는 방법은 무엇입니까?

독립적 인 감사인이 코드의 한 섹션을 감사하여 해당 감사를 무효화하지 않고 수정할 수없고 고객이 해당 감사를 준수해야하는 제품을 빌드하는 데 코드가 사용되는 경우 어떻게해야합니까? 코멘트없이 어떻게 표시합니까?

나는 항상 한 단어 주석을 갖는 것이 좋을 것이라고 생각했습니다. 따라서 단어 앞에 기호가 붙으면 (콜론이라고 말하면), 그 단어는 무시됩니다. 그렇게하면 s- 표현식 내에서 한 단어로만 주석을 허용했다는 lisp를 말할 수 있습니다. 예를 들어 다음과 같이 설정할 수 있습니다.

(if (= x y)
    x
    y)

... 이것으로 :

(if (= x y)
    :then x
    :else y)

꼭 필요한 경우 여러 단어로 된 주석을 연결하여 인라인 주석을 만들 수 있습니다.

(if x :Remember, :x :could :be :nil!
    ...)

물론 이것은 타이핑하기 힘든 고통입니다. 사실, 그게 요점입니다. 인라인 주석을 자주 사용하지 말고 짧고 요점을 지키도록 권장합니다. 그러나 나는 누군가가 그 언어를 사용하도록 설득하기가 힘들다는 느낌이 들었습니다.

이건 아무것도 아니야 일부 프로그래머는 코드를 읽을 수 있도록하기 위해 아무것도하지 않습니다. 주석을 허용하지 않으면이를 강화할 수 있습니다. 일부 프로그래머는 주석이 아닌 코드 리팩토링을 사용하는 것이 더 좋더라도 좋은 주석을 작성합니다. 주석을 제거하면 더 나은 리팩토링을 수행 할 수 있습니다.

이것이 좋은 아이디어 인 이유 :-없음

이 나쁜 생각입니다 이유 : - 더 많은 형편 프로그래머가 좋은하지만 - - 위대한하지 프로그래머보다가 있습니다 - 거의 항상이 있어야합니다 몇 가지 이상한 개는, 요약 등을위한 의견 - 당신이 의견을 피하다 경우에도 사용 아마 것 길에 무대로 의견 : 무언가를 쓸 때 의견을 던지고 돌아와서 리팩토링합니다. 그러나 여전히 배우기 때문에 항상 바로 할 수는 없습니다. -사람들이 일을하도록 장려 할 것입니다-누가 그것을 사용할 것입니까? 읽을 수없는 코드를 작성하고 변명 (나쁜)을 원하는 사람들과 이미 아이디어에 열중하고있는 사람들 (처음으로 "주석을 쓸 수 없음") 이것이 원하는 것이라면 사람들이 원하는 방식을 보여주는 코딩 표준을 작성하십시오.

이것이 관련이있는 이유-유용 할 수있는 곳은 "주석을 달지 않는"시스템을 개선하는 것입니다. 주석보다 더 나은 것을 지원하고 그 피치의 일부로 언어 또는 IDE는 주석을 피합니다. 어떻게 작동하는지 모르겠지만 적어도 생각해 볼만한 가치가 있습니다.