검색을했지만 찾고있는 것을 찾지 못했습니다.이 질문이 이미 요청 된 경우 언제든지 연결해주세요.

이달 초이 게시물이 작성되었습니다.

http://net.tutsplus.com/tutorials/php/why-youre-a-bad-php-programmer/

기본적으로 요약하면 의견을 쓰지 않으면 나쁜 프로그래머입니다. 내 개인적인 의견은 코드가 설명 적이어야하며 코드가 자체 설명 할 수 없다면 주석이 필요하지 않다는 것입니다.

주어진 예에서

// Get the extension off the image filename  
$pieces = explode('.', $image_name);  
$extension = array_pop($pieces);  

저자는이 코드에 의견을 주어야한다고 내 개인적인 의견은 코드가 설명하는 함수 호출이어야한다는 것입니다.

$extension = GetFileExtension($image_filename);

그러나 의견에서 누군가가 실제로 그 제안을했습니다.

http://net.tutsplus.com/tutorials/php/why-youre-a-bad-php-programmer/comment-page-2/#comment-357130

저자는 논평자가 "그 사람들 중 하나", 즉 나쁜 프로그래머라고 말함으로써 응답했다.

자기 서술 코드와 주석 코드에 대한 다른 사람들의 견해는 무엇입니까?

자체 문서화 코드 작성을 선호합니다. 이에 대한 안내서는 Clean Code 입니다.

물론 이것은 코멘트를 절대로 사용해서는 안된다는 의미는 아닙니다. 그들에게는 그들의 역할이 있지만 IMHO는 신중하게 사용해야합니다. SO에 대한 나의 이전 답변은 주제에 대한 나의 생각을 더 자세히 설명합니다.

물론 @Niphra가 지적했듯이, 내가 깨끗하다고 ​​생각하는 것이 다른 사람들이 실제로 이해할 수 있는지 항상 다시 확인하는 것이 좋습니다. 그러나 이것은 연습 문제이기도합니다. 유니 코드로 돌아가서 나는 단순히 모든 코드 엔터티에 대해 이상하고 재미있는 이름을 사용했기 때문에 암호 코드를 작성했습니다. 선생님이 저의 과제 중 하나를 거절 할 때까지, 어떤 모듈이 주 모듈인지 알아낼 수 없다는 것을 공손하게 지적했습니다. 요즘 나는 팀원들로부터 불만을 거의받지 않습니다.

코드가 수행하는 작업을 문서화해서는 안되지만 코드가 수행하는 이유를 문서화해야합니다.

많은 이름 지정 트릭이 이유와 이유를 노출시키지 않으므로 다양한 코드 비트의 목적을 설명하기 위해 주석을 추가해야합니다.

다른 모든 의견은 안전하게 제거 할 수 있습니다.

실제로 자체 설명 코드를 믿지 않습니다 . 이 더 읽을 수있는 코드 와 덜 읽을 수있는 코드는 (원래의 저자로) 그것의 지식, 그것을 읽는 사람, 및 코드 함수의 지식, 언어에 따라. 그러나 아니요, 여전히 ... 짧은 의견으로 설명해야합니다.

내가 생각하는 영역에 있다고 분명하게 생각하는 것은 아마도 완전히 다른 무언가를 생각하고 코드 의이 부분을 다시 사용해야하는 1 년 후에는 분명하지 않을 것입니다.

따라서 코드를 주석 처리하십시오. 물론 모든 라인 (좋은 하늘, 아니오)은 아니지만 함수 / 서브 루틴 / 모듈 또는 특히 까다로운 부분 위에 몇 줄의 주석을 달고 그것이 무엇을하는지 짧게 말하십시오. 당신은 1 ~ 2 년 안에 자신에게 감사 할 것입니다.

운 좋게도,이 논의에 관한 두 진영이 여기에 나타나 있으며, 두 가지에 대한 찬반론이 언급되었습니다.

나는 두 진영이 겹치는 논증을 가지고 있다고 생각하며, 실제로는 그들 대부분을 달성하는 방법이 조금 다릅니다.

겹치는 인수

