최근 에 GitHub 에서 여러 오픈 소스 Ruby (또는 대부분 Ruby) 프로젝트를 발견했으며 Rubocop 와 같은 코드 분석 도구로 검사 할 때 많은 위반이 발생 합니다.

이제, 이러한 위법 행위의 대부분은 레벨 규칙 당 2 개의 공백을 따르지 않거나 80 자 라인 길이 규칙을 초과하거나 멀티 라인 블록을 사용 {하고 사용 }하기 위해 작은 따옴표 대신 큰 따옴표를 사용합니다 (보간하지 않을 때) .

[The] Ruby 스타일 가이드는 실제 Ruby 프로그래머가 다른 실제 Ruby 프로그래머가 유지할 수있는 코드를 작성할 수 있도록 모범 사례를 권장합니다. ~ 출처 : 루비 스타일 가이드

비록 작고 수정하기 쉽지만, 위반을 수정하고 풀 요청을 작성하여 오픈 소스 프로젝트의 코딩 스타일을 변경하는 것이 적절합니까? 나는 레일과 같은 몇 가지 프로젝트, 인정 화장품 변경 사항을 적용하지 않는 예는 Rubocop가 실행될 때 이상 80,000 범죄를 생성하기위한 일부 (레일 번에 모든 "수정"에 너무 큰 -에 관계없이, 그들은 자신의 작은 세트가 코딩을 기여할 때 따라야 할 규칙 ). 결국 루비 스타일 가이드 는 Rubocop와 같은 도구와 함께 이유가 있습니다.

사람들 은 일관성을 높이 평가 하므로 이런 종류의 변경을하는 것이 루비 커뮤니티에 일반적으로 좋은 일입니다.

[루비 스타일 가이드 (Ruby Style Guide)의 저자]는 모든 규칙을 찾지 못했습니다. 주로 루비 커뮤니티 회원들의 피드백과 제안 및 전문 소프트웨어 엔지니어로서의 광범위한 경력을 바탕으로합니다. "Programming Ruby 1.9"및 "The Ruby Programming Language"와 같은 Ruby 프로그래밍 리소스 ~ 출처 : 루비 스타일 가이드

커뮤니티 코딩 스타일 규칙과 모범 사례를 따르지 않는 것이 기본적으로 나쁜 관행을 권장 하지 않습니까?

관리자에게 문의하십시오.

코딩 스타일은 매우 주관적인 토론이며 최대 80 자 길이의 규칙과 같은 규칙은 상당히 주관적이지만 일반적으로 짧은 줄을 읽는 것이 더 좋으며, 80은 오늘날의 화면 크기 및 IDE를 사용하는 경우 너무 제한적일 수 있습니다.

다른 규칙도 의도적으로 무시할 수 있습니다. 예를 들어, 개발자는 큰 따옴표를 전체적으로 사용하는 것이 더 나은 것으로 간주하고 우발적 인 보간의 "위험"과 구문 분석 시간의 극히 작은 증가를 기꺼이 받아 들일 수 있습니다.

많은 유지 보수 담당자는 검토하기가 지루하고 코딩 오류가 발생할 수 있으므로 큰 코딩 스타일 변경을 좋아하지 않습니다. 예를 들어, 문자열에 의도적 인 보간법이 포함되어 있고 큰 따옴표를 사용해야하더라도 문자열을 작은 따옴표로 전환 할 수 있습니다. 관리자는 실제 코드를 작업하는 동안 스타일 정리를 선호하므로 스타일 변경으로 인해 새로운 버그가 발생하지 않는지 확인할 수 있습니다.

당신은 rubocop 툴과 루비 스타일 가이드의 권위에 대해 크게 동기 부여가 된 것 같습니다. 루비 스타일 가이드는 관리자가 공유하지 않을 수도 있습니다. 그들은 이미 자신의 스타일을 가지고 있으며 익숙하기 때문에 모든 변경 사항은 프로젝트에서 작업하는 모든 사람에게 영향을 미치며 특히 프로젝트가 큰 경우 많은 작업입니다.

