소스 코드에서 비속어 다루기 [닫기]

사람들이 소스 코드와 VCS 주석에서 욕설을 다루는 방법. 유지 또는 삭제?

WTF 또는 Arrgggh와 같은 소프트 익스플로 티브는 어떻습니까?

비전문적이거나 모욕적이거나 으 rug해야 할 것이 있습니까?

부드럽게 낙담해야합니다

.. 일생 동안 소스 코드를 볼 수있는 사람을 알 수 없습니다.

특히 복잡하거나 오래된 코드로 인해 좌절감을 느끼고 소리를 내고 싶은 것은 모든 일이지만, expletives / rants / ASCII art / bad jokes / offensive remarks를 소스 코드에 넣는 것은 전문적이지 않으며 내 경험에 나쁜 생각. 때로는 의견을 작성하는 엔지니어가 자신의 의견이 미칠 수있는 최종 결과에 대해 잊어 버릴 수 있습니다. 여기 내가 본 몇 가지 문제가 있습니다.

• 공개 소스 / 샘플 코드로 공개 된 코드에 대한 많은 설명이 있습니다.
• 맛이 좋지 않은 농담은 일부 팀원에게 심오한 공격을 가해 산업 재판소로 이어집니다.
• 실제로 인종 차별 / 존재 / 성별 주의자라는 사람들이 해고 당할 수있는 타인의 말.

우리 모두는 좌절감 / 재미 / 재활용을위한 아울렛이 필요하지만, 소스 코드는 IMO를위한 장소가 아닙니다. 계약서, 도움말 페이지, 청사진 또는 기타 전문 문서에는 소스 코드보다 훨씬 적은 빈도로 읽을 수 있더라도 expletives / joke / offensive comment를 넣지 마십시오.

팀 리더가 모두 그것에 대해 굳게 다가 가면 화가 날 것입니다. 따라서 문제 엔지니어와 함께 조용한 단어를 사용하여 '조용히 낙담'했다고 말하고 페이스 북이든 인스턴트 메시징이든 증기를 피할 수있는 적절한 통풍 메커니즘을 제공했습니다. 에어 하키 또는 펀치 백.

주석은 자바 스크립트 나 다른 동적 클라이언트 측 코드는 어떻습니까?

다음은 제 의견을 형성 한 실제 경험 중 일부입니다.

• Microsoft에서 일하는 동안 한 소프트웨어 엔지니어가 "could n't"의 올바른 철자를 알지 못했음을 발견했습니다. 그는 o, l 및 d를 놓쳤으며 자신이 할 수 없었던 방법에 대한 긴 설명으로 그의 코드 대부분을 망쳤습니다. Y 사람이 문제 Z를 일으켰 기 때문에 X가 작동하게하십시오. 그의 코드는 훌륭했습니다. 그의 철자는 그다지 좋지 않았다. 말할 것도없이,이 코드의 후속 검토 자 (예 : 나)는 코드에서 많은 수의 무작위 맹세를 보라는 경고를 받았습니다. 이 코드 중 일부는 파트너 (드라이버 작성자)에게 보여졌습니다. 맹세를보고 그들의 공포를 상상해보십시오. 격언은 이상적으로는 프로젝트 관리자에게 구두 형태 (예 : 사람 Y가 토론에 참여할 수 있음)이거나 메시지를 보내지 만 소스가 아닌 커밋 된 것이어야합니다.

• 한 회사에서 외국어를 사용하는 개인이 주로 영어를 사용하는 팀에 합류했습니다. 그는 아무도 읽을 수 없다고 생각하면서 자신의 언어로 의견을 썼습니다. Babelfish / Google Translate가 자신의 언어에 대해 '영어로'옵션을 발표 할 때까지는 괜찮 았습니다.이 시점에서 팀의 나머지 부분은 몇 가지 의견을 번역했으며 회사가 회사에 대해 한 불결하고 종종 멸시하는 의견에 혐오감을 받았습니다. , 그의 팀과 여성 동료. 어색 합니다.

