코딩 표준에 대한 프로젝트 리더와의 의견 불일치

그래서 지난 1 년 동안 프로젝트 리더와 함께 새로운 프로젝트를 진행하고 있습니다.

처음에는 별도의 자식 저장소에 상주하는 자체 하위 프로젝트가 있었고 코드와 거의 상호 작용하지 않았으므로 코드 냄새가 나를 귀찮게하지 않았습니다. 6 개월 후 나는 프로젝트에서 더 큰 역할을하면서 그의 코드에 기능을 유지하고 추가하기 시작했다.

이제 두 하위 프로젝트 (팀이 자라려고하고 있습니다. 그는 여전히 저 위에 있습니다)의 수석 개발자이므로 이러한 것들이 나를 귀찮게하고 돌보고 싶었지만 거부되었습니다.

1. ===를 사용하지 않고 중괄호, 대문자로 된 함수, 따옴표 사용 (숨겨진 논리가있는 이중 및 단일)없이 큰 함수가있는 거대한 클래스가 없습니다. 결론은 더 나을 수 있습니다.
2. 공지 / 경고를 끄는 PHP의 옵션에 의존합니다. 코드는 검사되지 않은 변수 및 배열 키 사용법으로 가득합니다. 변수는 ifs 안에 정의됩니다.

위의 두 가지 문제에 대한 주장 :

1. 사람들에게 코딩 스타일을 적용하고 싶지 않습니다.
2. 언어 기능으로 간주되어 더 짧고 효율적인 코드를 제공합니다.

나는 몇 가지 규칙이 필요하고 코드는 방어 적이어야한다고 생각합니다. 서식 지정에 PHPStorm의 기본 설정을 사용하고 중괄호와 커뮤니티에서 허용하는 이름 지정 규칙을 사용하도록 제안했습니다.

두 프로젝트를 분리 할 수없는 동일한 지침을 사용하도록 조정하고 싶습니다.

내가 틀렸어? 개인 취향을 강요합니까?

왜 당신이 더 나은지 (그리고 그를 사용하여 어떤 주요 문제가 생길 수 있는지)에 대한 강력한 사례를 만들 수 있다면 , 당신은 개인적인 취향을 부과하지 않고 대신에 성공을 위해 프로젝트를 설정하려고합니다.

그가 더 나은 이유와 더 나은 문제를 만들 수 있고 어떤 종류의 문제로 인해 당신이 할 수없는 것을 막을 수 있다면, 그는 당신을 뒤엎 게합니다.

괜찮은 경영진은 그 장점을 볼 수 있어야하지만, 개발자가 "모든 사람이 로봇처럼 일하도록 강요하고 싶지 않은지"(또는 말도 안되는 부분이지만 상위 경영진의 고통 지점으로 사용하지 마십시오). 그들은 프로젝트의 지속적인 안정성에 관심을 가져야한다.

위의 내 의견에 따라 :

그가 프로젝트 리더라면 그것은 기본적으로 그의 부름임을 암시하는 것 같습니다.

그건 내 생각이었다 표준을 변경하고 싶지만 표준을 따르지 않는 경우 a) 그를 극복하는 방법을 알아 내거나 b) 다른 곳으로 가거나 c) 자극하지 않고 할 수있는 작은 일을 시도하십시오. 너무 많은.

더 나은 표준이 필요한 이유에 대한 강력한 사례를 제시 하는 경우에만 그를 극복 할 수 있습니다.

원래:

• 당신은 하지 않습니다 처럼 자신의 코딩 스타일. 그게 네 권리 야
• 그는 그것을 발견 OK를 가하고 발견은 일 / 주 / 개 단지 스타일을 조정하는 것은입니다 지출처럼 시간의 낭비 . 그게 맞아

자신의 신발에 자신을 넣어. 회사에 많은 돈을들이는 것 (임금) 외에 노력의 이점은 무엇입니까? 그는 항상 너무 따끔한가요? 그는 지금해야 할 더 중요한 일이 보이지 않습니까?

기본적으로, 당신 은 당신과 함께 살 수있는 어떤 종류의 타협을 찾아야합니다. 또한 당신이 그와 의사 소통하는 방법에 많이 의존합니다. 마지막으로 당신이 그에게 것을 요구하고 있기 때문에 ... 옆으로 당신의 자아를 넣어 도움이 될하려고 당신은 그가 관심을 가지고 뭔가하지하고자합니다. 즉, 당신이 그에게 부탁을 요구하고있다 .

