나는 우리의 코딩 표준 중 하나를 싫어하고 그것을 어떻게 처리해야합니까? [닫은]

면책 조항 : 제목이 제시하는 것처럼 과장된 것은 아니지만 여전히 불편합니다. 나는 정직하게 표현할 것이므로, 소금 한 알로 가져 가십시오. 내가 당신이 일하고 싶지 않은 코딩 표준 에 대해 이야기하고 있다고 가정하십시오.

편집 : 내가 그것을 좋아하지 않는다는 사실이 그것을 사용하거나 시행하지 않는다는 것을 의미하지는 않습니다.

나는 당신이 좋아하지 않는 표준을 극복하는 방법의 정신 으로이 질문을하기로 결정했습니다.이 표준은 어떻게 변경 될 수 있는지 더 잘 논쟁하는 방법에 대한 도움을 얻지 못했습니다 (이 마지막 부분에 대한 의견은 높이 평가되지만). 게다가, 나는 대기업에서 일하고 있으며 오래 살았고 그다지 중요하지 않은 무언가의 변화는 거의 없습니다.

표준은 개통 중괄호 전용 표준입니다.

somefunction()
{
    //...
}

* 명백하게 뛰어난 * 대신 (농담 / 절망적 인 음색에주의) :

somefunction() {
    //...
}

표준에 대한 나의 개인적인 주장 :

• 코드가 부풀어 오른다 : 여분의 불필요한 줄
• 세게 입력합니다 : 아마이 있지만 날이 표준으로 어려움을 겪고, 나는 하나의 여분의 키가 나쁘지 않다 알고있다.
• 읽기 쉽지 않음 : 함수 선언, if 문 또는 다른 범위 스태킹 문 을 읽기 시작하고 이미 여는 중괄호를 찾을 필요가 없습니다. 이 표준의 중첩 블록은 어떤 이유로 든 나를 화나게합니다.
• Microsoft IDE 배경을 가진 사람들이 사용합니다 . 패러다임에 의한 것이 아니라 표준 뒤에 논란의 여지가 있어야한다고 생각합니다.

그들의 주장 (그리고 그들에게 내부적으로 반론하는 방법) :

• 블록이 어디서 시작하고 끝나는 지 알 수 있기 때문에 더 쉽게 읽을 수 있습니다 : 나는 이것을 이해할 수 없습니다. 블록이 소유하고있는 것을 모르면 블록이 무엇인지 잘 알고 있으므로 뒤로 읽으십시오.
• 나는 그것을 Microsoft IDE에서 사용했고 그것을 좋아했다 .
• 그것은 표준에 있습니다 : * cringes *

나는 특정 표준에 반대하는 의견에 반대하는 유일한 사람입니까?, 어떻게 극복 했습니까?,이 특정 표준이 무엇인지에 대한 당신의 의견은 무엇입니까?

이 문제를 해결하려면 Torvalds의 인용문이 있습니다.

나쁜 프로그래머는 코드에 대해 걱정합니다. 훌륭한 프로그래머는 데이터 구조와 관계에 대해 걱정합니다.

이제 코드 표준에 의해 시행되는 브레이싱 스타일과 같은 사소한 것에 대해 걱정하는 프로그래머는 어디에 배치해야합니까? 그렇지 않으면 코드베이스가 너무 깨끗하여 브레이싱이 논쟁의 여지가있는 유일한 문제입니까?

어떤 사람들은 당신의 방식을 좋아하고 다른 사람들은 그렇지 않습니다. 어느 쪽이든 누군가는 화가 날 것입니다. 이번엔 네 차례 야 빨고 일을 시작하십시오.

팀의 표준이 문서화되어 있습니까? 그렇다면 스타일 가이드에 어떤 이유가 있습니까? 솔직히 말해서, 나는 그것을 엄청나게 빨고 실제 작업을 완료해야했습니다. 더 나쁜 문제가 있지만, 나는 당신을 느낍니다. 그것은 여전히 ​​순위가 높습니다 (그런데 스타일에 대해 당신에게 동의합니다).

내가 통과하는 데 도움이 된 것 :

