답변:
모든 사람에게 동일한 표준 코드 형식 지침을 100 % 준수하도록 요구하는 것은 모든 사람이 동일한 작문 스타일로 100 페이지 종이를 작성하는 것에 대해 별도로 공동 작업하도록 요구하는 것과 같습니다.
모두가 영어 (또는 같은 언어)로 논문을 쓰길 바랍니다. 그러나 다른 스타일이 분명하게 나타납니다. 어떤 사람들은 그것을 잘 쓸 것이고, 다른 사람들은 그렇지 않을 것입니다. 어떤 사람들은 수축을 사용하고 어떤 사람들은 단어를 완전히 철자 할 것입니다 (예 : 그것은 사실입니다). 기타.
나는 당신이 가장 중요한 점을 만졌다 고 생각합니다.
종이가 같은 글쓰기 스타일로되어있는 것처럼 코드가 같은 서식을 유지하려면 편집하고 수정해야합니다. 코드를 정리, 검토, 리팩터링해야합니다.
나는 다른 개발자의 코딩 스타일이나 형식에 완전히 만족하는 상점에 가본 적이 없습니다 (정확히 내 것과 같지 않기 때문에 최소한). 그러나 나는 그것을 읽고 이해할 수 있고 일관성이 있다면 만족할 것입니다. 다른 모든 것은 구문 설탕의 설탕입니다.
따라서 귀하의 질문에 대답하십시오 : 다소 중요하지만, 그렇지 않은 경우 세계의 끝이 아닙니다.
현재 업무에서 첫 번째 작업 중 하나는 개발 그룹의 코딩 표준을 마련하는 것이 었습니다.
첫 번째 노력은 약 60 페이지였습니다 (Microsoft의 프레임 워크 지침 중 상당 부분을 통합했습니다). 나는 그것을 파싱하라는 요청을 받았으며, 다음 번의 노력은 다양한 좋은 출처의 아이디어를 활용하여 10 페이지 길이였습니다. 나는 그것을 다시 깎아달라고 요청 받았으며 마침내 3-4 페이지로 떨어 졌다고 생각합니다.
결코 채택되지 않았습니다.
왜? 저는 현명한 코딩 표준을 본능적으로 따르는 많은 똑똑한 사람들과 함께 일하기 때문입니다.
필자는 Microsoft에서 일반적으로 받아 들여지는 지침을 따르고 일반적으로 사용되는 다른 스타일을 모방합니다 (Javascript 및 jQuery 는 모두 중괄호 언어이지만 C #과 다르게 형식 이 지정 됩니다). 또한 규칙을 수시로 위반하면 코드를 더 읽기 쉽게 만듭니다.
이 기본 사항을 수행하는 IDE를 사용하는 경우 (예 : Visual Studio) IDE에서 IDE를 수행하고 IDE에서 수행하도록 허용하는 한 여전히 수정하기 어려운 것으로 보이는 경우 또는 자동 서식을 설정하는 다음 사람은 어쨌든 그것을 죽일 것입니다.
한 사람이 가장 읽을 수있는 것은 모든 사람에게 해당되는 것은 아닙니다.
이런 종류의 IDE를 사용하지 않는다면 하나를 얻으십시오. 10 분 이상 이것에 대해 생각하더라도 자원 IMHO의 낭비입니다.
코드를 빠르게 이해하는 데 도움이되는 언급되지 않은 이점이 있다고 생각합니다. 코드 형식화가 프로젝트와 모든 개발자에 걸쳐 비슷할수록 코드를 더 쉽게 (그리고 무의식적으로) 작업 할 수 있습니다.
오랜 기간 동안 간단한 버그조차도 다루지 않은 후배 개발자들이 저를 찾아 왔습니다. 코드 형식을 적용하는 데 몇 분이 소요 된 후 이전에 놓친 버그를 신속하게 확인할 수있었습니다.
가독성은 확실히 중요하지만. 코드 형식 표준을 잘 이해하고 올바르게 사용하면 코드를 읽는 것 이상으로 코드를 더 빨리 이해할 수있을 것입니다.
코딩 형식을 개발하거나 업데이트 할 때 사용하는 지침 중 하나는 그룹화의 Gestalt 원칙입니다-http: //en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping
직접적인 결과 / 예제로서 우리 코드 포맷은 모든 블록 코드 (if, switch 등)가 다음 줄에 열린 괄호를 갖도록 요구하므로 닫는 괄호와 일치합니다 :
if(true)
{
}
Principle of Symmetry에 의해, 당신의 마음은 열린 괄호와 닫는 괄호를보고 더 빨리 코드 블록을 자연스럽게 인식 할 수 있습니다.
After taking a few minutes to apply our code format with them, they were quickly able to see the bug that they had missed before.코드 형식이 버그를 확인하는 데 도움이 되었기 때문이 아닙니다. 코드를 다시 포맷하는 작업으로 인해 이전에 훑어 본 코드를주의 깊게 살펴보아야했기 때문입니다.
어떤 언어 나 도구를 사용하든 무언가를 생각해 내십시오. IDE를 구성하고 구성 파일을 체크인하십시오.
누구나 프로젝트를 체크 아웃하면 동일한 서식 스타일을 사용합니다. 스타일이 무엇이든 중요하지 않으며 일관성 만 있습니다. 공백 v. 탭과 중괄호 중 어느 줄을 선호합니까? 그러나 내 자신의 취향보다 더 많은 것은 주어진 소스 코드 파일이 그 자체와 일치하는지 걱정합니다. 형식 전쟁으로 인한 혼잡보다 훨씬 더 읽기 쉽습니다.
내가 지금까지 만난 최악의 것은 코딩 표준을 사용하지 않는 것입니다. 그리고 diff 도구를 손상시키기 때문에 일부 코드 블록을 더 읽기 쉽게 만들 수 없습니다 ... 패치를 사용하여 변경 사항을 적용하고 있기 때문에 (변경 / 버그 수정 요청-> 수정 / 변경-> 패치-> "신뢰할 수있는"사람이 적용한 패치 -> commit) (가독성 관점에서) 꽤 재밌는 소스 코드를 얻을 수 있습니다. 적어도 우리는 두 개의 문자 변수를 사용하는 사람이 없습니다 (-.
가장 재미있는 것은 모든 사람이 우리가 이것을 바꿔야한다는 데 동의한다는 것입니다. 몇 번의 재 포맷 시도가 있었지만 (커밋시 자동), 하나의 작은 비트 형식 옵션이 누락 되었기 때문에 모든 것이 끝났습니다. 시력 ... [/ rant]
팀이해야하거나하지 말아야 할 것에 대한 보편적 인 표준은 없습니다. 일부 팀은 엄격한 지침을 따라야하지만 일부는 그렇지 않습니다.
요점은 팀으로 함께 일하고 팀에 가장 적합한 것을 결정 해야한다는 것 입니다. 코드는 쓰여진 것보다 여러 번 읽히기 때문에 쉽게 읽을 수 있어야합니다. 팀에서 읽을 수있는 코드를 작성하기위한 지침이 필요한 경우 코딩 표준을 준수하십시오. 당신이하지 않으면하지 마십시오.
그러나 대부분의 팀은 변수, 함수 및 클래스, 위치 괄호 등을 명명하는 표준 방법에 동의하면 도움이 될 것이라고 생각합니다. 팀이 그렇게 단순한 것에 동의 할 수 없다면 어떻게 모여서 정말로 중요한 결정을 내릴 수 있을까요? 또한 팀은 영원히 같은 사람들로 구성되지 않습니다. 사람들은 떠나고 새로운 사람들은 고용됩니다. 신입 사원이 코드베이스를 이해하기 쉬울수록 코드 품질을 저하시키지 않고 팀에 더 빨리 기여할 수 있습니다.