• 코드를 읽을 수 있어야합니다.
• 주석은 코드와 똑같은 말을하지 말고 필요한 경우 추가 정보를 제공해야합니다.
• 모든 변수 / 함수 이름에는 생각 / 주문을 잘 표현해야합니다.
• 중복 코드를 방지해야합니다.

이제 주요 차이점은 이러한 주장 중 일부에 얼마나 많은 가중치가 적용되는지입니다.

자체 설명 코드

• 주석이없는 경우보다 잘못된 주석이 있으므로 주석이 더 이상 사용되지 않을 수 있으므로 사용을 최소화하십시오.
• 주석은 코드의 중복입니다. 코드로 작성 될 수있는 모든 것은 코드로 작성되어야합니다.

더 많은 의견

• 주석은 코드보다 읽기 쉽습니다. 평범한 영어가 무언가를 설명하는 데 더 좋습니다.

• 일반 코드는 종종 애매 모호한 원인이되므로 어쨌든 주석을 달아야합니다. 이것을 코드로 설명하려고하면 이름이 너무 길어집니다. 또한,이 '추가'정보는 끊임없이 처음 접할 때만 필요합니다.

두 캠프는 모두 유효한 주장이 있지만 하나의 문제를 해결하기 때문에 한 캠프를 열광적으로 따라 가지 말아야합니다.

Clean Code 라는 책 에서 코드는 한 번만 호출되는 수많은 작은 메서드로 나뉩니다. 코드를 문서화하기위한 유일한 이유 (및 더 쉬운 TDD)를 위해 메소드가 작성됩니다. 이로 인해 Function Hell 이 발생 합니다. 코드는 원래 코드보다 읽기 쉽지 않으며 리팩토링 중에 재사용 가능한 코드를 캡슐화 할 생각은 없었습니다.

반면에 '댓글이 좋기'때문에 모든 함수가 주석 처리 된 API가 종종 있습니다. 주석을 달아야 할 것은 여전히 ​​그렇지 않습니다.

"죄송하지만 그 사람은 미안합니다."

나는 그가 왜 논평을 좋아하지 않는지 궁금합니다. : P

진지하게, 코딩은 너무나도 많은 기술로, 그처럼 쓸데없는 진술을 할 수는 없습니다. 때로는 주석이 필요하고 때로는 더 나은 이름의 함수가 필요합니다. 보통 둘 다.

문맹 프로그래밍을 극단적 인 스타일로 찾아보십시오.

짧고, 더 나은, 정답

잘 작성된 "자체 문서화 된 코드"가 필요한 것은 반 패턴 일 뿐이며 "이유"를 설명하는 주석에 대해 예외를 만들 때도 죽어야 합니다. 프로그래머가 한 눈에 알아볼 수있을 정도로 명확한 알고리즘의 모든 코드를 항상 작성할 수 있다는 사실은 신화입니다. 더 중요한 것은 분명한 코드를 작성 한다고 생각하는 프로그래머 는 그렇지 않다는 것입니다.

주석 보다 훨씬 더 나은 답변은 "왜"라는 설명에만 사용 되어야합니다.

• "물론"(물론) 설명
• 코드가 복잡하거나 목적이 불분명하고 더 단순화 할 수 없거나 가치가없는 경우에만 개별 라인에서 "무엇"을 설명하십시오
• 이해를 가속화하고 필요한 것을 찾는 코드 블록에 대한 "무엇"설명

백업 설명

사람들은 사람들이 주석을 사용하는 유일한 이유는 코드 줄의 의미를 설명하는 것이라고 잘못 생각합니다. 진실은 코드 주석의 큰 목적은 그것을 만들입니다 빨리코드를 살펴보고 원하는 것을 찾을 수 있습니다. 나중에 코드로 돌아 오거나 다른 사람의 코드를 읽을 때 잘 작성된 코드의 섹션을 읽고 이해할 수는 있지만 맨 위의 코드 섹션에서 수행하는 작업을 나타내는 주석을 빠르고 쉽게 읽을 수는 없습니다. 내가 찾고있는 것이 아닌 경우 완전히 건너 뛰시겠습니까? 잘 작성 되었더라도 몇 가지 의견을보고 전체 기능을 이해할 수 있다면 왜 거기에 앉아서 코드를 알아 내는가? 그렇기 때문에 우리는 함수에 설명적인 이름을 사용합니다. 아무도 내 기능에 대해 설명적인 이름을 사용할 필요가 없다고 말합니다.