관리자의 동기를 고려하십시오. 그들은 아마도 버그 수정, 버그 보고서, 작업 코드 및 잘 작성된 문서를 제출하여 새로운 사람들이 참여하기를 원합니다. 당신이 나타나서 "루보 캅에 범죄가있다"고 말하면 그들은 "아, 좋아, 짐을 나누는 데 도움이되는 새로운 사람"이라고 생각하지 않을 것입니다. 그들은 "이 사람은 누구입니까? 어떻게해야합니까? "

오픈 소스 프로젝트는 장점이있는 경향이 있습니다. 업무의 질에 따라 존경을받습니다. 당신이 나타나고 훌륭한 일을하고 나서 스타일에 대한 관심 을 불러 일으킨다면, 그들은 여전히 ​​거절 할 수도 있지만,들을 가능성이 더 높습니다. "토론이 싸다, 나에게 코드를 보여줘"라는 오픈 소스가있다.

항상 도그마에 대한 실용주의. 코딩 스타일 가이드는 특히 교활한 형태의 악으로, 단일 / 이중 인용과 같이 경건한 말도 안되는 것에 대한 건축 적 관심에서 멀어집니다. 스스로에게 물어보십시오 : 그것은 정말로 차이를 만들어 줍니까?

그것들은 어느 정도까지는 좋을 수 있지만, 거의 종교적인 열정으로 그들을 대하는 두 번째로, 당신은 너무 멀리 갔다. 그것들은 지침, 제안, 의견, 사실이 아닙니다.

그들은 그냥 무시해야합니까? 아니요, 도구를 사용하여 살펴 봐야 할 사항에 대한 일반적인 아이디어를 얻을 수 있다는 장점이 있습니다.

주니어 유형이 사실에 대한 의견을 얼마나 자주 혼동하는지 궁금합니다.

서식을 수정하기 위해 열린 문제가있는 경우에만 이러한 변경 사항을 가져올 수 있습니다. 그렇지 않으면 자신의 브랜치를 시작하고 저자가 더 읽기 편하기 때문에 더 많은 사람들이 브랜치를 사용하는 것을 보게되면. 이들은 자체적으로 지점에 병합되지만 업데이트를 병합하고 지속적으로 서식을 수정하여 지점을 유지할 준비를합니다.

자신의 지점을 계속 유지하기에 프로젝트가 충분히 중요하지 않은 경우 처음부터 정리할 가치가 없습니다.

풀 요청은 작성자가 개인적으로 취할 수 있습니다. 비판을 제공하는 메커니즘은 아니며 모든 코드를 다시 포맷하는 것은 비판으로 간주 될 수 있습니다.

자신의 지사를 유지하고 싶지 않지만 프로젝트에 기여하고 싶은 경우. 새 문제를 열고 현재 형식으로 인해 문제가 발생하는 이유를 설명한 다음 저자의 문제 해결을 제안하십시오. 작성자가 동의하면 문제가 귀하에게 할당되고 이제 풀 요청을 할 수있는 권한이 있습니다.

또한 GitHub 의 중대한 문제라고 동의하는 주제에 대해 언급했습니다 . 형식을 제외하고는 주석 을 잘못 사용 하고 많은 IDE에서 혼란을 일으키는 많은 프로젝트 가 있습니다. 더 이상 사용되지 않는 플래그를 잘못 사용하여 IDE에 경고 메시지를 전파하는 세 가지 인기있는 프로젝트를 생각할 수 있습니다. 풀 요청을 보내서 수정했지만 작성자는 동일한 IDE를 사용하지 않으므로 풀 요청이 무시됩니다.

분기, 병합 및 수정이 유일한 솔루션 인 것 같습니다.

Rubocop 사이트 자체 (강조 광산) 에서 가져온 것 :

