프로그래밍 언어에 주석이 필요합니까?

https://stackoverflow.com/questions/390797

23-08-2019
|

문제

Klingon Languages에 대한 어리석은 생각을 한 후에, 그것은 이것에서 왔습니다. 게시하다 나는 LUA 바이트 코드에 컴파일하는 Klingon 프로그래밍 언어를 만드는 바보 같은 취미 프로젝트를 시작했습니다. 초기 언어 설계 단계에서 나는 클링 온 프로그래머, 이 클링 온 프로그래밍 규칙에 대해 알게되었습니다.

진정한 Klingon Warrior는 그의 코드를 언급하지 않습니다!

그래서 나는 내 언어를 결정했습니다 의견을지지하지 않습니다, 좋은 클링 온은 절대 사용하지 않을 것입니다.

이제 많은 Klingon Ways는 인간 프로그래머에게 합리적으로 보이지는 않지만 취미 언어의 디자인과 구현에 대해 이야기하는 동안 나는 논평에 대한이 Klingon 규칙이 실제로는 매우 합리적이라는 것을 깨달았습니다.

프로그래밍 언어에서 댓글을 달리는 능력을 제거한다는 것은 가지다 쓰기 글린 코드, 예외 없음.

그렇다면 의견을지지하지 않는 언어가 있는지 궁금합니다.

언어에서 댓글을 제거하지 않는 것이 정말 좋은 주장이 있습니까?

편집 : 필요한 의견의 좋은 예가 있습니까?

PS> 위의 내 취미 언어는 어쨌든 부분적으로 바보이므로 일반적으로 필요한 의견의 개념만큼 내 구현에 너무 집중하지 마십시오.

해결책

프로그래밍 언어에서 댓글을 달 수있는 능력을 제거하는 진술의 "HAD"에 동의하면 모든 코드가 문서화되는 것처럼 보이지 않기 때문에 문맹 코드를 작성해야한다는 것을 의미합니다. 내 생각에 대부분의 사람들은 읽을 수없는 코드를 작성할 것입니다.

요컨대, 나는 개인적으로 실용적인 세상에서 자기 설명 프로그램이나 API의 현실을 믿지 않습니다.

내 논문에 대한 전체 API의 문서를 수동으로 분석 한 내 경험은 서명만으로 전달할 수있는 것보다 더 많은 정보를 너무 자주 가지고 있어야한다는 것을 시사합니다. 언어에서 인터페이스 주석을 제거하면 대안이란 무엇입니까? 문서화는 옵션이 아닙니다. 외부 문서는 읽을 가능성이 적습니다.

내부 문서에 관해서는, 사람들이 더 잘 쓰도록 설득하기 위해 문서를 줄이려는 요점을 볼 수 있습니다. 그러나 의견은 많은 협업 및 조정 목적으로 제공되며 사물에 대한 인식을 높이기위한 것입니다. 이러한 세부 사항을 extenral 위치로 금지함으로써 툴링이 훌륭하지 않으면 미래의 독자의 인식에 올 가능성을 줄입니다.

다른 팁

당신이하고있는 일을 언급하지 말고 왜 그렇게하는지 말하지 마십시오.

깨끗하고 읽을 수 있으며 간단한 코드가 적절한 변수 이름을 지원할 수있는 간단한 코드로 처리됩니다. 주석은 코드 자체가 표시 할 수없는 코드에 대한 더 높은 레벨 구조를 보여줍니다.

어, 테스트하는 동안 라인 (또는 줄)을 신속하게 댓글을 달 수 없었습니다. 특히 스크립팅 할 때 나에게 성가신 소리가납니다.

일반적으로 의견은 디자인이 좋지 않은 사마귀이며, 특히 개발자가 명확하게 밝히는 것이 분명한 댓글이 무엇인지에 대한 단서를 얻지 못하고 의견을 작성하여 그것을 보충하려고 시도했습니다.

의견이 유용한 장소 :

미래 프로그래머가 비즈니스 요구 사항을 이해할 수 있도록 수정 옆에 티켓 번호를 남기도록
특히 까다로운 해킹을 설명합니다
코드에 대한 비즈니스 로직에 대한 주석
API 문서의 간결한 설명이 있으므로 제 3자가 API를 사용할 수 있습니다.