예를 들어, 다른 사람의 기능을 살펴보고 있다면 코드를 통해 한 줄씩 이동하여 수행중인 작업을 확인하거나 함수 전체에서 잘 작성된 3 개의 주석을 확인하여 기능이 수행중인 작업과 위치를 정확하게 볼 수 있습니까? 하고 있어요?

또 다른 안티 패턴은 코드를 주석 처리하기 위해 함수를 과도하게 사용하는 것입니다. 잘 명명 된 함수는 코드 문서의 중요한 부분이지만 프로그래머는 다른 곳에서는 사용하지 않는 2-3 줄의 코드를 문서화 목적으로 함수로 분리하기도합니다. 주석을 과도하게 사용하는 것보다 함수를 과도하게 사용하는 것이 더 좋은 이유는 무엇입니까? 이와 같은 함수를 사용하는 것은 GOTO 문을 수용하는 것과 동일합니다. 스파게티 코드를 생성하면 따라 가기가 어려울 수 있습니다.

본질적으로 사람들이 지속적으로 코드를 공유하고 사람들이 코드를 완벽하게 만들 시간이없는 엔터프라이즈 환경에서 작업 할 때 몇 가지 좋은 설명은 많은 시간과 좌절을 줄일 수 있습니다. 그리고 당신은 가벼운 속도로 코드를 읽을 수있는 전문가 일지 모르지만, 사무실의 모든 사람이 아닐 수도 있습니다.

글쎄, 당신은 또한 당신에게 명백하거나 "자가 문서화"하는 것을 기억해야합니다. 그래서 나는 모든 것에 대해 언급합니다.

자체 문서화 코드의 장점은 해당 기능 내에서 다음을 찾을 수 있다는 것입니다.

$pieces = explode('.', $image_name);  
$extension = array_pop($pieces);  

함수 이름이 두 줄이기 때문에 설명이 필요 없습니다. 상황이 더 복잡해지면 코드 몇 줄마다 설명이 포함 된 함수로 감싸거나 필요한 경우 주석을 사용해야 합니다 .

나는 그것이 왜 그리고 / 또는 문제가되어야 하는지를 이해하지 못했습니다. 그렇습니다. 가능하면 코드를 최대한 많이 문서화하십시오. 그렇지 않으면 명확하지 않은 부분에 주석을 추가하십시오.

주석과 자체 문서화 된 깨끗한 코드가 다릅니다. 코드는 일을 하는 방법 에 관한 것입니다. 그리고 주석은 언어에 관계없이 코드로 설명 할 수없는 이유 부분을 ​​포함해야합니다. 또한 언어가 매우 제한적이고 계약, 정적 사양 및 어설 션이없는 경우 주석은 코드의 경계 문제를 다루어야합니다.

이 경우 설명 기능을 쉽게 수행 할 수 있습니다. 그러나 나는 코드가 자체 문서화되었다고 생각하는 훌륭한 프로그래머가 만든 많은 코드를 읽었으며 그들에게 명백한 것은 실제로 혼란 스러웠습니다.

$ extension = GetFileExtension ($ 이미지 _ 이름);

예를 들어, 이미지 이름 배열을 보낼 수 있습니까, 아니면 하나의 이미지 만 가져 옵니까? 파일 형식을 지원합니까, 아니면 일부만 지원합니까? 그것은 나를 위해 줄을 확보합니까, 아니면해야합니까? 파일 형식이 존재하지 않으면 알려줍니까?

물론, 나는 이것을 조금 늘리고 있습니다. 그러나 audio_bandwidth 및 video_bandwidth는 자체 문서화 이름이라고 생각한 프로그래머를 기억합니다. 오디오는 바이트 단위로, 비디오는 킬로바이트 단위로 표현해야했습니다. 그것을 알아낼 시간이 많이 걸렸습니다.

하나는 다른 하나를 배제하지 않습니다. 코드가 자체 주석 처리되어 있어도 자체 주석 코드가 수행 하는 이유 를 설명하기 위해 정기적 인 주석이 필요할 수 있습니다 .

