“재미있는 댓글”은 나쁜 습관입니까? [닫은]

37

소스 문서에 "부활절 달걀"을 추가하는 것이 전문가가 아닌지 묻고 싶습니다. 아마 당신이 읽게 에 StackOverflow의 소스 문서에 재미 덧글에 대한 설문 조사를하고, 나는 개인적으로 (예를 들어, 공개 API 문서에이 약한 물건을 재미를 포함하여, 내 작품 중 많은 그런 것들에서 발견 (여부) 한 BZZZTT을! 1! 일 안드로이드 공개 문서에서는 적어도 12 가지 이상의 예제를 제공 할 수 있습니다.

나는 스스로 논쟁의 여지가 있기 때문에 나 자신에 대한 최종 의견을 얻을 수 없다.

찬성론 :

누군가를 응원하고 하루를 더 재미 있고 생산적으로 만들 수 있습니다. 소스 코드의 주요 부분은 어쨌든 (프로젝트가 올바르게 수행 된 경우) 주석 처리 할 필요가 없습니다. 특정 방법 (예 :)이 자체 설명이거나 이상한 크 래핑 코드 더미 인 경우에는 할 수 없습니다 재미있는 농담은 의사가 얻을 수있는 정보에 해를 끼치 지 않습니다.

단점 :

매우 집중적이거나 좌절 한 경우, 마지막으로 필요한 것은 누군가의 어리석은 농담이며 문서화 된 코드 부분에 대해 필요한 정보를 제공하는 대신 더욱 좌절하게 만들 수 있습니다. 모든 사람이 그렇게하기 시작하면 문서가 어떻게 보일지에 대한 아이디어는 끔찍합니다. 또한 농담을 쓰는 사람은 재미 있거나 흥미롭고 / 읽는 시간을 낭비한다고 생각하는 유일한 사람 일 수 있습니다.

어떻게 생각해?

source-code

— 어떤 사람
소스

질문과 관련된 사이트 FAQ 및 지침을 읽으십시오. 이 질문은 실제로 해당 지침을 충족하지 않습니다.

— Walter

8

@Walter : 그것은 programmers.stackexchange.com/questions/50928/… 과 거의 같은 질문 이지만, 욕설보다는 재미있는 의견이며 한 달 전에 질문이 연결되어 있지 않습니다. 이 질문이 FAQ를 충족하며 코드 작성시 모범 사례와 관련이 있다고 주장하는 데 시간을 낭비하지 않겠습니다.

— 누군가

2

7 투표,이 Q는 분명히 원합니다. 개인적으로 나는 당신이 여러 번 언급 한 "con"에 의해 화나게 되었으나 "pro"에 대한 논쟁을 볼 수 있으므로 결과가 무엇인지 궁금합니다. (btw를 만난 최악의 사람은 새끼 고양이를 가리키는 BB 총의 "유쾌한"사진이 우리의 모든 개발 서버의 홈 페이지에 있어야한다고 생각한 프로그래머였습니다. Sigh ...)

— James

@sombody-당신은 요점을 가지고 있지만 재미있는 의견은 괴롭힘 소송의 대상이 될 수 있습니다. 다른 질문을 마무리하는 것을 고려할 것입니다 (게시 될 때 그 권리가 있는지 확실하지 않습니다).

— JeffO

1

나는이 게시물을 다시 열어야한다는 데 동의하지만, 투표권을 행사할 수없는 원인은 투표 할 수 없습니다. 프로그래머를 SO와 분리시키는 요점은 이와 같은 질문입니다. 이 질문에 대해 22 표를 더해 커뮤니티에서이를 분명히 요구합니다.

— RoboShop

12

나는 재미있는 의견이 시간을 낭비한다고 생각합니다. 쓸 시간을 낭비하고, 읽을 시간을 낭비하고, 동료들에게 (거의 항상) 단지 수수께끼 같은 재미있는 말을 동료에게 보여주기 위해 시간을 낭비한다고 생각합니다.

그러나 ... 실제로 매일 매일 100 %로 일하는 사람은 아무도 없으며 (그렇다면 이런 사이트는 비어있을 것입니다) 진정한 유머는 하루를 깨고 사기를 유지하는 데 도움이됩니다.

내가 읽은 모든 '재미있는'댓글은 당시에 재밌었기 때문에 여전히 그것에 반대 투표를 할 것입니다. -농담.

재미있는 의견이 실제로 재밌 으면 내 마음이 바뀔 것입니다. 그러나 일단 농담을 장려하면 욕이나 모욕 또는 악의를 장려합니까?

— 아 멜빈
소스

5

+1 당신은 무언가를 고쳐야 할 때만 그 의견을 이해하지 못하며 버그 수정을 할 때 그 주제에 대한 다른 개발자의 '영리한 농담'을보고 싶지 않습니다. 농담을 생각하는 데 시간을 소비하지 말고 코드를 더 명확하게 작성하고 버그를 수정하는 등의 시간을 보내십시오. 또한 리팩토링 된 경우 '농담'은 어떻게됩니까?

— Jan_V

2

따라서 그것은 육류 분야의 유머와 같습니다. 재밌는 것이 좋으며 모든 것이 아닌 것이 좋습니다.

— Dan Ray

1

해를 끼치 지 않는 한 영리한 +1. 퍼팅 stop() //hammertime정지의 모든 인스턴스에서하는 것은 재미 없어.

— glasnt

@glasnt-그것은 정말로 재미있는 의견입니다-그러나 그것은 반복 2를 자극하고, 점점 더 자극적입니다!

— amelvin

의견에 유머를 허용하는 것은 완벽하게 허용됩니다. 왜 이미 건조한 산업을 건조하고 유머러스하게 만들까요? 욕설이나 모욕 또는 악의를 허용하는 것은 완전히 다른 문제입니다. 내 경험은 당신과 완전히 다릅니다. 나는 재치있는 유머 감각을 나타내는 유익한 주석을 읽는 많은 시간을 chuck습니다. 그것은 내 하루를 더 좋게 만들었습니다. 유머 감각이 좋으려면 약간의 지능이 필요하지만, 성숙하게 할 수 있다면 그것을 가져 오십시오.

— JBeck

71

나는 재미있는 댓글 달기의 큰 팬입니다 .

당신은 항상 당신의 의견에 전문적이어야하지만, 어떤 유머는 독자를 죽이지 않을 것입니다.

특히 독자가 팀의 구성원 인 경우.

내가 가장 싫어하는 것은 자신을 너무 심각하게 생각하는 개발자입니다. 우리는 직장에서 즐거운 시간을 보내야한다고 생각합니다. 그렇지 않으면 일할 가치가 없습니다.

9

+1 "프로페셔널하지만 웃기는"

— deworde

프로그래밍 자체가 재미있다 :)