또한 종종 귀하의 요청 방법에 따라 다릅니다 . 예 :

당신이 원하는 것 :

코드를 더 예쁘게 만들기

하지 말아야 할 것 :

당신의 코드는 그대로

무슨 말을하는:

두 프로젝트를 일관성 있고 기본 사항으로 만들 수 있다면 정말 감사하겠습니다. 하루 만 걸립니다.

당신이 원하는 것 :

더 이상 점검하지 않은 경고

하지 말아야 할 것 :

당신의 코드는 그대로

무슨 말을하는:

나는 이것과 그 경고를 제거하는 빠른 방법을 알고 있습니다. 그런 다음 다시 활성화하면 나중에 무언가가 깨질 수 있는지 더 빨리 감지 할 수 있습니다.

그리고 마지막으로 :

나는 그것이 우선 순위가 아니라는 것을 안다. 우선 순위가 높은 물건이 먼저 나오면 기꺼이 할 수 있습니다.

또는 그 방법으로 문제가 해결되지 않거나 그와의 관계가 좋지 않으면 떠날 것을 고려하십시오. 지금 물건을 정리할 수 없다면 앞으로 나아질 것 같지 않고 자존심을 버릴 것 같지 않습니다.

사이드 노트

나는 노인들이 더 관대하게하는 것이 더 일반적이라고 생각합니다. 그들은 코드가 어쨌든 기술 변경, API, 팀, 비즈니스 파트너, 요구 사항, 글로벌 의사 결정 등 무엇이든 10 년 또는 2 년 안에 폐기 될 것임을 알고 있습니다 . 그들은 자아가 적고 완벽하기보다는 작동하는 데 집중합니다. 나는 나 자신을 완벽하게하는 경향이 있지만 그들을 탓할 수는 없습니다.

아마도 논란의 여지가 있지만 ...

우리는 이에 동의하고이를 상위 경영진에게 이관하기로 동의했습니다.

못. 이제까지. 하다. 이. 이제까지. 당신이 이것을 할 때마다, 그것은 우리 모두를 10 년으로 되돌립니다. 이것이 어떻게 작동하는지입니다.

• 선임 관리자 1 : "우리는 코딩 문제와 시간 낭비에 대한 문제인 blah, blah, blah와 관련하여이 문제를 처리하도록 요청 받았습니다."

• 선임 관리자 2 : "그리고 그들은 우리에게 괴상한 잔디 전쟁을 해결 하라고 요구 하고 있습니까?"

• 선임 관리자 3 : "고객이 의사 소통을 할 수없고 비즈니스 가치가 무엇인지 신경 쓰지 않거나 이해하지 못하는 아기를 좋아합니까?"

• 선임 관리자 2 : "그렇습니다. 골프는 누구입니까?"

그런 다음 당신과 당신의 상사의 성과 검토 시간이 온다 :

"[상사 상사] : 죄송합니다. 직접 보고서를 관리 할 수없고 모범 사례를 따르지 않을 우려가 있습니다. 소프트웨어를 작동하게 만듭니다) "

"[선임 관리자] : 죄송하지만 동료와 관련이없고 직속 상사의 지시에 따라 문제가 발생할 우려가 있습니다."

이것이 바로 우리가 만드는 가치에 비해 대부분 임금이 낮은 이유입니다. **

A) 그것을 극복하거나 B) 원하는대로 표준을 약간 조정 한 상점으로 이동해야합니다. FWIW, 나는 B를 할 것입니다 (그리고 그러한 잔혹성을 허용하지 않는 언어로 나아가기를 바랍니다). 그러나 불법적이거나 잠재적으로 치명적인 문제가 발생하지 않는 한 소송에 기술적 분쟁을 제기하지 마십시오. 단지 귀찮은 것은 그것을 삭감하지 않습니다 ***.

*이 글을 읽고 오해하는 사람들을 위해 OP와 그의 상사가 이와 같다는 말은 아닙니다 (코드 품질 / 가독성이 비즈니스의 수익에 직접적인 영향을 미친다는 것을 알고 있습니다) 비 기술적 관리에 의해 이와 같이 인식 될 것 입니다.