모든 상황에서 프로그래머는 설명적인 코드를 작성하기 위해 노력해야하며 서면으로 작성된 코드를 설명하는 의견을 작성하지 않아야합니다. 즉, 언어가 의견을지지 해야하는 유효한 이유가 많이 있다고 생각합니다.

코드에는 두 가지 독특한 청중이 있습니다.

컴파일러
우리처럼 인간

주석을 모두 제거하기로 선택한 경우, 귀하가 취하고있는 가정은 컴파일러에만 제공되는 것입니다.

물론 Klingon 인 당신은 당신이 인간이 아니기 때문에 의견이 필요하지 않을 수 있습니다. 아마도 당신은 대신 IL에서 말함으로써 당신의 능력을 분명히 보여줄 수 있습니까?

당신은 그렇지 않습니다 필요 릴리스 모드에서는 모두 사라 졌기 때문에 코드의 단일 주장입니다. 그러나 C ++에 주장이 내장되어 있지 않았을 때 누군가가 대체하기 위해 Assert 매크로를 썼습니다.

물론 당신은 그렇지 않습니다 필요 어느 쪽이든, 같은 이유로 댓글. 그러나 의견없이 언어를 디자인하면 사람들은 다음과 같은 일을 시작합니다.

HelperFunctionDoesNothing("This is a comment! Blah Blah Blah...");

궁금해. 누군가가 댓글이 포함 된 정적 문자열을 선언하는 것을 막고 나머지 func/method/procedure/battle/uthern의 변수를 무시하는 방법은 무엇입니까?

var useless_comment = "Can we destroy our enemies?"
if (phasers on full) return Qapla'

언어에는 댓글이 필요합니다. 의견의 95% 이상을 명확한 코드로 대체 할 수 있지만 문서화해야 할 가정이 여전히 있으며 해결중인 외부 문제가있는 경우 절대적으로 문서화해야합니다.

코드를 변경하여 필요를 제거 할 수 있는지 먼저 고려하지 않고도 의견을 작성하지 않지만 때로는 코드를 변경할 수는 없습니다.

모든 소스 코드는 기본적으로 저작권이 있습니다. 종종 좋습니다.

소스 코드를 읽는 사람이 저작권을받는 것을 상기시킵니다.
사람들에게 해당 소스 코드 파일에 대한 라이센스 용어가 무엇인지 알려줍니다.
그들이 보호 된 상표 비밀을보고 있는지 여부를 알려주세요

불행히도 의견이 없으면이 작업을 수행하기가 어렵습니다.

나는 몇 줄을 언급 한 유일한 사람입니까? 암호 여러 목적을 위해?

인간이 코드를 주석 할 수 있어야한다는 것은 사실이지만, 언어가 댓글을 직접 지원할 필요는 없습니다. 대부분의 언어의 경우 한 줄의 주석을 삭제하는 스크립트를 작성하는 것은 사소한 일입니다 (예 : 모든 줄은 '#'또는 다른 문자)은 컴파일러를 실행합니다.

그러나 실제로, 나는 내가 가장 좋아하는 난해한 프로그래밍 언어조차도 의견을지지한다는 사실에 놀랐고 실망했습니다. brainf ** k 그리고 공백. 이 언어는 읽기가 어렵 기 때문에 의견을지지해서는 안된 것 같습니다. (내가 가장 좋아하는 난해한 언어와 반대로 : lolcode, 이는 lolcats-speech에서 자체 문서화를위한 것입니다)

나는이 시점에서 다른 답변자들과 반대 할 것입니다. 나는 Klingon 프로그래밍 언어에 대한 당신의 비전에 충실하고 의견을지지하지 않습니다!

주석에 대한 요점은 종종 코드와 관련된 경향이 있다는 것입니다. 중복성을 추가 할 때마다 이런 종류의 불일치 위험이 있습니다.

실제로 그룹이 NLP를 사용하여 일부 큰 시스템에서 댓글 잠금을 분석 한 다음 정적 분석 결과와 비교할 때 본 흥미로운 연구가 있습니다.