— Gopi

2

@Sri Kumar : 불행히도 항상 그런 것은 아닙니다. :(

— Bobby

1

@Bobby : 재미있게 결정하세요! 그들이 당신을 허락하지 않으면, 그것을받을 가치가있는 회사에 행복을 가져 오십시오.

3

너무 심각하게 생각하지 않아 +1

— JeffO

8

의미가 있다면 웃기는 것이 좋습니다. 재미있는 방식으로 댓글에 무언가를 설명하는 것이 좋습니다. 그것의 경우, 단지 뭔가 재미와 주석으로 실제 값을 포함하지 않는, 단지 성가신 이잖아. 의견이있는 이유는 유지 관리 효율성을 높이기위한 것입니다. 유머는 그와 충돌 할 필요는 없지만 적절하게 수행 할 수는 없습니다.

— 브라이언 녹 블라 우크
소스

중요한 프로그램의 오류 처리 코드에는 "Life 's a _ and then die"라는 주석이 있습니다. 설명의 끝에서. 재미 있고 말이됩니다.

— Michael K

1

@Michael-이것이 낭비라고 생각하는 완벽한 예입니다. 재미 있지 않고 (아주 오래되고 피곤한 진술을 반복하면서) 가치가 없습니다.

— Brian Knoblauch

8

코드는 여러 번 읽습니다.

백 번째로 말한 후 재밌는 농담을 얼마나 알고 있습니까?

@ Thorbjørn Ravn Andersen : 칸막이 벽에 인쇄하고 고정시키는 딜버트 만화는 어떻습니까? ;)

@Pierre, 소스 코드 주석을 입력하기에 적합한 단일 Dilbert를 찾으면 알려주십시오.

@ Thorbjørn Ravn Andersen : 딜버트가

@Pierre, 실제로 나는 그 포스터의 문구가 한계를 넘어 재미 있지 않다고 생각하지만, 그것은 또 다른 문제입니다. 당신은 얼마나 더 있습니까?

@ Thorbjørn Ravn Andersen : 그게 유일한 사람

7

재미있는 의견이 훌륭합니다.

지루한 코드에 긍정적 인 분위기를줍니다.
당신이 타이밍을 올바르게 얻는다면 그것은 정상적인 지루한 의견보다 훨씬 잘 설명합니다. 여기서 '타이밍'이란 주석 아래 코드와의 관련성을 의미합니다.
감정은 (인간) 기억에 더 나은 장소가 주어지기 때문에 많은 사람들이 코드를 기억할 것입니다. 오픈 소스 프로젝트에서 더 많은 사람들이 당신과 함께 일하기를 원한다면 이것은 좋은 방법입니다.
일반적으로 리뷰에 도움이됩니다. 코드를 훨씬 견딜 수있게 만듭니다. 물론 좋은 코드 작성에 집중해야합니다. 나는 그들이 작성한 코드에 자신감이 생겼을 때 재미있는 의견은 단지 부작용이라고 생각합니다.