• 다른 회사에서는 한 사람이 실제로 ASCII 아트로 가져 와서 모든 종류의 아트를 소스 코드에 넣었으며 코드 검토 자에 의해 발견되지 않은 (또는 아마도 축복받은) 사람이었습니다. 얼마 후, 그는 어떤 이유로 보통 일종의 태그 라인으로 용에 살았습니다. 나중에 웨일스 어 사람이 팀에 합류했습니다. 웨일즈의 국가 상징은 빨간 용이므로, 새로운 남자는 처음에는 그림에 대해 기뻐했지만 어리석은 태그 라인 중 일부가 공격적인 것으로 해석 될 때 기분이 상했습니다. 예, 일부 팀장 조정이 필요했지만 이런 일은 일어나지 않았습니다.

무고한 사람들을 보호하기 위해 이름 / 사양이 제거되었습니다.

소스 코드를 판매하는 경우 (즉, 구성 요소 작성자 인 경우) 아마도 소스 코드가 없을 것입니다.

그것이 건전성의 문제라면 무엇이든, 그것은 당신에게 달려 있습니다.

누군가 WTF를 많이 쓰는 것을 본다면 아마도 그들이 겪고있는 문제에 대해 이야기해야한다는 신호일 수 있습니다.

누군가가 다른 사람 코드에 대한 공격을 지시하는 경우 해당 사람을 괴롭히는 것일 수 있으며 처리해야 할 상황이 완전히 다릅니다. 아마도 그들은 합법적 인 불만을 가지고 있고 제대로 발음하는 법을 모른다. 아마도 그들은 단지 바보 일뿐입니다.

개발자가 작성하는 것이 무엇이든간에 일종의 콘텐츠 필터를 갖는 것이 현명하지 않으며, 상황이 어떻게 진행되는지에 대해 많은 것을 알려줍니다.

저는 내부에서 개발 한 코드를 실행하는 µController가있는 소비자 제품을 설계, 제조 및 판매하는 Fortune 500 대 기업에서 근무하고 있습니다. 소송은 항상 부자가되기를 희망하는 소비자 또는 침해를 주장하는 경쟁자에 의해 가능합니다. 이로 인해 우리는 코드와 모든 의견을 적대적 배심원의 감시를받을 수 있다는 지식과 함께 작성합니다. 즉, 변수 및 함수 이름에는과 같은 단어가 포함되어서는 안됩니다 KILL_CHILD(int process_id). 이 예제 기능의 목적은 하위 프로세스를 종료하는 것이지만, 제품을 사용하는 동안 원고의 아동이 사망 한 경우 적대심의 배심원은 해당 기능 이름을 어떻게 볼 수 있습니까?

코드 내 주석이 더 나빠질 수 있습니다. 괜찮은 방어 팀이 자식 프로세스가 무엇인지 (앞의 예에서) 설명해야하는 이유를 설명 할 수는 있지만, 다음과 같은 주석으로부터 방어하는 것은 거의 불가능합니다.

// The following section of code is REALLY BAD!!!  I hope
//  it doesn't burn anybody's house down.

이와 같은 반대 의견은 실제 법원 사건에서 요인을 결정하고 있습니다.

관련 주제에서, 프로젝트의 이름은 또한 강력한 소송의 현미경 하에서 손상 될 수 있습니다. 기술 뉴스 소스가 "SATAN Unleashed On The Internet"을 보고 한 90 년대 중반 보수 그룹의 소란을 기억하십니까 ?

<rant_mode_off>

개인 프로젝트의 경우 코드에서 원하는 것을 자유롭게 할 수 있습니다.

그것이 당신을 귀찮게하고 당신이 머리 혼초라면, 나는 당신이 이것에 관한 규칙을 구현할 수없는 이유를 알지 못합니다. 이 가상의 상황에서 당신 은 모든 지도자를 따릅니다.

그러나 그것이 당신을 귀찮게하고 아무도 신경 쓰지 않는다면 아마도 그것을 빨아 들여야 할 것입니다.

가벼운 욕설을 자주 사용하기 때문에 물어볼만한 사람이 아닐 수도 있습니다.

나는 그것이 당신의 환경이 얼마나 PC (정치적)인지에 달려 있다고 생각합니다.

내가 양복과 넥타이 회사를 위해 코딩한다면 나는 욕설을 전혀 사용하지 않으려 고 노력하지만 취미 프로젝트 나 무언가를 위해 더 자유롭게 생각하는 경향이 있습니다.

미국과 다른 일부 국가에서는 사람들이 내가 살고 일하는 네덜란드보다 훨씬 더 많은 PC (또는 멈춤) 인 것 같습니다.

추가 보너스로, 여기에 몇 가지 통계가 코드의 욕설에 : http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-per-programming-language/

나는 그것이 매우 전문적이지 않을 수 있다는 것에 동의하는 경향이 있지만, 모든 사람들이 때때로 울고 다른 사람들에 대항하지 않도록 노력합니다. 즉, 코드베이스는 그룹의 전반적인 전문성을 반영하는 경향이 있으므로 설명이 포함 된 코드베이스는 전문가가 아닌 그룹을 반영 할 수 있으며 그룹에 "일부 광택을 적용"하기 위해 회의가 필요할 수 있습니다. 마찬가지로 코드에 특정 추세가 나타나면 그룹 내에서 해결해야 할 일반적인 문제를 나타내는 지표 일 수 있습니다 (예 : 작업중인 API에 개발자를 실망시키는 문제가 있음).

코드베이스 측면에서 일반적으로 작업에 안전하도록 해당 주석을 편집하고 그대로 둡니다. 작업중인 언어에 따라 클라이언트 또는 고객 앞에 나타날 수있는 내용을 절대 알 수 없으므로 항상 좋습니다.

이 전문가가 아니거나 공격적이거나 으 rug해야 하는가?

아마도 세 가지 모두 ... 당신의 관점에 따라.

특정 상황에서 사람들이 "다채로운 언어"를 사용하여 자신을 표현하는 것은 인간의 본성입니다. 어떤 문화에서는 다른 문화보다, 어떤 사람들은 다른 문화보다 더 그렇습니다. 그러나 경향은 보편적입니다.

내가 당신이라면, 당신이 당신의 직장 동료들에게 인기를 얻지 않는다면 그것을 으 it 할 것입니다.

그러나 소스 코드 / VCS 주석이 조직 외부에 게시 된 경우, 비즈니스가 고객에게 불쾌감을주는 것이 좋지 않다는 이유로 경영진은 더 강력한 선을 원할 수 있습니다.

욕설의 문제점 중 하나는 문화마다 다릅니다. 미국에서는 무고한 것들이 "삐져 나오는"경향이있는 반면, 다른 나라에서는 종종 의회 토론에서 같은 언어가 교환되는 것을들을 수 있습니다.

코드와 커밋 주석의 비속어는 "아무도 그것을 보지 않을 것"이라는 관점 때문에 매우 흔합니다. 대부분의 조직이 부활절 달걀을 불법화하는 것이 실제로 더 일반적이라고 생각합니다.

개인적으로 고객이 아닌 물건 (예 : 내부 커밋 자료)은 큰 문제가 아니라고 생각합니다.

그러나 대부분의 대규모 다국적 기업은 법무 부서와 "안전한 작업장"및 그와 같은 모든 것들에 의해 운영됩니다. 즉, 한 명 이상에게 불쾌감을 줄 수있는 것은 문제가되고 해고의 잠재적 원인이됩니다. 나는 그것을 인정하는 것을 싫어하지만 급여를 지불하는 사람들의 규제에 굴복하는 경향이 있습니다.

이 문제에 대한 빠른 해결책은 소스 제어 시스템에 욕설 필터를 설치하는 것입니다 (사전 제출 스크립트 또는 정기적 확인).