** 저의 고위 경영진이 실마리가 아니라고 생각하는 사람들에게는 비현실적입니다. 관리자는 사람들 이 코드 관리에 관심 이 있는 방식으로 사람들을 관리하는 데 (이상적으로) 관심이 있다는 것을 이해하십시오 . 그들은 기술적 인 문제에 대해 우둔하지 않을 수도 있지만 사람들을 알고 있기 때문에 A) 해결할 자격이 없을 수도 있고 B) 당신 둘 다 도움없이 해결할 수 있었어야 할 논쟁을 제기하는 이유가 더 많습니다. 당신이 나빠 보이게합니다.

*** 그렇습니다. 기술 부채는 사업 침체 시점까지 쌓일 수 있습니다. 난 그냥 중괄호 (존재가 말했다, 나는 당신을 절약 할 수 있다고 생각하지 않습니다 결코 중괄호를 생략하지 않고 강력하게 다른 사람이하지 중 하나 할 선호).

IMHO, 당신은 다음 작업을 걱정하지 않는 '작동하는'개발자에 직면하고 있습니다. 그의 주장은 쓸모가 없다.

그의 코드에 대해 말하는 것은 그의 게으른 게으름입니다. 동일한 코딩 표준을 따르는 프로젝트를 갖는 것은 엄격합니다. 당신은 로봇이 아닙니다. 당신은 엔지니어입니다. 당신은 엄격해야합니다.

당신은 그의 코드를 읽는 데 어려움을 겪고 있다는 몇 가지 예를 지적 할 수 있으며, 그것은 당신에게 큰 생산성 손실이지만, 나는 그것을 그에게 가져 오는 방법을 모른다.

그러나 나는 당신에게 뭔가 대답 할 것입니다.

작동 중입니다. 변경할 필요가 없습니다.

내 충고 : 만약 그가 정말 무뚝뚝하고 아무것도 가고 싶지 않다면 놓아주십시오. 그의 프로젝트에서 오류 / 버그 / 진화가 발생할 때까지 기다리십시오. 올 때, 수정 / 추가 된 코드 부분을 올바른 방식으로 수정하고 다시 작성하십시오. 그것에 대해 아무 말도하지 마십시오. 어쨌든 로봇이 아니기 때문에 그는 자신의 코딩 스타일을 강요하지 않을 것입니다.

프로젝트에서 작업 할 때는 우선 순위를 설정해야합니다.

우선 순위 # 1은 동료와 함께하는 것입니다. 우선 순위 # 1 다음에는 큰 차이가 있습니다. 그런 다음 작동하고, 테스트 가능하고, 테스트하고, 문서화하고, 유지 관리 할 수있는 코드와 같은 코드에 우선 순위를 두십시오. 그런 다음 또 다른 큰 차이가 생겨 코딩 표준이 따릅니다.

새로운 코딩 표준에 맞게 기존 코드를 변경하는 것은 우선 순위 목록에서 실제로 낮습니다.

추신. "마이크로 최적화"와 "초고속 컴퓨터": 완전히 잘못된 주장. 마이크로 최적화에 대한 인수는 컴퓨터가 빠른 것을 아니라, 인수 당신이 시간 이후에 진행이없는 마이크로 최적화 수단에 낭비하는 시간이 실제 절감.

추신. 코드가 더 좋아 보이도록 변경하는 데 하루가 걸리지 만 동료를 화나게하고 적을 만들면 하루 만 비생산적인 일에 낭비하게됩니다.

PHP는 우리 직업에서 가장 엘리트 그룹이 아닙니다. 실제로 당신은 그의 어려운 소프트웨어 시스템을 비판하고 있습니다. 당신의 전문 표준은 그의 표준보다 높습니다.

그런 다음 당신은 당신의 책임 아래 코드를 개선 할 여지가없는 경우,이 마지막으로 한 솔루션 : 에 이동 .

현재 PHP 시장에 대해서는 잘 모르지만 먼저 다변화 할 수 있습니다. 과대 광고 언어 나 C #과 같은 틈새를 배우십시오.

그렇게 좋은 직업을 얻지 못할 수도 있지만 전문적으로 더 나아갈 것입니다. 그러니 인내심을 가지고 자기 공부를하십시오. 안전한 돈. 그런 다음 프로젝트에 여유를 요청하거나 구직을하십시오.

# 1이 코딩 표준을 바꾸고 싶지 않은 진정한 이유라고 믿기가 어렵습니다. 코드베이스를 소유하고 있다면 귀하 (및 다른 개발자)가 동의 한 모든 코딩 표준을 시행 할 수 있어야합니다. 다른 개발자와 합의를 이룰 경우 (리더가 더 이상 개발 작업을 수행하지 않는다고 가정 할 경우) 다음을 제외하고는 진정으로 관심을 가질 이유가 없습니다.