나는 그 기사에 동의하지 않으며 어느 정도 당신에게 동의합니다. 좋은 방법 이름, 좋은 변수 이름 및 단일 방법을 수행하는 작은 방법을 사용하는 경우 코드를 따라야합니다.

영리한 코드는 끔찍하게 읽고 유지하기 때문에 영리하지 마십시오. 키워드 : 유지 !

내 의견은 의견이 무엇을 설명하지 말아야하는 이유를 설명해야한다는 것입니다. 이 가상의 완벽한 세계에서 코드는 쉽게 읽을 수있을 정도로 깨끗하며, 수행중인 작업을 설명 할 필요는 없지만 왜 이런 식으로 또는 그렇게했는지 선택해야합니다.

소스 제어 시스템을 사용하는 경우 커밋 메시지를 사용하여 모든 사람과 자신에게 주어진 시간에 무엇을했는지 더 중요한 이유를 알 수 있습니다.

문서를 피하고 싶 듯이 주석을 작성하지 마십시오. 프로그래밍 언어 자체와 관련하여 모든 사람들은 거의 동일한 어휘와 구문 세트에서 작동합니다.

앱이 특정 도메인 용인 경우 모든 사람이 공통 어휘에 동의 및 / 또는 설정하는 것을 어렵게 할 수 있습니다. 우리는 약어와 광대 한 전문 용어를 피하도록 배웠습니다.

에 빗다

그리고 아닙니다

이자 지분 이전의 세금 감가 상각 및 상각

하나를 모른다면 아마 다른 것을 이해하지 못할 것입니다. 회사가 일반적이지 않은 구현을하는 경우, 그 분야에서 경험이있을 수도 있지만이 특정 회사에서는 그렇지 않은 다음 프로그래머에게 의견이 도움이 될 것입니다.

코드의 문서 와 표현성 을 구별해야한다고 생각 합니다.

코드를 디버깅하거나 검토 할 때 책을 읽지 않습니다. 대부분의 경우 메소드에서 메소드로 이동하고 마음에 빠르게 연결하여 런타임에 무슨 일이 일어나고 있는지에 대한 기본적인 이해를 원합니다. 코드를 문서화하는 것이 아니라 해당 프로세스에서 중요한 코드 서명 의 표현성 , 즉 즉시 식별하고 자신의 내부 호출 스택에 추가 할 수있을 정도로 의미있는 능력입니다. 그 시점에서, 우리의 뇌는 (적어도 내 방식으로 작동합니다.)) 큰 주석 블록을 도움이 아니라 소음으로 간주하는 경향이 있습니다. 따라서 여기서는 한 줄 주석 또는 더 나은 자체 설명 방법과 객체 이름으로 충분합니다.

특정 수업이나 기능에 대한 "책을 읽고"싶다면 단위 테스트에서 더 좋은 곳을 찾으십시오. 잘 설계된 단위 테스트는 본질적으로 의도적으로 드러나고 가장 두꺼운 주석 블록보다 훨씬 더 많은 문서화 (즉, 설명, 상세)입니다. 실제 코드에 대한 이러한 기대. 합격 시험은 주장하는 것이 사실임을 입증하기 때문에 문서 측면에서 어떤 주석보다 백 배 더 신뢰할 수 있습니다.

일부 코드는 자체 문서화되어 있지 않으며 해당 부분을 이해하고 테스트 한 동료 인간의 의견이 필요합니다. 내가 가지고있는 것은 그것을 이해하기에 충분하지 않다고 생각합니다.

//
// iterative version
//
Node* ReverseList( Node ** List ) 
{

  Node *temp1 = *List;
  Node * temp2 = NULL;
  Node * temp3 = NULL;

  while ( temp1 )
  {
    *List = temp1; //set the head to last node 
    temp2= temp1->pNext; // save the next ptr in temp2
    temp1->pNext = temp3; // change next to privous
    temp3 = temp1;
    temp1 = temp2;
  }

  return *List;
}

나는 일반적으로 자기 문서화 코드를 작성하는 것을 선호한다.

대학에서 우리는 영어로 모든 코드 줄을 주석으로 바꾸는 법을 배웠다.