한 가지 사실은 루비 개발자로서 항상 귀찮았습니다. 파이썬 개발자는 훌륭한 프로그래밍 스타일 참조 (PEP-8)를 가지고 있으며 루비 코딩 스타일과 모범 사례를 문서화 하는 공식 안내서를 얻지 못했습니다 .

이해하십시오 :

공식 루비 스타일 가이드는 없습니다

스타일 가이드가 나쁘다는 말은 아닙니다. 그러나 공식 가이드는 없지만 스타일 가이드를 갖는 것은 개인, 프로젝트, 팀, 회사 수준에서 선택됩니다. 스타일 가이드는 심리학 용어를 "그룹 내 사회적 규범"으로 사용합니다.

그게 무슨 뜻입니까? 그룹 내 구성원으로 간주되지 않는 경우 이는 귀하 또는 다른 웹 사이트에서 언급 한 내용이 해당 그룹과 동맹 할 가능성이 거의 없음을 의미합니다. 따라서 해당 특정 프로젝트에 적극적이고 존경받는 기여자가 아닌 경우 제안이 무시되거나 스타일 가이드를 갖는 것에 대한 이전의 고려 사항을 상기시킬 가능성이 높습니다. 최악의 경우, 모욕으로, 또는 자신이 소유하지 않은 곳에서 코를 찌르는 인터 로퍼 또는 자전거 타는 사람으로 간주 됩니다.

스타일 가이드를 제안 할 수 없습니까?

스타일 가이드의 가치를 믿고 일관성을 중시 하며 통일 된 스타일 가이드 라인에 대한 헌신을 위해 복음 을 전 하고자합니다 .

그것이 당신이 무엇을하고 있는지, 그리고 당신이 성취하고자하는 것이 확실하다는 것이 확실합니다. 특정 스타일 가이드를 믿고 그것이 하나의 트루 스타일 가이드라고 생각하거나, 그 무법 한 이방인들이 연습을하는 것보다 더 낫다면, 그것도 괜찮습니다.

그러나 사람들이 인식하지 못하는 것은 그들의 행동이 합법적 인 권위를 고려하지 않는 출처에서 온 비공식적이고 구속력이 없으며 거의 ​​임의적 인 규칙을 따르지 않는다는 말을 듣는 것입니다. 그것이 당신이하기로 결심 했을 때, 또는 그것이 단지 당신이하고있는 것으로 인식 된다면, 당신은 "레드 카펫 처리"와 "창과 큰 끓는 냄비를 가진 화난 원주민"을 덜 얻게 될 것입니다 치료.

여기에 다른 의견을 제시하기 위해, 많은 경우에, 그러한 변화는 환영받을 것입니다. 오픈 소스 프로젝트에는 저자가 많은 경향이 있습니다. 종종 "코딩 스타일"이 없습니다. 스타일은 문제의 코드를 작성한 사람이 사용했던 모든 것입니다. 한 파일이 다른 사람과 다른 사람이 작성한 경우 스타일도 다를 수 있습니다. 합의 스타일이있는 프로젝트에서도 정기적으로이 스타일을 확인하지 않으면 자주 사용되지 않습니다.

내 경험에서 일반적인 예는 누군가 스타일이 상대적으로 낮은 풀 요청을 통해 일부 코드를 제공하는 경우입니다. 그러나 코드가 작동 할 수 있습니다. 다른 사람들은 이것에 대해 다른 견해를 가지고 있습니다. 어떤 사람들은 스타일이 좋지 않으면 풀 요청을 병합하지 않을 것입니다. 코드가 작동하는 한 어떤 사람들은 신경 쓰지 않습니다. 어떤 사람들은 좋은 스타일을 선호하지만, "여기에 공백을 고치십시오"라는 말로 기고자들을 놀라게하고 싶지 않습니다. 기여자가 겁을 먹을 것 같은 느낌이 들기 때문에 코드베이스가 좋습니다.