문맹 프로그래밍이 코드만큼 많은 댓글을 작성하지 않습니까? 확실히, 내가 문맹 프로그래밍에서 본 것의 대부분은 더 많은 의견이 아니라면 코드만큼 많은 설명을 가지고 있습니다.

당신은 당신의 언어로 쓰는 개발자가 명확한 코드를 작성하기 위해 추가 노력을 기울일 것이라고 생각할 수도 있지만 실제로는 onus가 실제로 너 언어를 설계합니다 그래서 댓글을 달 필요가 없다는 표현. 지옥, 영어조차도 그런 것과 같지 않습니다 (우리는 여전히 괄호!). 당신의 언어가 그렇게 설계되지 않았다면 Brainfuck만큼 유용하고 Brainfuck의 인기와 존중을 즐길 수 있습니다.

링크를 추가해야합니까 아니면 링크가 주석과 유사하다고 간주됩니까?

게다가, 사람들은 끈을 고조롭게하고 변수 이름을 오용 해야하는 경우 주석을 추가 할 수있는 방법을 찾을 수 있습니다 (주석을 찾는 것 외에는 아무것도하지 않습니다). 당신은 읽었습니까? Godel Escher Bach?

주석 시설을 완전히 제거하는 것은 나쁜 생각입니다. 분명히 개발자는 최소한의 의견을 가진 코드를 작성하는 법을 배워야합니다. 즉, 자체 문서화 코드를 작성하려면 많은 일이 발생하는 이유를 설명 해야하는 경우가 많습니다. 다음 사례를 고려하십시오.

새로운 개발자가 코드를 유지하기 시작할 수 있으며 원래 개발자가 프로젝트에서 왼쪽/ 출발했습니다.
사양 또는 시장 요구 사항의 변화는 대응 직관적 인 무언가로 이어집니다.
특히 오픈 소스 인 경우 올바른 통지를 복사하십시오 (일부 오픈 소스 Libs 가이 작업을 수행해야 함)

또한 새로운 프로그래머가 더 많은 의견을 제시하는 경향이 있으며 전문 지식을 개발함에 따라 코드는 자체 문서화되고 간결 해지는 경향이 있습니다. 일반적으로 의견은 왜 또는 무엇이 아닌지에 관한 것입니다.

아니요 - 의견이 필요한 단일 프로그래밍 언어가 없습니다.

언어는 컴퓨터를위한 것입니다. 의견은 인간을위한 것입니다. 0% 댓글로 프로그램을 작성할 수 있습니다. 올바르게 또는 잘못 실행됩니다. 100% 댓글로 프로그램을 작성할 수 없습니다. Main () 등을 컴파일하지 않거나 스크립팅 언어의 경우 정확히 아무것도하지 않습니다.

게다가, 실제 프로그래머는 자신의 코드를 댓글을 달지 않습니다. Klingons처럼.

URI의 답변에 동의하지만, 언어도 언어를 만들었습니다. (ICHBINS.) 언어는 자체 컴파일러를 깨끗하게 표현할 수 있지만 가능한 한 간단해야했습니다. 당신이 댓글없이 그렇게 할 수 있기 때문에 그들은 제조되었습니다.

코드에 내장 된 주석 대신 텍스트에 중첩 된 코드를 가진 문맹 프로그램 스타일을 사용하는 문맹 프로그램 스타일이 약간 다르게 진행되는 개정을 계속 진행하고 있습니다. 나중에 예제/테스트 케이스를 일류 언어 기능으로 얻을 수도 있습니다.

Klingon 해킹과 함께 행운을 빕니다. :-)

Javadoc에게 얼마나 감사하는지 말할 수 없습니다. 의견 내에서 설정하는 것이 정말 간단합니다. 따라서 의견이 유용한 의미입니다.

물론 언어에는 댓글을 달 필요가 없습니다. 그러나 (유용한) 프로그램에는 의견이 있어야합니다 ... 문맹 코드에 의견이 부족하다는 당신의 아이디어에 동의하지 않습니다. 아주 좋은 코드는 주석으로 쉽게 이해할 수 있지만 없이는 어려움이 있습니다.

나는 많은 상황에서 의견이 필요하다고 생각합니다.

