누군가의 코드에서 철자법 / 문법 관련 실수를 지적해야합니까? [닫은]

동료의 코드를 검토하는 동안 함수 이름의 철자 오류와 함수 및 변수 이름의 'doesUserHavePermission ()'대신 'doesUserHasPermission ()'과 같은 문법 오류가 발생했습니다.

이것들을 그에게 지적해야합니까, 아니면 이것들을 알아 차려서 너무 비관적입니까?

맞춤법 및 문법 오류가있는 코드는 유지 관리 할 수 ​​없습니다 .

• 사람들은 나쁜 문법을 기억하지 못하기 때문에 함수가 작성된대로 함수를 호출하려고 시도 할 것입니다. 이것이 버그가 발생하는 방식입니다.

• 철자가 어떻게 나오는지 모르면 코드에서 무언가를 잡을 수 없습니다.

• 문법 / 맞춤법을 사용하는 사람들은 대부분 일관되지 않으므로 이름이 일치하지 않는 많은 버그가 발생합니다. 이것은 새로운 철자를 도입 할 수 있고 코드가 당신을 망쳐 놓았다는 것을 알리기 위해 분쇄가 오지 않기 때문에 사용하기 전에 변수를 명시 적으로 선언 할 필요가없는 언어에서 특히 문제가됩니다.

이러한 문제를 해결하는 것은 현명한 것이 아니며, 주로 지능, 문해력 등에 대한 다른 사람들의 의견에 의해 필요하지도 않습니다 (큰 부작용이지만). 품질, 유지 보수 가능한 코드 작성에 관한 것입니다 .

네 물론 이죠 문법적으로 정확하면 이름을 기억하기가 더 쉽습니다. 이름 과 문법 실수 를 기억하는 것은 완전히 다른 것입니다.

공식 코드 검토에서 결함으로 지적하지 마십시오. 대신 목록을 작성하고 개인에 대해 이야기하십시오. 가능한 한 외교관이 되십시오. "이봐, 내가 알아 차린 것, 그리고 이런 종류의 일을 진지하게 내려다 보는 사람들을 만났을 때 그들은 프로그래머를 부주의하고 부주의하게 보이게한다"고 말했다.

고객이 볼 코드 인 경우 반드시 수정해야합니다. 좋든 싫든 그것은 회사의 평판에 반영됩니다.

예를 들어 UserHasPermission으로 시작한 것으로 의심되며 다른 사람이 로컬 연습이 UserBlahBlah ()가 아닌 doesUserBlahBlah ()라고 말했으며 문법 변경을 간과했습니다.

직접 변경하십시오.

코드 "소유권"이 문제가되지 않는 환경에 있기를 바랍니다. 소스 제어에서 프로젝트에 액세스 할 수 있으면 직접 들어가서 수정하십시오. 특정 동료가 동일한 유형의 문법이나 철자 오류를 일관되게보고있는 경우이를 지적하고 싶을 수도 있지만 관계, 사람이 영어를 모국어로 사용하는지 여부 및 일반적인 수용력에 따라 달라집니다. 그러나 당신이 그것을하기로 결정하든 아니든간에 조용히 가서 수정하십시오. 나는 항상 메소드 서명이나 공공 재산에서 오타가 보이면 이것을 고칩니다. 때로는 주석에 오타를 고치려는 유혹에 저항 할 수 없지만 그것은 단지 나입니다 :)

나는 모국어가 영어가 아니며 실제로 네덜란드어 인 개발자이며 누군가 문법이나 철자 실수를 지적하더라도 전혀 신경 쓰지 않을 것입니다. 이런 식으로 저는 영어 실력을 지속적으로 향상시킬 수 있습니다. 그리고 모든 소스 코드의 모든 실수를 수정하는 것은 어렵지 않습니다. 폴더에있는 모든 파일을 통해 간단한 Perl 스크립트를 작성하여 쉽게 작성할 수 있습니다. 아마도 sed로도 할 수 있습니까? 모르겠어요

그래서 나는 다른 사람의 코드에서 문법이나 철자 실수를 분명히 지적 할 것이지만, 내가 말하는 것이 정확하다고 확신하는 경우에만.