따라서 보이는 스타일이 프로젝트가 원하는 스타일이라고 똑바로 가정하지 마십시오. 실제로, 그것은 오픈 소스에 일반적으로 기여하는 것으로 일반화 될 수 있습니다 : 오픈 소스 프로젝트가 가지고있는 코드가 원하는 코드라고 가정하지 마십시오 .

그래도 몇 가지 사항을 알고 있어야합니다.

• 어떤 사람들은 스타일에 대해 종교적입니다. 그들이 번지기를 원하지 않는 것이 분명 해지면 귀찮게하지 마십시오.

• 이것은이다 거대한 bikeshed 문제를 해결합니다. 모든 사람들과 그들의 형제는 이것에 대해 의견을 가지고 있습니다. 이로 인해 이러한 풀 요청을 병합하는 것이 어려울 수 있습니다.

• 병합 충돌이 매우 빨리 발생하기 때문에 이러한 풀 요청을 병합하기가 어려울 수도 있습니다. 기본적으로 수정 한 코드베이스의 일부가 사소한 방식으로 변경 되더라도 변경 될 때마다

나는 "먼저 물어"접근법을 고수합니다. 그들이 열려 있고 끌어 오기 요청을 기꺼이 고수하고 싶다면 계속하십시오.

나는 좋은 스타일 가이드를 가지고 있었지만 루비의 상황을 감안할 때 "나는 움직였다".

기본적으로 나는 내가 일하고있는 것과 함께 살고 그렇지 않으면 여러 직업에서 배운 일반적인 규칙을 따릅니다.

내가 선택한 언어 인 Ruby의 경우에도 (나의 머리 속에서) 스타일을 보편적으로 받아 들여지고 일반적으로 받아 들여지는 나의 선호와 모범 사례로 나 divided 다. 보편적으로 수용되는 사항 이슈 또는 기능 분기 요청에 대한 변경 요청의 일부로 변경을 제출할 수 있습니다.

각 스타일의 예 (제 생각에는) :

루비에게 보편적으로 사용되는 것 :

• 탭이 아닌 공백
• 두 개의 공간 들여 쓰기
• method_names_use_underscores
• 상수는 Caps로 시작합니다.

일반적으로 허용되는 사항 :

• 필요하지 않은 경우 괄호를 사용하지 마십시오
• { }한 줄 블록과 do end여러 줄 블록에 사용하십시오 .
• CONSTANTS_ARE_IN_ALL_CAPS
• 표현식이 한 줄에 맞는 경우에는 예측 문 ( cond ? true : false)을 사용하십시오 if then.

개인 취향 :

• 120 자 길이의 줄 길이
• case when문은 case 문에서 2로 들여 쓰기됩니다.
• 이중이 필요하지 않으면 작은 따옴표를 사용하십시오.

동의 안함 :

• 사례 진술
• 선 길이

모범 사례:

• 작은 방법, 가능하면 <= 5 줄.
• 작은 클래스, 가능하면 <= 100 줄.
• 상수를 피하십시오
• 코드에는 테스트가 있습니다

마지막으로, 다른 사람들이 자세히 설명했듯이 먼저 문의해야합니다. 하루가 끝나면 스타일을 결정하는 열쇠는 개발자 간의 의사 소통과 다른 사람들의 감수성입니다. 예를 들어 오픈 소스 프로젝트에서 스타일을 변경하려면 하나 또는 두 개의 실제 기능 또는 버그 수정에 대한 풀 요청을 먼저 수행합니다. 메인테이너 께서 나를 아시고 내가 기여했다고보고하면 다음 나는 스타일 변경을 제안 할 수 있습니다. 난 단지 제안 하지만 그들. 예를 들어 "프로젝트 x에서 다른 기능을 수행하는 동안 몇 개의 파일에 4 개의 들여 쓰기가 있고 2로 변경할 수 있는지 궁금합니다."