예를 들어 알고리즘을 생각해보십시오. C로 작성된 함수가 여행 판매원 문제,이 문제를 다루는 데 사용할 수있는 광범위한 기술이 있습니다. 그리고 코드는 일반적으로 본질적으로 비밀합니다.

주석을 사용하여 매개 변수와 사용 된 알고리즘을 명시 적으로 설명하지 않으면이 코드를 재사용하는 것은 거의 불가능합니다.

코드에 대한 의견없이 살 수 있습니까? 물론, 그것은 더 쉬워지지 않을 것입니다.

프로그래밍 언어에 주석이 필요합니까?

아니요. 그랜드 체계에서 컴파일러는 댓글에 대해 덜 신경 쓰지 못했으며 코드가 더 낮은 공통 분모로 연삭하기를 원합니다.

프로그래밍 언어가 주석 구조를 제공하는 것이 유용합니까?

예. 의견은 프로그래머에게 매우 유용하며 자신이하는 일을 아는 것처럼 가짜가 아니라 디버깅 및 유용하게 문서화 할 때도 매우 유용합니다.

의견은 코드를 읽는 사람 (아마도 미래의 당신”을 읽는 사람을 안심시키기 때문에 유용합니다.

의견이 불가능한 언어를 만드는 것이 생각보다 어려울 것입니다.

if (false) {
    print("This is a comment. Chew on that, Klingons!")
}

나는 그 질문이 언어가없는 언어가 얼마나 자급적이지 않을 것이라고 생각합니까? 예를 들어, 다른 코드 내에서 사용되는 DLL으로 컴파일된다면, 필요한 것, 변경 및 반환 측면에서 함수 서명을 넘어서 무엇이 아는가? 예를 들어 Visual Studio 내의 객체 브라우저와 같은 문서로 사용할 수있는 함수 위의 주석으로 매우 쉽게 수행 할 수있는 일을 표현하기 위해 수십 개의 문자 인 기능 이름을 갖고 싶지 않습니다.

물론!!

주된 이유는 초보자 개발자입니다. 모든 사람이 문맹 코드를 작성하는 방법을 아는 것은 아닙니다. 실제로 수백만 명이 있습니다.

우리 모두는 어느 시점에서 시작합니다.

그러나 "전문가"개발자만을 목표로하는 경우, 왜 언어를 먼저 귀찮게합니다. 당신은해야한다 나비 사용 !!!!!!!! 그것이 실제 개발자가 사용하는 것입니다!

댓글은 필수입니다. 원하는 경우 (#// ##/시퀀스를 사용하여 주석이나 그와 비슷한 것을 만들기 위해) 더 어렵게 만들려고 노력하십시오.

"코드는 프로그래머가 이용할 수있는 좋은 문서입니다. 그러나 이것은 매우 이상적인 조건이지만 모든 사람이 항상 좋은 코드를 작성하는 것은 아닙니다. 따라서 미래의 의견에 잘 쓰지 못한 코드를 만들기 위해서는 모든 사람이 항상 좋은 코드를 작성하는 것은 아닙니다. 필수의.

한 번은 VB 앱 (독점에서 영감을 얻은 바보 같은 보드 게임)을 작성했습니다. 어느 코멘트. 그러나 나는 우리에게 의견을 말한 선생님을 화나게하기 위해 그렇게했습니다. 관련 있는, 나중에 기억할 수있었습니다. "

완벽한 코드에는 0 주석이 필요합니다. 완전한 초보자로 간단하고 이해할 수 있어야합니다.

모든 코드에는 주석이 필요합니다. 1 줄 또는 2 줄로 작성한 모든 기능의 이유와 작업을 설명하려고합니다.

자신을 완벽한 세상에만 설명하는 코드는 항상 이상한 해킹이나 프로퍼 방식 대신 빠른 멍청한 일을 해야하는 이유가 있습니다. 기억해야 할 가장 좋은 점은 코드가 왜 일을하는지에 대해 언급하는 것입니다. 좋은 코드는 시간의 99%가 무엇을하는지 설명합니다.

스도쿠 퍼즐 (3 합리적으로 간단한 루프)을 해결할 수있는 코드와 같은 간단한 것을 작성하고 3 개월 후에 읽으십시오. 당신은 정확히 명확하지 않은 것을 발견 할 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow