직장에서의 코딩 표준 처리 (나는 보스가 아니다)


40

저는 10 명 정도의 소규모 팀에서 일하고 있습니다. 우리는 코딩 표준이 전혀 없습니다. 표준이 된 것들이 있지만 어떤 일을하는 방법은 완전히 다릅니다. 내 큰 것은 들여 쓰기입니다. 일부는 탭을 사용하고 일부는 공백을 사용하고 일부는 다른 수의 공백을 사용하므로 큰 문제가 발생합니다. 누군가가 IDE를 사용하여 자동 형식을 지정하고 다른 문자를 사용하여 들여 쓰기 때문에 병합 할 때 종종 충돌이 발생합니다. 나는 우리가 어느 것을 사용하는지 상관하지 않으며, 우리 모두가 같은 것을 사용하기를 원합니다.

그렇지 않으면 파일을 열 것이고 일부 줄은 조건과 같은 줄에 중괄호가 있고 다른 줄은 다음 줄에 있습니다. 다시, 나는 그들이 모두 같은 한 마음에 들지 않습니다.

나는 직속 상사, 일대일 및 그룹 회의에서 표준 문제를 제기했으며, 그 표준에 대해 너무 걱정하지 않습니다 (나와 같은 견해를 공유하는 다른 사람들도 있습니다). 나는 들여 쓰기 문자에 대한 특정한 관심을 불러 일으켰고, "우리가 저장소에서 밀거나 당길 때 모든 것을 변환 할 수있는 일종의 스크립트를 만드는 것"이 ​​더 나은 해결책이라고 생각했다. 나는 그가 변경하고 싶지 않다고 생각 하고이 솔루션은 지나치게 복잡해 보이며 유지 관리 문제가 발생하기 쉽습니다 (또한 큰 문제의 한 가지 징후 만 나타냅니다).

직장에서 비슷한 상황에 처한 사람이 있습니까? 그렇다면 어떻게 처리 했습니까? 표준에 따라 상사를 판매하는 데 도움이되는 좋은 점은 무엇입니까? 관심있는 사람들 중 코딩 표준을 만들기 위해 풀뿌리 운동을 시작하는 것이 좋은 생각입니까? 너무 구체적입니까? 그냥 놓아 두어야합니까?

시간 내 주셔서 감사합니다.

참고 : 지금까지 훌륭한 의견을 보내 주셔서 감사합니다! 분명히, 나는 그들 모두를 지배하는 하나의 스타일을 지시하고 싶지 않습니다. 나는 모든 사람에게 가장 적합한 것을 선호하는 것을 선호하는 방식을 기꺼이 인정합니다. 나는 일관성을 원하고 이것이 민주주의가되기를 원합니다. 나는 그것이 모두가 동의하는 그룹 결정이되기를 원합니다. 사실, 모든 사람이 나아갈 수는 없지만 그룹의 발전을 위해 타협하기에 충분히 성숙하기를 바랍니다.

참고 2 : 위에서 언급 한 두 가지 예에서 일부 사람들이 따라 잡고 있습니다. 나는 그 문제의 핵심을 더 잘 따르고 있습니다. 명명 규칙, 해체해야 할 거대한 함수, 유틸리티 또는 서비스에 무언가가 있거나, 상수가 있거나 주입되거나, 다른 버전의 종속성을 사용하거나 동일한 경우, 이 경우 인터페이스를 사용하고, 단위 테스트를 설정하는 방법, 단위 테스트를 수행 할 대상, Java 또는 주석 또는 외부 구성을 사용해야하는 경우 (자바 관련) 계속할 수있었습니다.


3
일부 병합 도구는 공백 차이를 무시하는 옵션을 제공합니다. 근본 원인을 해결할 수는 없지만 중간 통증을 완화 할 수 있습니다 ...
FrustratedWithFormsDesigner

5
코드를 소스 제어로 푸시 할 때 코드 형식을 지정하는 관리자 솔루션이 마음에 들지 않는 이유
Larry Coleman

5
나는 이것이 기술적 문제가 아니라 사회적 문제라고 생각한다. 팀이 표준에 동의 할 수없는 경우 IMO가 도움을 줄 기술은 없습니다.
Bryan Oakley

11
모든 사람은 동일한 설정으로 IDE 자동 포맷을 사용해야합니다. 그냥 해.

1
@ Thorbjørn-합의. 어제 전역 IDE 설정을 발행했습니다.
Adrian J. Moreno

답변:


73

동료와 나는 우리가 처음 합류했을 때 비슷한 문제를 겪었습니다 (저는 먼저 팀에 합류했습니다. 그는 약 1 년 후에 합류했습니다). 실제 코드 표준은 없었습니다. 우리는 MS 상점이며 심지어 MS 코딩 표준도 사용되지 않았습니다. 우리는 모범으로 인도하기로 결정했습니다. 우리는 함께 앉아 IDE 표준, 명명 표준, 생각할 수있는 모든 표준을 모두 갖춘 문서를 작성했습니다. 그와 나는 표준을 명시 적으로 준수하기로 동의했습니다. 팀에 이메일을 보냈고 (우리 둘 다) 우리에게 부족함을 발견했으며 문서로 부족한 부분을 해결할 것이라고 알 렸습니다. 우리는 비평, 아이디어, 의견, 의견을 초대했습니다. 우리는 피드백 방식은 거의받지 않았으며 약간만 되돌려 받았습니다. 그와 나는 즉시 표준을 사용하기 시작했습니다. 주니어 개발자들을 프로젝트에 데려 오면서 표준을 소개하고 사용하기 시작했습니다. 우리는 처음에는 꺼려했지만 많은 것들을 위해 표준을 천천히 사용하기 시작한 몇 명의 단서를 가지고 있습니다.

우리는 많은 주니어 개발자들이 같은 문제를 인식했지만 다른 사람이 한 발짝 내딛고 결정을하기를 기다리고 있음을 발견했습니다. 따라야 할 계획이 있었을 때 많은 사람들이 그것을 채택하기를 열망했습니다. 까다로운 너트는 다른 방법으로 코딩을 거부하는 것이며, 일반적으로 장기적으로 그림에서 코드를 작성합니다.

표준을 원한다면 길을 타십시오. 팀에 도움이 될 것으로 생각되는 표준 목록을 제시하십시오. 피드백을 위해 동료 및 리드에게 제출하십시오. 나는 당신 팀의 다른 사람들이 비슷한 아이디어를 가지고 있다고 확신하지만, 그것에 대해 아무것도 할 생각이 없을 것입니다. 간디가 말했듯이 "당신은 세상에서보고 싶은 변화 여야합니다."


4
나는 동의하는 사람들 사이에서 시작한다는 아이디어를 좋아합니다! 표준을 쉽게 찾고 따르기 쉬울수록 사람들이 그렇게 할 가능성이 높아집니다. IDE 형식 도구가 있으면 설정 지침 및 구성 파일을 쉽게 찾을 수 있어야합니다. 설치가 잘 문서화되어 있습니다.
bethlakshmi

1
요컨대, 다른 사람들이 동일한 표준을 갖기를 기대하기 전에 자신을 표준으로 유지하십시오. 대부분의 팀 개발자들이 사용하고있는 것을 식별하여 시작하고 환경을 설정하십시오.
Freiheit

2
+1 정확히 같은 상황을 처리 한 방식입니다. 나는 모범으로 이끌어가는 것이 종종 개발 상점에서 많은 문제를 해결한다는 것을 알았습니다. 당신이 길을 타오르는 유일한 사람이라면 아마도 처음부터 길을 다시 평가해야 할 것입니다.
Jduv

1
Joel,이 이야기는 동료들과 나에게 영감을주었습니다. 여러분의 이야기를 템플릿으로 사용하여 횃불을 집어 들고 있습니다.
Josh Johnson

동의하는 사람으로 시작하는 것에 부분적으로 동의하지만, "우리는 함께 앉아서 문서를 작성했습니다"라는 의견에 동의하지 않습니다. resharper 또는 무료 대체 코드 메이드를 사용할 수 있으며 파일을 저장할 때마다 코드를 강제로 다시 포맷 할 수 있습니다. 어쨌든 알파벳별로 분류 방법, 유형별로 필드 그룹화 및 지역 사용과 같이 코딩 표준을 미친 수준으로 강제하는 회사에서 일하고 있습니다. 내 시간의 절반을 낭비하는 느낌이 들었습니다.
kirie

6

표준은 관리자가 정의하고 시행 한 것이어서는 안됩니다. 팀 전체가 표준에 동의해야합니다. 공통 표준 세트에 동의 할 수없는 경우 관리자가 표준을 강제하도록하는 것은 실패합니다.

귀하와 귀하에 동의하는 다른 사람들은 모범을 보여야합니다. 동일한 코딩 표준을 사용하여 시작하고이를 공개 한 후 다른 팀에게 홍보하고 개선 방법에 대한 피드백을 요청하십시오.

표준을 홍보하려고 할 때 중요한 부분은 다음과 같습니다. 초점은 일을하는 가장 좋은 방법을 찾는 것이 아니라 일을하는 일관된 방법 을 찾는 데 초점을 두어야 합니다. 어떤 사람들은 동의하지 않을 수 있지만, 진정한 괄호 스타일, 진정한 주석 스타일 등은 없습니다.


4
팀이 표준을 정의해야하지만 이상적으로는 관리자가 집행자 여야한다는 데 동의합니다. 코딩 표준을 가지고 있다는 전체 아이디어에 대해 관리자로부터 바이 인이 없다면, 그 리더쉽 역할을 직접 고려해야합니다 (Joel Etherton의 답변 참조).
semaj

3
그런데 기술적으로 거기에 있다 하나의 진정한 중괄호 스타일 : en.wikipedia.org/wiki/Indent_style#Variant:_1TBS
분석 재개 모니카

@ semaj : 전적으로 동의하지 않습니다. 관리자에게 전혀 영향을 미치지 않아야합니다. 조금도 아닙니다.
Bryan Oakley

반면에, 당신은 프로그래밍 팀, 누군가의 직원이며 히피 공동체가 아닙니다. 프로젝트가 실패하면 누구의 헤드 롤? 누군가의 일을 보장합니다. 모든 사람이 책임이 있다면, 아무도 책임 이 없습니다. 참조 , , , 등
크레이그

"누가 머리를 굴린다"는 뜻입니다. 분명히 ...
Craig

5

이로 인해 발생하는 문제로 인해 낭비 된 시간에 대한 증거를 보여줄 수 있습니까?

이러한 문제를 해결하는 데 상당한 시간을 소비하거나 버그를 수정하는 데 시간이 걸리는 경우 코딩 표준을 채택하여 비용을 크게 줄일 수 있습니다.

따라서 발생한 문제와 문제를 해결하는 데 걸리는 시간을 기록하십시오 (귀하와 동료가 알고있는 위치).

그런 다음 합리적인 양의 데이터가 있으면 동료에게 제공하십시오. 그들은 표준 채택의 이점을보아야합니다. 그렇지 않으면 상사와 상사에게 데이터를 표시하십시오. 코딩 표준을 갖추면 회사 비용을 절약 할 수 있으며이를 채택하는 데 도움이된다는 것을 보여주십시오.


3

귀하의 특정 상황에서 귀하의 상사의 해결책이 좋은 것이라고 생각합니다. 아무도 그들의 경력 전체를 위해하고있는 일을 바꿀 필요가 없으며, 컴파일러가 무시하는 코드 스타일은 코드를 읽을 수있는 한 중요하지 않기 때문에 괜찮습니다. 체크 아웃 할 때 모든 사람이 자신의 스타일로 자동 서식을 설정하고 체크인 할 때 표준 스타일로 자동 서식을 지정하면 문제가 없습니다. (슬프게도 나는 내가 일하는 곳에서 코더가 더 이상 연속 통합 서버가 보는 것과 동일한 정확한 코드를 작성하지 않을 것이라는 근거를 반대한다고 제안했습니다.)

코딩 품질이 코드 품질을 실제로 변화시키는 곳에 적용 할 때 코딩 표준이 좋다고 생각합니다. 예를 들어, 작은 방법, 명확하게 명시된 책임이있는 클래스, 더 어려운 비트에 대한 유용하고 정확한 주석 달기 등 자동 확인이 더 어렵지만 소프트웨어 개발의 기본입니다. 실제로 할 수있는 일은 다른 사람에게 모범 사례를 가르치고 잘못된 줄에 중괄호가있는 코드를 읽도록 가르치는 것입니다.


3
나는 어떤 줄 에든 중괄호로 괜찮습니다. 스타일이 모두 같은 파일에 있으면 버려집니다 . 스캔하기 어렵게 만듭니다.
조쉬 존슨

그것은 나를 미치게한다. 그러나 전체 코드베이스를 정확하게 다시 포맷 할 수 없기 때문에 자동화 된 솔루션을 제공 할 수있을 때까지 처리하려고합니다.
jprete

2

코딩 표준과 관련하여 : 코딩 표준이 "좋은 것"(표준이 아니라)이라고 말하면서 거의 모든 사람들과 함께 할 것입니다.

그러나 멀리 가지 마십시오. 나는 특정 들여 쓰기 스타일을 지시하는 일부 프로젝트에서 문자 수까지 (그리고 프로젝트가 멀리 갈 때 필연적으로 8 개의 공백 들여 쓰기와 같은 어리석은 것을 선택합니다) 작업했습니다. 작은 물건을 땀 흘리지 마십시오.

간단한 해결책 : 개발자에게 중괄호 및 들여 쓰기에 대한 제한된 선택 세트를 제공하지만 중괄호 스타일과 들여 쓰기는 모듈 전체에서 일관성을 유지해야합니다. (foo.h와 foo.cpp가 같은 스타일을 따르기를 원합니까?) 유지 관리자는 기존 스타일에 적응해야합니다. 기발한 스타일에 맞게 모듈을 다시 작성할 수 없습니다. 모듈 내의 여러 스타일은 혼란스럽고 구불 구불 한 신호입니다. 나는 그 말도 안될 때 무엇이 ​​잘못되었는지 궁금하게 만듭니다.

파일의 저장된 내용에서 들여 쓰기 위한 탭 금지를 고려할 수도 있습니다 . 대부분의 IDE / 편집기는 사용자 입력 탭을 공백으로 변환하는 합리적인 작업을 수행하며 대부분 자동으로 변환하는 옵션이 있습니다. 파일에 이미 탭, 특히 탭과 공백이 혼합 된 백이 포함 된 경우 많은 사람들이 엉터리 작업을합니다.

모든 말에서, 나는 당신이 당신의 프로젝트에서 더 깊은 문제를 가지고 있다고 생각합니다. 병합 문제를 언급했습니다. 많은 병합 작업이 필요한 경우 프로젝트의 파티셔닝이 잘못되었을 수 있습니다. 너무 많은 요리사가 국물을 망쳐 놓듯이, 같은 파일에서 작동하는 너무 많은 프로그래머가 프로젝트를 망칩니다. 왜 Joe, Susie, foo.cpp를 만지는가?


3
또는 탭을 사용할 수도 있고 개별 개발자가 원하는 크기로 만들 수도 있습니다.
Monica Monica

1
@ 브레 단 : m 경험으로는 작동하지 않습니다. 필연적으로 탭과 공백을 혼합 프로그래머는 줄을 자신의 코드를 얻기 위해 너무 , 특히 계속 줄을. 이 혼합 모드 공간과 탭 가비지는 개발자가 사용하는 것과 다른 탭 설정으로보기 흉하게 보일 수 있습니다.
David Hammen

2
나는 그것들을 섞으라고 말한 적이 없다. 탭만 사용하십시오. 그러나 들여 쓰기는 각 개발자가 원하는 것처럼 보입니다. "정확하게"정렬하기 위해 코드가 실제로 필요한 경우에도 들여 쓰기를 위해 탭을 사용하고 그 다음에 공백을 사용하여 정렬하십시오 (시간 낭비라고 생각합니다).
Monica Monica 복원

2
그 후이 아이디어를 죽이는 공간입니다. "소스 파일에 탭 없음"규칙은 많은 코딩 표준에서 일반적입니다. 그럴만한 이유가 있습니다.
David Hammen

1

이것은 일부 연구가 수행되는 영역 중 하나입니다. 기본적으로 주요 질문은 코드 검토를 수행하는지 여부입니다. 코드 검토는 의심 할 여지없이 코드 품질을 향상시키는 가장 효율적인 방법입니다. (출처 : CMU (Software Engineering Institute)). 추가 테스터보다 확실히 더 효율적입니다.

이제 코드 검토는 다른 사람들의 코드를 쉽게 읽을 수 있도록 공통 코딩 표준의 이점을 얻습니다. 이는 코딩 표준을 도입하기위한 2 단계 인수를 제공합니다. 결국 좋은 코드를 생산하는 것이 더 저렴합니다.


1

이미 당신과 함께있는 "여러 명의 다른 사람들"이 있기 때문에 즉흥 회의를 제안합니다. 모든 개발자를 초대하고 잠시 시간을내어 일상적으로 자신과 동료를 괴롭히는 것이 무엇인지 알아 내십시오 . 처음에는 특정 솔루션을 찾지 말고 현재 코드를 작성하는 방식에 어떤 변화가 필요한지 알아 보십시오 .

그런 다음 몇 가지 기본 개념에 모두 동의 할 수 있는지 확인하십시오. @David Hammen이 제기 한 각 모듈 내에서 동일한 스타일을 사용한다는 제안은 좋은 출발이며 대부분의 개발자가 쉽게 동의 할 수 있다고 생각합니다.

일단 다운 패터가 생기면 새로운 코드를 작성할 때 기본 스타일에 모두 동의 할 수 있다고 생각하면 좋은 추가 기능입니다. 실제로 유지 관리에 영향을 미치는 것들에 집중하십시오. 내 개인 목록에서 이름 지정 문제가 발생할 수 있습니다. 눈에 띄는 복잡성의 단일 제품에 6 가지 이름 지정 스타일이있는 경우 매우 빠르게 두통이 될 것입니다. 그러나 다시 귀하와 팀이 느끼는 것에 집중하십시오. . 모든 사람이 다른 애완 동물 스타일을 가지고 있더라도 적어도 따라하기로 동의 할 수있는 짧은 문서를 작성하여 팀의 모든 사람에게 우송하십시오. 이 문서를 "살아있는"문서로 만들고 시간을두고 업데이트해야하지만 너무 단단하고 구체적으로 작성해서는 안됩니다 .

상사가 코드 작성에 관여하지 않는 한, 어떤 정확한 스타일이 채택되는지 (가독성과 유지 관리성에 중점을 둔다면) 걱정하지 않아도되지만 공통 스타일을 따르는 팀의 모든 사람들의 이점을 볼 수 있어야합니다 코드를 작성할 때


1

고통스러운 것들이 있습니다. 가장 고통스러운 것은 IDE를 다른 방식으로 설정 한 개발자와 결합하여 코드를 자동으로 다시 포맷하는 IDE입니다. 코드를 비교할 때마다 다른 설정을 가진 사람이 코드를 편집 한 후 수백 개의 변경 사항이 있습니다. 용납 할 수 없습니다. 여기에서는 모든 사람의 머리를 서로 치고, 설정에 동의하고, 다른 설정을 사용하는 사람의 체크인을 거부해야합니다. 한 줄의 코드를 변경하면 diffs는 수백이 아닌 한 줄의 코드 만 변경되었음을 표시해야합니다.

다른 모든 것은 무해하거나 다른 사람들이 확신 할 수있는 일을하는 더 좋은 방법이 있습니다. 규칙은 다음과 같아야합니다. 실제로 개선하지 않는 한 다른 사람의 코드를 혼동하지 마십시오. 그리고 스타일 A와 스타일 B의 혼합은 항상 스타일 A 또는 스타일 B보다 나쁩니다.

모범 사례를 따르십시오. 언어마다 다릅니다. 그러나 표준은 필요하지 않지만 (잘 알려진 사람이 작성했을 수도 있지만 실제로는 알 수없는) 표준은 필요하지 않습니다.