코드베이스의 스타일을 수정하는 것이 현재 시간을 가장 잘 사용하고 있습니까?

결과물이 확실합니다. 다른 코드베이스 어디에서나 스타일을 개선하고 개선하는 데 시간이 얼마나 걸립니까? 스타일을 잘못 수정하여 버그를 도입하면 어떻게 되나요? 에서 삼촌 밥 :

물론 잘못된 코드를 정리할 수 있습니다. 그러나 그것은 매우 비싸다. 코드가 썩을 때, 모듈은 서로를 비껴 서 숨겨지고 얽힌 많은 의존성을 만듭니다. 오래된 의존성을 찾고 깨는 것은 길고 힘든 작업입니다.

이와 같은 코드 스타일을 개선 하는 것은 독립 실행 형 스프린트 항목 으로 시간 을 거의 사용하지 않습니다 . 내가 이런 종류의 개선을 좋아하는 방법은 내가 "좋은 이웃 정책"이라고 부르는 것입니다. 원하는 스타일과 논리 구조를 고치지 마십시오. 하지 마라. 대신 코드의 한 부분을 변경할 때마다 스타일을 수정하고 찾은 것보다 더 좋게 남겨 두십시오. 코드가 잘못 설계되어 기능을 구현하는 데 어려움을 겪고 있다면 스타일을 수정하여 머리를 치지 말고 자신을 차단하십시오.

이러한 방식으로 각 변경 사항은 다음과 같습니다.

1. 기술적 완벽주의 동기 부여 외에 비즈니스 동기 부여
2. 많은 시간 투자로 간주되지 않습니다 (그렇지 않기 때문에!)
3. 당신과 당신의 팀이 시간이 지남에 그것을하고 있기 때문에 좋은 스타일 습관을 정확하게 확립합니다
4. 한 번에 너무 많이 변경하지 않기 때문에 코드베이스에 큰 위험을 초래하지 않습니다.

몇 달 후, 당신은 "끔찍한 패키지"가 더 이상 나쁘지 않으며 상사가 그의 팀이 더 행복하다는 것을 알게 될 것입니다. 그러나 직접 대결이 아니기 때문에 이미 완료되었을 것이며, 할 일 목록에 큰 리팩토링 프로젝트를 추가하여 시간을 낭비하지 않았기 때문에 불만을 제기 할 것이 없습니다. 그는 당신에게 옳다고 말하지 않을 것입니다. 그러나 그것은 어쨌든 목표가 아닙니다 (오른쪽?).

리드에 대해 다음 질문을하십시오.

• 그들은 혼자 일하거나 아주 작은 팀과 일하는 데 익숙합니까?
• 그들은이 가게에서 주로 코딩을 했습니까?
• 그들은 결정을 내리는 데 익숙합니까?
• 그들은 "그냥 끝내는 데"익숙 했습니까?
• 그들은 대부분의 코드를 작성 했습니까?

대답이 "예"라면, 특정 유형의 리드 프로그래머의 그림을 그릴 것입니다. 그것이 당신이 경험 한 것과 일치한다면, 아마도 그들의 머리에 들어가는 데 도움이 될 것입니다. 그렇지 않은 경우이 답변을 무시하십시오 .

이것은 첫날부터 거기에 있었고 같은 코드베이스에서 일하는 동일한 직장에서 몇 년을 보냈고 길을 갔으며 다른 방법에 대한 경험이 많은 사람입니다.

그들은 코드를 작성할 때 다른 사람들을 고려하지 않습니다. 물론, 그들은 그것을 썼거나 그것을 이해하는 데 수년을 보냈습니다.

그들은 코딩 스타일을 유지 보수와 버그를 줄이는 도구가 아닌 개인적인 선호로 간주합니다. 코딩 스타일에 대해 논쟁 할 때 그들은 왜 자신의 방식대로 일하는지에 대해 전혀 생각하지 않았기 때문에 당신의 주장을 듣기가 어려울 것입니다. 그들이들을 수있는 것은 "나는 그것을하고 싶다"또는 "나는 새롭고, 화려하고 트렌디 한 방법을하고 싶다"입니다.