1. 어떤 스타일이든 단일 스타일에 실질적인 이점이 있음을 인식 아니면 적어도 많은 사람들이 그렇게 생각 합니다.
2. 정확히 방금 한 일을 왜 잘못 생각했는지 적어두면 나중에 논증을 잘 넣을 수 있습니다.
3. 신을 위해 스타일링 도구를 사용하면 정신을 절약 할 수 있습니다. ReSharper에서 , CodeMaid , StyleCop , JSLint , CheckStyle , 등 , 심지어 비주얼 스튜디오는 ... 당신을 위해 그것을 할 것입니다 .
4. 이 프로젝트를 시작하고 표준을 설정할 수있을 때 다음에 대비하십시오.

하나의 규칙이 다른 규칙보다 우월하다는 것은 명백하게 임의적 이다.

당신이 직면 한 가독성 문제 또는 팀원들이 표준에 직면하게되는 것은 변화에 대한 심리적 저항 일뿐입니다.

객관적인 가독성 인수는 전체 코드 기반에 대해 * 일관성 * 을 선호 합니다.

당신이 무언가에 대해 옳았다 는 확신 이 들었고, 시간이 지남에 따라 당신이 틀렸다는 것을 깨달았거나, 적어도 몇 년 전 과도하게 반응했다는 사실을 다시 생각해보십시오 . 다시 틀렸을 가능성을 고려하고 새로운 코딩 표준 또는 프로세스 시간을 제공하여 확신을 얻으십시오.

내가 코딩에 상당히 새로운이었다 내 자신의 기준 분노는 단어로 된 식별자 수 있는지 여부였다 (내 경력에 오년 말) WrittenLikeThis나 written_like_this. 나는 내가 어느 쪽을 말했는지조차 말하지 않을 것이지만 요점은 얼마 후에 측면을 바꾸었고 더 오랜 시간을 보낸 후에는 어느 쪽도 신경 쓰지 않았다는 것입니다.

중괄호로 설명하는 표준 차이는 거의 임의적입니다. 모든 사람이 똑같이하는 한 두 방법은 모두 똑같이 좋은 방법입니다.

당신이 말하는 "명백히 우월한"은 사람들이 "이전에 익숙한"것에 대해 말할 때 말하는 우월한 것입니다.

머지 않아 1 년 정도면 익숙해 질 것입니다. 다른 방법은 "분명히 우월합니다".

간단히 말해서 : 그것을 다루십시오.

이 특정한 주제는 한 스타일을 다른 스타일보다 선호하는 사람들 사이의 종교 전쟁에 해당합니다. 모호한 사람들은 거의 없습니다 ...

궁극적으로 옳고 그른 것도 아닙니다.

스타일 가이드 및 코딩 표준은 여러 가지 이유로 존재합니다. 한 가지 중요한 측면은 레이아웃의 균일 성을 보장하여 명백한 오류 수를 줄이고 유지 관리 성을 향상시키는 것입니다.

나는 특정 표준에 반대하는 의견에 반대하는 유일한 사람입니까?

짧은 대답은 "아니오"입니다. 당신은 유일한 사람이 아닙니다. 그러나 걱정해야 할 더 중요한 것들이 있습니다. 누군가가 입력 한 표준에서도 항상 타협이있을 것입니다. 나에게 이해가되지 않는 C99 및 C12 로의 일부 측면을 목격하십시오.

MISRA-C (내가 직접 영향력을 가짐)조차도 개인적으로 동의하지 않는 항목이 포함되어 있지만 다른 사람들이 정당화되는 이유를 이해할 수 있습니다.

이것들을 어떻게 극복 했습니까?

그리고 그 안에 답이 있습니다. 왜 개인적으로 그것을 좋아하지 않는지에 초점을 맞추기보다는 그에 동의 한 사람 / 사람들이 왜 그렇게했는지 이해하고 시도하십시오.

규칙은 일반적으로 이전 문제를 해결하기 위해 (말이 볼트로 고정 된 후 닫히는 안정적인 문에) 도입됩니다. 규칙이 여전히 무의미한 경우 표준 소유자와 대화하고 "교육"하십시오.

난 그냥 당신이 그것에 착수해야한다고 생각합니다. 본인의 의견으로 귀하의 메모를 해결하려고 노력할 것입니다.

• 블로 트 코드

  단일 클래스에서 100의 메소드를 작성하지 않는 한 수백 개의 추가 라인이 추가되지 않는 한 한 줄의 추가 코드가 전혀 코드를 부 풀리지 않습니다. 그런 다음 단일 클래스에 수백 개의 메소드가 있으면 또 다른 문제점이 있습니다.

• 타이핑하기 어렵다

  이에 대해 더 이상 동의하지 않습니다. 어쨌든 다음 줄로 가려면 리턴 키를 눌러야합니다. 입력하기가 더 어떻습니까?

• 읽기 어렵다

  코드 조각의 각 줄에 특정 기능이 있어야한다고 생각합니다. 그런 다음 메소드 이름을 한 줄로 정의한 다음 열기 및 닫기 괄호를 별도의 줄로 정의해야합니다.

• MS IDE 배경을 가진 사람들이 사용

  어 ..... 좋아?

요약하면 다른 표준 개발자와 달리 .Net 개발자 가이 표준을 기본으로하는 IDE를 사용했기 때문에 열등한 것처럼.

나는 특정 표준에 반대하는 의견에 반대하는 유일한 사람입니까?

당연히 아니지. 코딩 표준을 결정하기위한 회의는 끔찍합니다! 그들은 몇 시간 동안 끌려 가고 참가자들은 표준에 명시된 자신의 마음에 드는 (내를 제외하고는 항상 틀린) 특질을 얻는 데 개인적으로 투자하게됩니다. 결국 아무도 결과에 만족하지 않습니다. 코딩 표준 회의보다 더 나쁜 것이 있으면 몇 개월 동안 표준 결정을 따르는 공식 코드 검토 회의입니다. 일부 사람들은 표준을 채택하려고 시도하지만 다른 사람들은 의도적으로 표준을 무시하려고합니다. 피드백 시간 같은 라인 132, 142, 145, 181, 195, 및 부호화 표준이 명확하게 온되어야한다고 말할 때 SillyFileConverter.cpp (221)는 동일한 라인의 개구 걸림쇠를 넣어 다음 라인!

이것들을 어떻게 극복 했습니까?

각자의 방식으로 회의가 도움이됩니다. 조건부와 같은 줄에 오프닝 버팀대를 남긴 사람과 전적으로 동조하더라도, 당신은 단지 그것을 빨아 들이고 바보 같은 표준을 따름으로써 시간을 낭비하여 화가 날 것입니다. 그 남자가 curmudgeon이고 같은 일을 반복해서 반복한다면 훨씬 더 성가신 것입니다. 그 행동에 짜증이 나면 선호하는 것과 조금 다른 스타일로 글쓰기를 정당화하는 것이 훨씬 쉬워집니다 . 결국 그 사람 이되고 싶지는 않습니다 .

이해하기 쉬운 공식 코드 검토를받지 않더라도 표준 준수를 위해 고유 코드를 검토 할 수 있습니다. 표준에 대한 생각은 중요하지 않으며, 작성한 내용과 표준의 내용을 비교하는 것입니다. 준수하지 않을 때마다 스스로 욕을하면 표준을 채택하는 데 도움이되는 부정적인 피드백이있을 수 있습니다.

이런 종류의 것들로 나는 Lilliput의 Gulliver를 기억합니다. Lilliputians는 삶은 달걀을 열기 위해 전쟁을 벌이고 있었다. (원래 빅 엔디안, 리틀 엔디안 싸움).

스스로를 비웃을 수있는 기회로 삼으십시오. 그들은 종종 사업에 충분하지 않습니다.

귀하의 특정 예는 일부는 동의하고 일부는 동의하지 않으므로 불행합니다. 예를 들어, 당신의 주장에 동의하지 않으며, 다른 사람들도 동의 할 것입니다. 거의 주관적이므로 질문을 닫아야한다고 생각합니다.

그러나 당신이 동의하지 않는 표준을 다루는 방법에 대한 질문은 더 답할 수 있습니다. 나는 스타일링 가이드 라인이 존재하고 동의되고 사용 된 곳에서 그 대답은 단지 웃기만하고, 그것을 견디고 다루는 것이라고 생각합니다. 일관성을 갖는 것이 더 중요하다는 것을 고려하십시오. 가이드 라인이 부정확하거나 잘못된 경우, 변경에 대한 논거가있을 수 있지만 이것은 문체 적이므로 개인적 취향과는 별개의 논거가 없습니다.