비록 작고 수정하기 쉽지만, 공격을 수정하고 풀 요청을 작성하여 오픈 소스 프로젝트의 코딩 스타일을 변경해도 괜찮다고 생각하십니까?

요컨대, 아니!

물론, 나는 이것들이 단지 스타일의 문제이며 실제 버그는 아니라고 가정합니다. 후자의 요청은 항상 합리적 일 것입니다 (IMO). 또한 당신이 프로젝트에 익숙하지 않다고 가정하고 있습니다. 이미 관리하고있는 사람들과 접촉하지 않습니다.

그러나 어떤 언어 중에서도 스타일 가이드와는 다른 선호도를 가진 사람들이 항상 있습니다. 더 나은지 나쁜지, 모르는 사람들에게 스타일 변경을 적용하려고 시도하는 사람과 그렇지 않은 프로젝트가 있습니다. 의 다른 아무것도 할 수 비트로에서 제공하지 않는 경우 무례. 결국-요청이 수락되면 실제로 무엇을 달성하고 있습니까? 아마도 한 프로젝트의 구성원이 다른 스타일로 스타일을 변경하기를 원했다면 이미 완료했을 것입니다. 그 요청으로 할 일은 반드시 더 잘 작동하지 않는 스타일을 강요하는 것입니다. 기존 회원을 위해.

스타일 "수정"을 수행하는 것 이외의 다른 방법으로 프로젝트에 기꺼이 기여할 경우 약간 변경됩니다. 프로젝트에서 작업하고 싶지만 비표준 스타일을 찾는 방법에 대해 관리자와 대화를 열고 싶다면 괜찮습니다. 그러나 스타일 변경 만 포함하는 많은 프로젝트에 대한 풀 요청을 맹목적으로 만드는 것은 아닙니다.

코드의 인쇄 형식을 변경하더라도 버그가 발생할 수 있습니다.
따라서 유효한 비즈니스 사례가없는 한 코드를 변경하면 안되며 "코드가보기에 좋지 않습니다"또는 "코드가 코딩 표준을 따르지 않습니다"는 유효한 비즈니스 사례가 아닙니다. 위험은 너무 크다.
어쨌든 소스 파일을 크게 변경하는 경우 표준에 따라 전체 파일을 가져 오는 것이 가능할 수 있지만 대부분 작은 변경을 수행하는 경우가 있습니다. 기존 코드가 코딩 표준을 따르지 않더라도 기존 코드와 일치합니다.
코드는 코드 생성기의 결과 일 수 있으며 때로는 재생성 될 수도 있습니다. 코드 생성기는 추악한 코드 생성으로 유명합니다 ...

나는 약간의 성공한 .NET 프로젝트를 가지고 있으며, ReSharper와 StyleCop으로 코드를 살펴보고 많은 것들을 "고정한"사람들로부터 PR을 받았습니다. 다음과 같은 두 가지 이유로 해당 PR을 수락하지 않습니다.

• 많은 변경 사항이 더 나은 것이지만 일부는 일반적으로 성능에 영향을 미치며 좋은 부분을 선택하는 것은 너무 어려운 작업입니다.
• 모든 변경 사항이 양성이거나 유리한 경우에도 모든 커밋의 모든 파일에 대한 모든 변경 사항을 검토해야하며 다시 너무 오래 걸립니다.

즉, 누군가가 더 나은 오류 검사 또는 문서 주석을 추가하려면 해당 PR을 하트 비트로 수락합니다.

관리자가 이러한 코딩 스타일 위반을 결함으로 간주하는지 또는 프로젝트에 코딩 스타일에 대한 다른 표준이 있는지 확인해야합니다.

표준이 다른 경우 표준을 문서화하거나 공식화하도록 도울 수 있습니다. 그런 다음 해당 스타일을 위반 한 것으로 판명 될 수 있습니다.