그들은 그들의 방식으로 설정됩니다. 그들은 모든 도구와 편집자, 그리고 두뇌를 정확히 그들의 스타일에 맞게 마이크로 구성하는 방식으로 오랫동안 같은 방식으로 해왔 기 때문입니다. 이 스타일에서 벗어나면 신중하게 정렬되었지만 매우 취하기 쉬운 작업 방식과 충돌합니다. 변경을 시도하면 편집자, 도구, 작업 방식 또는 "읽기 어렵다"에 대한 불만이 제기됩니다. 그들은 바꿀 수없는 현상으로 너무 꽉 싸서 변화를 거부합니다.

이것은 소프트웨어 엔지니어링과 소프트웨어 아키텍처를 제대로 배운 적이없는 사람입니다. 그들은 어떤 일이든 함께 뭉쳐 버립니다.

기술적 인 문제가 아니라 사람들의 문제가 있습니다.

당신은 당신의 리드를 재교육해야하거나 종료해야합니다.

관리에가는 것은 최후의 수단 입니다. 모두에 대한 이유 @JaredSmith 지적 밖으로 당신은 잃게됩니다 때문이다. 이 사람은 그들을 위해 돈을 버는 데 몇 년을 보냈습니다. 그는 그들의 회사를 썼다. 그는 수많은 화재에 시달리고 있습니다. 당신에게 그는 스파게티를 만드는 카우보이 요리사입니다. 그들에게 그는 회사를 설립하고 구한 영웅입니다.

재교육하려면 다음을 수행해야합니다.

• 그의 신뢰를 얻으십시오.
• 그가 어떻게 생각하는지 알아 내십시오.
• 변화에 대한 그의 두려움을 해결하십시오.
• 쉽게 변경하십시오.
• 이것이 어떻게 그에게 더 나은지 보여주십시오 .

그의 스타일을 진지하게 받아들이고 그의 머리 속으로 들어가십시오. 그것에 대해 물어보십시오. 왜 자신이하는 방식으로 일을합니까? 그가 읽을 때 무엇을 보았습니까? 도구와 어떻게 상호 작용합니까? 코드는 어떻게 이동합니까? 이 모든 것을 알면 그의 반대 의견을 이해하고 해결할 수 있습니다.

그의 주관적 이의 제기의 객관적인 뿌리를 찾아 실행 가능하게하십시오. "읽기가 어렵습니다"는 주관적이며 정보를 제공하지 않습니다. 당신은 그것에 대해 아무것도 할 수 없습니다. "색맹이며 구문 강조 기능이 작동하지 않습니다"는 객관적이고 정보를 제공하며 이에 대해 무언가를 할 수 있습니다. 자세한 내용 은 Get To Yes 라는 책을 추천 합니다.

루트 문제, 그가 겪고있는 실제 문제에 도달하면 문제를 해결하거나 완화 할 수 있는지 확인하십시오. 그런 다음 문제가되지 않습니다. 그들은 여전히 ​​변화에 감정적 인 문제가있을 것이지만 적어도 더 이상 실제 문제라고 주장 할 수는 없습니다.

한 번에 조금하십시오. 이것은 수년간 같은 방식으로해온 사람입니다. 그는 코드에서 특정 패턴을보고이를 이해하는 데 사용됩니다. 갑자기 모든 패턴을 변경하면 혼란 스러울 것입니다. 알려진 모범 사례를 통해 천천히 속도를내는 것이 실망 스럽기 때문에 그를 따라 가야합니다.

표준 커뮤니티 스타일을 옹호하십시오. 이것은 개인 취향에 관한 주장을 제거하고 왜 그들의 다른 스타일이 훨씬 더 나은지를 정당화하도록 압력을가합니다. 채용을 계획하고 있다면 신입 사원을보다 쉽게 ​​통합 할 수 있습니다.

자동화 된 코드 스타일을 옹호하십시오. 올바른 스타일을 따라 버튼을 누르십시오. 표준 스타일로 시작하여 취향에 맞게 구성하고 버튼을 눌러 코드를 다시 스타일링 할 수있는 도구를 사용하십시오. 가능한 한 쉽게 스타일을 따라가는 것은 따라 가기가 어려울 것이라는 많은 주장을 제거합니다. 그러나 원하는대로 코딩 할 수 있으며 완료되면 버튼을 누르면 다른 사람들이 읽을 수있는 스타일을 따릅니다.