나는 원래 Java 배경에서 왔으므로 언급 한 표준을 따랐습니다. 그런 다음 싫어하는 스타일이 사용되는 더 많은 C ++ 및 C #으로 옮겼습니다. 그러나 옳고 그른 대답은 없습니다. 더 중요한 것은 표준과 그 뒤에 모든 사람이 따르는 것입니다. 코딩 표준이 이와 같이 문체 적이며 명확하지 않은 경우에는 팀에 마찰을 일으킬뿐입니다.

포맷터 + 체크인 후크가 좋은 시작입니다. 그러나 글을 쓰는 것이 하루 종일 응시하는 것만 큼 중요하지 않기 때문에 충분하지 않습니다. 어떤 상황에서는 파일을 스타일로 유지하지만 스타일에 더 가깝게 표시 하는 Emacs의 안경 모드 의 접근 방식 이 매력적입니다.

그것으로 나의 경험 - 그것은, 작성된 정확히 문제에 직면 CamelCaps대는 underscore_separated- 그것은 신속하게 도움보다 더 짜증나되었지만, 몇 주 동안은 회사의 스타일을 받아들이는 (마지 못해) 내 전환을 부드럽게뿐만 아니라 출구를 제공하는 것이 었습니다 내 분노를 채널하기 위해 ( "아, 나는 그것을 싫어, 다시 설정을 조정하자 ... 적어도, 내가 뭔가를했다 ") ;-)

어쨌든, Glasses 모드는 중괄호 배치를 처리하지 않으므로 Emacs를 사용하지 않으며 편집기에서 독점적으로 코드를 읽지 마십시오 .- (
그러나 마지막 요점은 기회입니다- 대부분의 시간에 코드 를 읽는 경우 별도의 도구를 사용하면 왕복 재 포맷 노이즈에 대해 걱정하지 않고 스타일을 변환하기 위해 해킹 할 수 있습니다. 읽기 전용이기 때문입니다. 특히 일부 웹 인터페이스에서 코드를 읽는 경우 Greasemonkey를 사용하십시오.

다음은 가벼운 완화를위한 더 쉬운 아이디어입니다.

• 잃어버린 화면 줄을 되찾기 위해 더 넓지 만 높지 않은 글꼴을 선택하십시오.

  • 가능한 경우 전체 화면을 더 자주 사용하십시오.

• 미묘한 색상 (및 작은 글꼴)으로 강조 표시되도록 중괄호를 설정하여 나머지 코드보다 잘 보이지 않게합니다. 들여 쓰기는 읽기에 충분해야합니다. {줄 에서 빈 공간으로 ...

• 끝났을 때 편집기가 여는 중괄호와 일치하는지 확인하십시오. }눈이 본능적으로 잘못된 곳으로 갈 때 약간 도움이 될 수 있습니다.

• "보다 세게 입력하기": 실제 편집기를 가져 와서를 누르면 새 줄을 자동으로 열도록 구성하십시오 {.

함께 살아라.

이것은 분명히 화장품이며 코드의 품질이나 개발자의 생산성과 관련하여 아무런 변화가 없습니다. 논쟁을 시작할만한 가치가 없습니다.

그런 종류의 코딩 표준을 위해, 나는 코드베이스에 대한 일관성과 특정 (합리적으로 합리적인) "종교적인"접근 방식에 대한 가독성을 매일 선택합니다.

중요하지 않은 문제에 대해 대다수 팀원의 민주적 인 결정으로 생각하면 극복하는 데 도움이 될 수 있습니다.

표준입니다.

http://doh-san.blogspot.com/2005/10/five-monkeys.html

"표준"이라고 말하는 대부분의 사람들은 "5 마리 원숭이"원칙을 따르고 있습니다.

계속해서 원하는 스타일을 사용하십시오. 그런 다음 일부 코드 beautifier 를 사용하여 표준 형식으로 코드를 변경하거나 자신의 작은 응용 프로그램에서 스타일을 지정된 표준 스타일로 변환하십시오. 코드를 체크인하기 전에 미화기를 사용하십시오.
체크인 한 코드를 표준 형식에서 작업중인 형식으로 변경하기 위해 반대로 할 수도 있습니다.