권력 투쟁을 확실히 피하십시오. 팀의 모든 히틀러가 모든 사람을 그의 의지로 강요하려고하는 것보다 더 나쁜 것은 없습니다. 그리고 그것은 불행히도 코딩 표준을 작성하기 위해 자원 봉사 할 사람입니다 :-(


동일한 프로젝트에서 다른 개발자의 다른 표준으로 인해 탈모가 발생합니다. 프로젝트의 표준 설정을 작성하십시오. 모든 개발자가 해당 설정을 가져 오도록합니다. 기간. Visual Studio IDE와 같은 도구를 사용하면 쉽습니다. Emacs (나 자신이 끔찍한 것을 좋아함) 또는 그 밖의 것을 사용한다고 주장하는 개발자가 있다면 표준을 준수해야 할 책임이 있습니다. 체크인을 위해 코드를 다시 포맷하려면 예쁜 인쇄 루틴을 사용하십시오. 목표는 모든 사람의 개별 소스 코드 파일에있는 개별 예술적 스타일이 아니라 모든 사람이 이해하기 쉬운 균일 한 코드입니다.
Craig

0

당신이 제공 한 모든 예제는 기본적으로 공백과 형식에 관한 것입니다. 그것이 가장 큰 문제라면, 나는 당신의 관리자와 동의합니다. 그것은 큰 문제가 아닙니다.

표준이 실제로 매우 유용한 곳은 사물의 이름을 지정하고 복잡성을 줄이는 것입니다. 식별자, 클래스 이름, 배치 위치 등을 지정하는 방법. 특히 대규모 프로젝트에서는 이름을 일관성있게 유지하는 것이 매우 중요합니다. 복잡성을 줄이기위한 규칙에는 함수를 특정 줄 수 이하로 유지 (더 작은 함수로 나누기)하거나 매개 변수 목록을 특정 개수의 인수 아래로 유지하는 것 (객체로 묶고 전달해야 할 수도 있음)이 포함됩니다.

팀의 특정 개발자가 단일 문자 변수 이름을 가진 많은 긴 코드 조각을 포함하기 때문에 이해 / 디버그하기 어려운 코드를 작성하는 경우, 표준으로 채택 할 수있는 것이 아니라 일부 표준을 채택해야합니다. 스크립트. 그것은 표준이 개선 할 수있는 것으로 (전략적으로) 지적하는 것이 좋습니다.

관리자가 문제로 인식하지 못하는 또 다른 이유는 실제로 서로의 코드를 자주 읽지 않기 때문입니다. 모든 사람이 자신의 코드 영역을 가지고 있고 그 외부에서 너무 많이 모험하지 않을 때 발생할 수 있습니다. 누군가가 조직을 떠날 때까지 잘 작동합니다. 이는 여러 가지 좋은 이유와 나쁜 이유로 발생할 수 있습니다. 가독성에 도움이되는 표준을 사용하면 새로운 개발자가 코드를 유지 관리하기가 더 쉬워집니다.


0

누군가가 IDE를 사용하여 자동 형식을 지정하고 다른 문자를 사용하여 들여 쓰기 때문에 병합하면 충돌이 발생합니다.

이 문제는 포맷이 아니라 다시 포맷하는 문제입니다. 이것은 SCM에게 큰 문제이며 조언은 간단합니다.하지 마십시오. 따라서 다음에 누군가가 모든 공백을 탭으로 다시 포맷하거나 중괄호를 원하는 스타일로 리팩토링 할 때 줄을 내려야합니다. 대신 병합을 수행하십시오. 그들의 무의식이 초래 한 시간 낭비를 비 승인하는 것처럼 보임.

대안은 사전 커밋 포맷터를 넣는 것인데, 체크인 전에 항상 모든 코드를 표준 스타일로 다시 포맷합니다. 당연히 다시 포맷하는 개발자 팀이 있다면 이것이 좋은 옵션입니다 .SCM은 항상 같은 형식을 볼 것이므로 델타는 작고 병합하기 쉽습니다.


0

누군가 내가 일하는 새로운 코딩 표준을 제안하면 우리는 그것에 투표합니다. 과반수 표를 받으면 그렇지 않으면 거부됩니다. 이 작업을 수행하지 않으면 표준을 구매하지 않으며 문서화되어 있어도 사용되지 않습니다.


0

특정 문제로, 최선의 방법은 아마도 Joel의 제안으로 시작하여 모범을 보일 것입니다. 이것에 관심이있는 1 ~ 2 명의 프로그래머를 모으고 계약을 맺으면 게으른 사람들을 강제로 강요 할 것입니다.

이제 일반적인 문제의 경우 간단히 변조 하는 것이 가장 좋습니다 . 파일마다 유지 관리를 제공해야하는 경우 각 사용자는 서로 다른 파일을받습니다. 다른 파일과 다르더라도 해당 코딩 표준을 그대로 유지합니다. 같은 파일로 작성해야합니까? 서브 세트 파일을 작성하고 대신 포함하십시오.


0

이것을 시도하지 마십시오!

카운터 예제로 리드. 가능한 한 코드 형식을 끔찍하게 만들고 다른 사람들의 예쁜 코드에 대해 끔찍한 형식의 변경 사항을 확인하십시오. (피할 수없는) 반응이 발생하면 코딩 표준이 없기 때문에 현재하고있는 것이 좋다고 말합니다.

동료가 !! 치지 않으면 (!!) 코딩 표준이 생길 수 있습니다.

분명히 이것은 높은 위험 전략입니다 ... :-)


실제로, 지금이 사람을 시도하고 몇 사람이 있고 내가 시작하기 전에이 전략을 사용하는 많은 사람들이 있습니다. 최선의 노력에도 불구하고 지금까지 어떠한 표준도 나오지 않았습니다 :(
Josh Johnson

@ 조쉬 존슨-그들은 분명히 열심히 노력하지 않았습니다. 모든 식별자에서 ROT-13 사용을 고려하십시오 :-)
Stephen C
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.