이 사람처럼 웃기지 마라 .)

— 리노
소스

6

다음은 아침 2시에 쓴 글입니다 ( "DQ"는 회사의 이니셜입니다).

// Twas the night before go-live and all through DQ
// the devs were all crying and yes, this means you.
// Keys had been saved with both hyphens and 'scores
// which left this programmer with finger pad sores.
// The solution I crafted, you'll likely find lacking:
// to OR them together with judicuous hacking.

$hyphenated = str_replace('_','-',$data_type_key);
$underscored = str_replace('-','_',$data_type_key);
// (and then see line 46)

— 댄 레이
소스

3

예, 그러한 일은 오전 2시에 일어날 가능성이 가장 높지만, 이것이 좋은 농담은 아닙니다. 2 줄의 출처에 대한 의견을보고 싶다면 6 줄의 텍스트를 읽은 후에 누군가입니다. 200 줄의 코드를 설명하는 600 줄의 에세이를 읽어야 할 때와 같은 비율

— 누군가

5

아, 효율성은 창 밖이었다. 이 프로젝트는 이미 당신이 알고있는 클러스터였습니다. 약간의 부당은 2am 사기로 먼 길을갔습니다. 아시다시피, 제가 여기서 작성하는 코드는 다른 누군가의 허덕을 해결하는 것입니다. 이는 지난 2 주간의 죽음 행진과 거의 비슷했습니다. 나는 이런 종류의 일을 규칙적인 관행으로 용납하지 않지만, 나는 이것에 매우 만족했다고 고백합니다.

— Dan Ray

그 상황에서 나는 또한 매우 기뻐할 것입니다

— 누군가

줄 번호를 넣지 말고 <whatever> 자체는 주석 인 대신 "<whatever> 검색"을 사용하십시오.

— Vinko Vrsalovic 2016 년

3

고객 앞에서 소스 코드를 검토하고 있다면 당황 스럽습니까?

현재 답변 중 어느 것도 그것을 고려하지 않는 것 같습니다. 일부 고객은 유머 감각이 없으며 농담을 진지하게 받아들이지 않는다는 표시로 삼을 것입니다. 그들은 당신이 당신의 일에 부주의하다는 것을 유추 할 것입니다.

웃긴 코드 주석은 비전문적이고 부적절 할 수 있습니다.

— 더들리
소스

3

이미 말한 것 외에도 국제 팀에서 일하는 경우 일부 외국 문화 직원이나 영어가 모국어가 아닌 사람이 이해할 수없는 단어 놀이 때문에 해외 동료 중 일부가 농담을하지 않을 수 있습니다 . 오픈 소스 프로젝트에도 동일하게 적용됩니다.

— 바텍
소스

2

그것이 효율적이고 독자의 시간을 낭비하지 않으면 (읽거나 이해하는 데) 약간의 유머에 문제가 보이지 않습니다.

— jonners99
소스

2

현실 세계의 농담처럼 항상 재미 있고 생산적이지 않고 전문적이지 않습니다. 그러나 모든 농담에는 시간과 장소가 있으며 코드에는 시간과 장소가 있습니다. 실제 세계에서와 마찬가지로 농담을 언제 어디서 어떻게하는지 알고 있습니다.

— 제임스 베드포드
소스

1

나는 대학에서 과제를 할 때 거의 항상 재미있는 논평을하고 있었는데, 결코 사용되지 않을 것이며 숙제 일뿐이라는 것을 알았 기 때문에 거의 항상 재미있는 의견을 제시했습니다.

더 심각한 프로젝트의 경우, 나는 여전히 여기저기서 사용하지만 널리 보급되지는 않았으므로 이해하기가 성가 시거나 이해하기 어려워 주석의 목적을 무시합니다.

브라우저 비 호환성 및 이상한 결함을 피해야했던 약간의 웹 프로그래밍을 기억합니다. 때로는 분노와 분노로 가득 찬 의견으로 마무리되었습니다 .js.

내 기본 규칙은 다음과 같습니다. 코드 섹션의 기능이 어느 정도 명백한 경우 FUNNY COMMENTS ON!

코드가 너무 모호하고 " 인라인 클래스 " 와 같은 지옥처럼 난독 화되는 경우, 며칠 안에 이해할 수있는 주석을 사용하는 것이 좋습니다.

— 폴몬
소스