HTTP 프로토콜의 HTTP 리퍼러 헤더가 "리퍼러"로 잘못 표시되었다고 언급 할 가치가 있다고 생각합니다 (그리고 우리는 함께 살아야합니다.

문법 오류가있는 코드를 유지할 수 없다는 다른 답변에 동의합니다.

또한 몇 가지 사항을 추가하고 싶습니다.

• 코드는 종종 영어를 잘 못하거나 영어를 모국어로 사용하지 않는 사람들이 작성합니다. 검토 한 코드에 문법 오류가 있다고해서 이것이 동료가이 오류를 만든 것은 아닙니다. 웹 사이트에서 복사 한 붙여 넣기 일 수 있습니다.
• 영어가 동료의 모국어가 아닌 경우이 실수에 대해 이야기하는 것이 좋거나 나쁜 생각 일 수 있습니다. 저는 프랑스 출신이기 때문에 영어로하는 실수에 대해 항상 환영합니다. 왜냐하면 나중에 실수를 피할 수있는 유일한 방법이기 때문입니다. 다른 한편으로, 나는 당신이 문법 실수에 대해 말하면 정말 상처를받는 몇몇 사람들을 알고 있습니다.
• John R. Strohm이 말했듯이 공개적으로하지 마십시오. 대부분의 사람들은 이것에 정말로 짜증을 낼 것입니다.

빌트인 맞춤법 검사기와 함께 IDE를 사용하는 것이 좋습니다. IntelliJ Idea는 Java 프로그램에서 훌륭한 일을합니다. 함수 이름뿐만 아니라 사용자가 볼 수있는 예외 메시지와 같이 많은 난처한 오타가 있습니다. 오타로 가득 찬 메시지를 생성하는 프로그램은 큰 자신감을 얻지 못합니다.

나는 경우에만

• 프로그램 사용에 영향을 미칩니다
• 프로그램의 정확성에 영향을 미칩니다
• 저자가 수정되기를 원한다는 것을 분명히 알고 있습니다.

참고로 함수 이름이 문법을 가질 정도로 길면 너무 길 수 있습니다. 주어진 예제에서 userHasPermission 함수를 호출하고 다음 과 같이 "grammar"를 코드로 옮깁니다.

if userHasPermission() ...

이것은 또한 내 프로젝트 (많은 히브리어, 러시아어 또는 아랍어를 사용하는 사람들에 의해 채워짐)에서 많이 발생하지만 더 높은 수준까지도 종종 발생합니다. 저자가 염두에 두었던 것은 그들이 의미 한 것과는 아무런 관련이 없습니다.

개인적으로, 프로젝트에 참여하기 전에 코드를 작성할 수있는 많은 팀 구성원이 자주 발생하는 경우 문제가되지 않기 때문에 무시하는 경향이 있습니다.

그러나 오래 전에 작성된 코드 또는 주석과 동일한 파일에서 일부 작업을 커밋하고 오타가있는 경우 너무 많은 작업이 아니기 때문에 수정합니다.

황금률 적용

다른 사람들에게 당신이하는 것처럼 행동하십시오.

나는 다른 사람들이 이런 종류의 일에 등을 돌리기를 원하므로 다른 사람들을 돕습니다. 은혜 롭고지지적인 태도는 당신에게 유리할 수 있습니다.

다른 많은 좋은 프로그래밍 관행과 마찬가지로 프로그램의 철자법에 대한 정책을 구현하는 객관적이고 비 정치적이며 효과적인 방법은 사전 커밋 프로세스의 일부로 자동화하는 것입니다. 자동화는 목적을 위해 자신의 도구를 작성해야하는 경우에도 엄청난 불만을 덜어줍니다.

이것은 코드에서 사소한 실수이지만 실수입니다. 찾은 다른 실수처럼 취급하십시오. 본인의 정책은 항상 내 동료 직원이 유능하다고 가정하고 달리 입증 될 때까지 그러한 방식으로 대우합니다.

그것이 하나의 실수라면 그냥 고쳐서 체크인 할 수도 있습니다. 패턴 인 경우 해당 동료에게 수정 사항을 검토하도록 시작할 수 있습니다. 그들이 좋은 코더라고 생각하지만 개선하기에 좋은 것임을 알려주십시오. 나는 이런 식으로 큰 일을 한 적이 없다고 생각합니다.

큰 문제인 것처럼 취급하지 않는 한, 동료 직원을 자아를 두지 않고 개선 할 수있는 위치에 두는 것이 쉬워야합니다.

userPermission () 아마도? -

마지막으로 찾은 것은 클래스 이름의 철자가 너무 커서 검색 결과가 강조 표시되지 않는 전역 문제였습니다. 매우 모호한 버그가 발견되었습니다.

분명히 지적하지만 철자 실수를 확인하는 데 시간을 낭비하지 마십시오. 도구를 사용하여 CI에서이를 자동화하십시오. .net fxCop 에서이 작업을 수행 할 수 있습니다 ...

그것은 실수가 무엇인지, 얼마나 흔한 지 그리고 얼마나 나쁜지, 그리고 그것이 진짜 선의의 실수인지 또는 어떻게 말했는지에 달려 있습니다.

어떤 바보가 5 분 동안 코드 검토를 30 분 내로 끌면 개인적으로 그것을 참을 수 없다. 왜냐하면 그는 모든 것을 그가 어떻게했는지에 따라 이름을 바꾸고 싶어하기 때문이다. "데이터 오브젝트로드" 를 "데이터 오브젝트 로더 구성 요소가 이제 데이터 오브젝트 스토리지 구성 요소에서 관련 데이터 오브젝트를로드합니다"로 변경할 필요 가 없습니다 .

/ rant :)