F 폭탄을 떨어 뜨리는 것처럼 통제 할 수없는 한 괜찮습니다. 나는 내가 작업하는 사람이 두 사람이 각각 나타내는 다양한 객체를 논의하는 스크립트를 작성하는 것을 보았습니다. 이 두 문자 중 30 줄이 서로주고받는 여러 줄 주석이있었습니다.

/ * igor : 내가 공개 대중을 만들 것인가? * Frankenstein : ah igor, 나는 당신의 가장 좋은 특성을 물려받습니다 ... * /

이런 식으로 오랫동안 계속되었습니다. 그는 위생 검사의 일부로 Frankenstein과 Igor라는 두 가지 물체를 만들었습니다. 실제로는 매우 창의적 이었지만 시간 낭비였습니다. 두 C # 객체 사이의 시나리오보다 WTF 나 Expletives를 보았을 것입니다 ...

회사 / 고객의 문화에 따라 다릅니다. 예를 들어, 성서 소프트웨어를 개발하고 있다면 어떤 형태의 표현도 환영받지 못합니다. 반면에 게임 개발자는 그다지 신경 쓰지 않을 수 있습니다 (또는 다른 극단으로갑니다).

코드 나 커밋에 대한 의견은 도움 이 될 것 입니다. 어떤 단어는 다른 단어보다 우리의 관심을 끌고 있습니다. 명백한 잘못이지만주의를 기울일 방법이없는 것에주의를 기울이는 것이 유용 할 수 있습니다.

즉, 나는 expletives를 사용하지 않지만 때때로 "Doh!"와 같은 것을 사용할 것입니다. 또는 "응?" 정신적으로 그렇게 다르지 않습니다. 그것이 당신을 귀찮게한다면, 범죄자와 이야기하십시오-그는 그것에 대해 생각하지 않을 수도 있습니다. 그들이 당신에게 하이킹을하라고 강하게 말하고 그것에 대해 강하게 느끼면 관리자에게 렁을 가십시오. 관리자로부터 지원을받지 못하면 관리자와 함께 살거나 다른 곳으로가는 법을 배워야합니다.

글쎄, 나는 당신이 다음과 같은 코드에 대해 무엇을 말해야하는지 정확하게 모르겠습니다.

tocommit = (n + (COMMITSIZE/PAGESIZE) - 1) & ~(COMMITSIZE/PAGESIZE - 1);

이 코드는 내가 최근에 최적화하려고 시도한 실제 매우 멍청한 코드베이스에서 가져 왔습니다. (코드는 오픈 소스이므로 여기에 어떤 고용주의 비밀도 밝히지 않습니다.)

다른 사람들이 말했듯이, 그것은 직장과 소스 코드를 볼 수있는 사람에 달려 있습니다.

소스 코드를 판매하는 경우 릴리스 된 버전의 두 번째 저장소가 있으며 각 새 버전이 제공하는 내용에 대한 설명 이외의 체크인 주석은 허용하지 않습니다. 내가 매일하는 일과 나의 모든 잘못은 내 고객이 아닌 나와 팀 사이에 있습니다.

현재 내 빌드 서버는 OMG, WTF, kludge, mess 및 TODO 주석을 남아있는 정리의 지표로보고합니다. 지금은 프로세스의 일부입니다.

오픈 소스 소프트웨어에 욕설이 보이고이를 제거하려면 푸시 백 가능성을 준비하십시오. 세 줄로 된 버그 보고서를 작성하지 말고 받아들이기를 기대하십시오. 욕설과 차별적 언어가 나쁜 이유를 설명하는 미니 에세이를 작성하고 반박을 선점하십시오.

개인 취향의 문제라고 생각합니다. 그 물건은 실제로 나를 귀찮게하지 않으므로 아마도 그것을 떠날 것입니다. 심지어 코드에서 문제 영역이 어디에 있는지 힌트를 줄 수도 있습니다.

그들은 당신 을 귀찮게 합니까? 당신 이이 질문을하고 있다는 사실에서 나는 그들이하는 것으로 추측합니다. 어떤 경우에, 그것들을 제거하거나 무엇이 잘못되었는지에 대한 적절한 주석으로 정리하십시오.