개인적으로, 나는 코드에서 지옥을 어수선하게 생각하여 주석이나 코드 인 경우 보다 읽기가 쉽지 않습니다 . 나는 C # 코더이며, 내가 항상하는 유일한 의견은 IntelliSense 문서로 해석되는 "삼중 슬래시"주석 블록입니다. 내가 무언가를하는 특정한 방법에 대해 특히 죄책감을 느낀다면, 특히 비밀스러워 보인다면, 더 설명 할 것이지만, 그것에 관한 것입니다.

IMO : 자체 문서화 코드는 변수 및 메소드 이름에 의미 있고 상황에 맞는 이름이 부여되어 목적이 무엇인지 설명하는 코드입니다.

코드를 여러 번 다시 방문했지만 여전히 도메인을 아는 사람에게 의도를 분명히하는 방법을 찾지 못한 경우. 함수를 다시 작성하십시오. 결국 그것은 10-20 줄을 넘지 않습니다. 어쨌든 함수를 더 이상 다시 쓰면 길어지고 읽을 수없는 이유 중 하나입니다. : rinse-repeat

어쩌면 코드가 무엇을하고 있는지 명확하지 않으며 동료에게 도움을 요청한 것을 기억합니다. 그렇다면 우리 모두 진화하는 Linux cuz를 도와 주셔서 감사합니다. 바로 여러분이 쓰고있는 커널 코드입니다. 상단에서 헹구지 않으면 :)

단순히 의견을 쓰지 마십시오.

128-129 페이지의 Code Complete 2nd edition을 확인하십시오.

추상 데이터 유형은이 수수께끼로부터 당신을 구할 것입니다. 자체 문서화 코드가 갈 길입니다. 의견이 도움이 될 수 있지만

저수준 구현이 아닌 실제 엔터티

댓글 사용을 피할 수 있습니다.

주석에 대한 한 가지 점은 주석을 한 번 작성하지만 함수를 구현할 때 표시되지 않고 함수를 변경할 때만 표시됩니다.

주석은 Delphi 2009+ 또는 JavaDoc이 작동하는 방식으로 IDE에서 해석 될 때 매우 유용하지만 구조화 된 마크 업 언어에 가깝기 때문에 문서를 프로그래밍하는 것이 현명합니다.

나는 당신이 세계 최고의 프로그래머가 될 수 있기 때문에 코드 자체가 문서화되지 않는다는 진언을 믿는다. (Ada), 무슨 일이 일어나고 있는지에 대해 이해하지 못하지만 왜 그리고 짧은 이유를 문서화한다면 코드가 어떻게 작동하는지, 앞으로 자신과 다른 사람들을 도울 것입니다.

의견은 필수입니다. 코드를 작성할 때 현재 요구 사항뿐만 아니라 미래에 코드를 읽고, wtf를 파악하고, 수행하고있는 이유 및 이유를 파악한 후 수정하는 방법을 쓰는 사람들을 위해 작성하기 때문입니다.

코딩 / 프로그래밍 할 때이 점을 명심해야합니까?

내가 작업중인이 코드의 미래 코더에 대해 이것을 쉽게 이해하고 수정할 수있게하려면 어떻게하면 좋은 일을 할 것입니다. 실패하면 다른 사람들이 코드를 수정하기가 어려워지고 결코 그렇지 않을 것이라고 상상하지 마십시오.

대부분의 일에서 나는 항상 다른 사람들의 코드를 수정해야했고, 가장 끔찍하게 작성되고 문서화가 잘되지 않았습니다.

따라서 코드 문서 자체를 생각하는 습관은 실사를하지 않는 것입니다.

프로그래머로서 우리는 경험이 부족한 프로그래머에게는 전혀없는 것처럼 보일 수있는 자제를 실천해야하지만, 다른 사람들의 코드에 대해 겪었던 모든 끔찍한 경험을 피하려면 습관이 있어야합니다. 또는 몇 년 후 몇 달 후에 자체 코드를 볼 수도 있습니다.

확인 http://thedailywtf.com을 그들은 단지 자신의 실사를하지 않았다 프로그래머에 대한 유머러스하지만 실제 이야기의 톤이 ..