이 사람은 다른 사람에 대해 생각할 생각이 없기 때문에 이러한 변화가 그들에게 어떻게 도움이되는지 보여 주어야합니다. "이것은 현재 표준이므로, 다음에 고용 한 사람과이 싸움을 다시 겪을 필요가 없습니다"만큼 간단 할 수 있습니다. 또는 "테스트가있는 경우 코드 변경에 대해보다 적극적이고 변경 사항에 대해 덜 걱정할 수 있습니다". 또는 "좋은 문서가있는 경우 사람들은 코드 작동 방식에 대한 질문으로 계속 귀찮게하지 않아도됩니다". 이것이 효과적이기 위해서는 그들이 원하는 것을 알아야합니다. 어떤 사람들은 귀찮게하고 싶어합니다.

길고 긴 길입니다. 상사 를 관리 하고 재교육 할 인내심이 있는지 여부를 결정해야합니다 . 좌절감을 느끼는 사람들보다 자신을 선생님이라고 생각하면 더 기분이 좋을 것입니다.

내가 틀렸어?

PHP를 모르기 때문에 직접 판단 할 수는 없지만 선호하는 코딩 스타일이 사용자가 직면 한 코드보다 "더 나은"것으로 주장 할 수 있습니다. 기존 자동화 도구

그렇다면 코딩 스타일의 개선을 제안하는 것은 잘못이 아닙니다.

작업하려는 코드가 아닌 결론

선호하는 표준에 맞지 않는 코드로 작업하는 것을 거부하는 것은 잘못된 일이지만, 회사에서 일함으로써 처음에 코드 작업에 동의 한 경우에만 가능합니다. 당신의 취향에 맞지 않는 요구를한다면 그것은 당신의 권리가 맞고, 결과적으로 더 나은 직업을 찾을 수있을 것입니다.

개인 취향을 강요합니까?

아뇨. 그는 프로젝트 리더이고 당신은 아닙니다. 이 경우에 그는 "위로 위임"되었지만 그의 부름이다.

그는 하위 프로젝트의 수석 개발자로서 당신에게 아래로 위임하기로 결정했을 수도 있으며, 미래에 그들과 함께 일하는 하위 프로젝트 및 동료를 위해 코딩 표준을 자유롭게 설정할 수 있습니다. 그러나 어떤 이유로 든 그는 당신이 표준화해서는 안된다는 느낌을 강하게 느낍니다. 그가 코딩 스타일에 대해 잘못하더라도 당신이 그가 허락하지 않은 권위를 요구할 수는 없습니다.

그러나 그는 "코딩 스타일을 적용하고 싶지 않다"고 말하기 때문에 최소한 원하는 스타일로 새 코드를 작성할 수 있습니다. 결과적으로 스타일의 객관적인 이점을 보여줄 기회가 생길 수 있습니다. 그것은 당신의 사건을 두 번째로 할 좋은 시간입니다.

파일을 편집하는 사람들에게 파일이 이미 작성되어있는 스타일로 요청하도록 합리적으로 요청할 수도 있습니다. 이를 통해 작성한 파일의 표준을 유지할 수 있습니다. 불행히도 이것의 반대 측면은 그가 작성한 파일을 자신의 스타일과 비슷한 것으로 편집해야한다는 것입니다.

실제로 테스트 스위트가 우수하고 상대적으로 안전하다고 리팩터링 할 수 있다고 가정하더라도 전체 파일을 폭파하고 다시 스타일을 지정하지 않아야하는 이유는 여전히 존재합니다. 주요한 것은 큰 구조적 변경 전후에 이루어진 변경 사항을 병합, 순서 변경 또는 되돌리려는 악몽이라는 것입니다. 그러나이 특정 프로젝트에서는 거의 일어나지 않을 수도 있습니다.

[제 관리자는 우리가 로봇이 아니기 때문에 사람들에게 코딩 스타일을 적용하는 것을 좋아하지 않는다고 말합니다.

우리가 소스 코드를 컴파일 한 후에 버리고 왜 모든 테스트를 통과했는지 궁금해 한 적이 있습니까? 소스 코드는 인간을위한 것이며, 인간이 쓰는 것뿐만 아니라 읽는 것이기도합니다 .

조만간 누군가 돌아가서 코드를 읽어야 할 이유가있을 것입니다. 어쩌면 그들은 그것을 바꾸고, 문서화하거나, 재사용해야 할 수도 있습니다. 도대체 무엇이. 일어날 일이며, 코드가 모두 일관된 스타일이면 훨씬 쉽게 읽고 사용할 수 있습니다.

나쁜 스타일조차 스타일이 전혀없는 것보다 낫습니다.