소스 코드의 철자 오류가 심각한 문제인지 여부를 확인하는 방법은 무엇입니까? [닫은]

코드베이스에서 매일 보는 매우 어려운 철자 실수를 발견했습니다. 매우 짧지 만 대표적인 예를 재현합니다.

ArgumnetCount
Timeount
Gor message from queue 

불행히도 이것은 한 사람에게만 국한되지 않습니다. 우리 팀에는 영어를 모국어로 사용하지 않는 사람들이 많이 있지만, 미국에서 태어나고 자란 우리의 소프트웨어 설계자에게 최악의 철자 실수를 찾아 낼 수도 있습니다.

이것들은 이메일, 프리젠 테이션, 문서, 소프트웨어 개발 회사에있는 모든 서면 정보에서도 찾을 수 있습니다.

심각한 문제인지 확인하는 방법을 알고 싶습니다.

_{나는 항상 이러한 맞춤법 실수를 우려하면서 만났지만, 내 개인적이고 공식적인 정책은 우리가 올바른 철자를 지불하지 않고 일을 끝내기 위해 돈을 지불한다는 것입니다. 그러나 나는 가까운 친구들과 함께이 문제를 제기했으며 결코 좋은 결과를 얻지 못했습니다.}

철자 오류는 다음 두 가지 중 하나를 의미 할 수 있습니다.

• 영어를 능숙하게 구사하지 못하는 사람은 적절한 도구 (사전, 철자 검사기 등)를 사용하여 보상하는 데 시간이 걸리지 않습니다.
• 영어를 잘하는 사람은 영어에 능숙하지만 철자를 전혀 신경 쓰지 않습니다.

문제의 사람이 우선 순위 목록에서 가독성, 유지 보수성 및 우아함이 높지 않다는 것을 의미하기 때문에 상당히 나쁜 징조입니다. 원인이 영어 실력이 부족한 경우, 영어 의사 소통과 언어에 대한 일반적인 느낌, 두 가지 필수 기술이 부족함을 의미합니다. 프로그래밍 언어로 잘 표현하지 마십시오).

그러나 철자가 틀린 이유는 무엇입니까? 결국 코드가 작동하고 컴파일러는 구문 규칙을 위반하지 않는 한 식별자의 이름을 지정하는 방식에 전혀 신경 쓰지 않습니다. 그 이유는 우리는 컴퓨터뿐만 아니라 무엇보다도 인간을 위해 코드를 작성하기 때문입니다. 그렇지 않은 경우에도 여전히 어셈블리를 사용하고 있습니다. 소스 코드는 한 번 작성되지만 수명주기 동안 수백 번 읽습니다. 철자 오류로 인해 소스 코드를 읽고 이해하기가 더 어려워집니다. 약한 오류로 인해 독자가 1 초 동안 우연히 넘어 질 수 있으며, 상당수의 지연이 발생할 수 있습니다. 정말 나쁜 오류는 소스 코드를 완전히 읽을 수 없게 만들 수 있습니다. 또 다른 문제가 있는데, 이는 여러분이 작성하는 대부분의 코드가 다른 코드에 의해 참조 될 것이며, 그 코드는 다른 사람이 작성하지 않는 것보다 더 자주 발생합니다. 식별자의 철자가 틀리면 다른 사람이 이름이 무엇인지뿐만 아니라 철자가 얼마나 정확한지 기억해야합니다. 시간이 걸리고 프로그래밍 흐름이 중단됩니다. 대부분의 코드는 유지 보수에서 두 번 이상 터치되기 때문에 각 철자 오류로 인해 많은 중단이 발생합니다.

개발자 시간이 급여와 비용과 같은 방법을 고려해보십시오.이 경우를 쉽게 설명 할 수있을 것입니다. 결국, 흐름을 깨고 다시 들어가는 데 최대 15 분이 걸릴 수 있습니다. 이런 식으로 심각한 철자 오류가 발생하면 추가 개발 및 유지 관리에 수백 달러가 소요될 수 있습니다 (단, 간접 비용으로 추정 및 평가에 직접 표시되지 않으므로 경영진에 의해 무시되는 경우가 많습니다).

나는 "Timeount"가 원어민이 아닌 문제인지 실제로 의심합니다. 사람들은 모국어로 오타를 만듭니다. 이 특정 예를 "잉글랜드"로 인정하지 않습니다.

나는 이것이 특정 예에 관한 것이 아니라는 것을 이해합니다. 원칙적으로 동의합니다. 이 유형의 항목으로 인해 실제 문제가 발생했습니다 ( "첨부 파일이라는 열이 없으면 첨부 파일 만들기").

프로그래머가되는 것은 대부분의 경우 언어에 구애받지 않는 오타, 쉼표, 세미콜론, 점으로 정확하고주의를 기울이는 것입니다.

Timeout변수를 찾기 위해 변수를 검색하는 데 처음으로 시간을 낭비 하면로 작성된 Timeount철자가 중요한 또 다른 이유를 알게 될 것입니다.

이 문제가 당신을 귀찮게한다면, 대부분의 IDE는 이제 주석에서 철자 검사를 허용하므로 난독증이 철자법을 아는 것처럼 보일 수 있습니다. 확실히 나를 도와줍니다! 따라서 철자가 좋은 것은 사소한 "수정"입니다.

퍼블릭 클래스 이름과 메소드의 철자 오류는 단순히 전문가가 아닙니다. 시간과 돈이 들었습니다. IDE는 클래스 및 메소드 이름 메뉴를 생성 할 수있는 Java와 같이 정적으로 유형이 지정된 언어에서는 고통 스럽습니다. 동적으로 유형이 지정된 언어에서는 견딜 수 없습니다.

더 나쁜 것은 데이터베이스 테이블 이름과 열 이름의 철자 오류입니다.

내 경험상 올바른 철자는 코더의 영어 능력과 약간만 관련이 있습니다. 나는 영어 원어민이 본질적으로 임의의 철자와 단어 구분을 사용하여 코드를 생성하는 것을 보았고 올바른 철자를 생산하는 데 영어가 아닌 원어민을 보았습니다. 그러나 올바른 철자는 전체 코드 품질과 관련이 있습니다. 유능한 프로그래머는 영어 실력에 관계없이 업무의 질에 신경을 쓰며 명명에주의를 기울입니다.

소스 코드에서 내부 프리젠 테이션 및 문서 등 의미를 바꾸지 않거나 이해를 방해하지 않는 작은 오타는 문제가 아닙니다. 자극적이라고 생각되면 소스에 직접 수정하십시오.

또한 특히 의견에서 물질은 형태보다 중요합니다. 여기에 Engrish 없음 :

문자열 s = "Wikipedia"; / * "Wikipedia"값을 변수 s에 지정합니다. * /

사실 어떤 사람들은 다른 사람들보다 자연스럽게 더 신중한 작가들입니다 (교육 때문인지 태도 때문인지 지능 때문이든 상관 없음). 이 문제를 해결하기 위해 얼마나 많은 노력을 기울이는가는 비즈니스 가치 문제입니다. 오타를 수정하는 데 드는 것보다 오타를 수정하여 더 많은 가치를 얻습니까? 내부 물건의 경우 대답은 일반적으로 아니요입니다. 오픈 소스를하지 않는 한 고객은 소스 코드 주석의 오타에 대해 불평하지 않을 것입니다.

의도적으로 잘못 입력하고 부적절한 의견은 전문가가 아니므로 피해야합니다. 그러나 초점은 중요한 사안에 있어야합니다 (즉, 비즈니스를 위해 일하는 경우 비즈니스 가치 창출).

공개적으로 보이는 물건은 반드시주의 깊게 교정해야합니다.

여기서 문제는 영어 자체가 아니라 의견의 명확성 부족입니다. 완벽한 영어는 필요하지 않습니다. 명확한 영어입니다. 명백한 오류를 포착하기 위해 Google을 통해 무언가를 실행하는 것은 사소한 일입니다.

예를 들어 Gor message from queue"대기열에서 메시지 가져 오기"또는 "대기열에서 메시지 보내기"를 의미하는 경우 첫눈에 명확하지 않습니다 . 주석의 의미를 이해하려면 주석을 읽어야합니다 (따라서 주석의 목적을 무너 뜨립니다).

회사에서 코드 검토를 구현하도록 요청해야합니다. 그런 다음 사람들이 당신에게 똑같이하는 동안 건설적인 방식으로 "비판"할 수 있습니다.

변수를 참조 할 때와 같이 동일한 철자를 사용하는 한 컴파일러는 철자가 틀린 것을 신경 쓰지 않는 것이 분명합니다. 문제는 철자가 틀린 코드가 팀 구성원의 코드 유지 능력에 부정적인 영향을 미치는지 여부입니다.

내가 볼 수있는 유일한 방법은 유지 보수를하는 사람들과 이야기하는 것입니다. 누구가 틀린 코드를 따르는 데 어려움을 겪고 있는지 물어볼 수 있습니다.

나는이 문제에서 주관성을 완전히 제거 할 수있는 방법이 없다고 생각하지만 그것을 줄이기 위해 (수동으로 또는 스크립트를 통해) 소스를 스캔하여 특정 코드 모듈에 대해 잘못된 철자 수를 추정하고 유지 보수가 가능한지 확인할 수 있습니다 맞춤법 오류가 많은 모듈에서 맞춤법 오류가 적은 모듈보다 평균 시간이 더 오래 걸렸습니다.

모든 모듈이 동일하게 만들어지는 것은 아니므로, 모듈의 순환 복잡성과 같은 다양한 메트릭으로 결과에 가중치를 부여 할 수 있습니다.

내 경험상 이러한 기본적인 철자 오류는 문제가되고 더 깊은 문제의 증상 일 수 있습니다. "사소한"오류로 작업 한 모든 프로젝트는 디자인 과정에서 개발 과정에서만 검토 과정을 거쳐야만 실제로 문제가 발생했습니다. 이는 실제로 중요한 기능이 무엇인지 알고 싶을 때가 아닙니다. 없습니다.

시스템 사양 (있는 경우)을 다시 확인하고 전체 디자인을 조사합니다. 구멍을 발견해도 놀라지 않을 것입니다.

이것은 실제로 두 가지 별도이지만 관련된 문제입니다. 철자가 틀린 위치에 따라 다릅니다.

1) 소스 코드에서. 와 같은 식별자 ArgumnetCount가 있으면 누군가가 와서 올바른 철자를 사용할 때 실제 문제가 발생할 수 있습니다 . 따라서 가능할 때마다 이러한 실수를 수정해야합니다. 이전 버전과의 호환성을 유지해야하는 경우 다음과 같은 작업을 수행 할 수 있습니다.

/**
 * @deprecated - use setArgumentCount()
 */
public void setArgumnetCount(int c) {
    setArgumentCount(c);
}

2) 사람이 읽을 수있는 텍스트 (이메일, 문서, 코드 주석). 그것들을 올바르게 작성하는 것이 중요하지만, 머리 속의 파싱 소프트웨어가 훨씬 더 관대하기 때문에 우선 순위가 낮습니다. 몇 가지 실수가있는 텍스트가 여전히 읽을 수 있지만 걱정하지 마십시오. 문제가 아닙니다. 그러나 누군가가 당신에게 무료 관련 넌센스를 보내고 다중 사용자 웹 응용 프로그램의 청사진으로 그 넌센스를 사용하기를 기대한다면, 저자에게 설명을 요구하는 공손한 메모를 보내야합니다. 내가 이거 이해하길 바래? ")

올바른 철자 영어는 코드에서 필수입니다. 나는 또한 횡설수설로 가득 찬 큰 코드베이스를 가지고 있으며 유지 관리하는 것은 악몽입니다.

손을 떼지 마십시오. 코드 관리자가 독자가 아니라는 사실을 모든 사람에게 알리십시오.

글쎄, 이것은 많은 문화적 문제입니다.

독일어 관점에서 말하면, 우리는 우리의 언어가 영어 용어에 점점 더 많은 영향을받는 것을 알 수 있습니다. 이것은 국가 기업이 영어 슬로건이나 광고를하는 한 계속됩니다. 특히 경영직에 종사하는 일부 사람들은 명백한 독일어로 한 문장을 말할 수 없지만 한 문장을 말할 수는 없습니다. 그들의 연설은 화려하고 이해하기 어려운 경영 속어로 가득 차 있습니다. 우리는 그러한 사람들이 "날씨"라고 말합니다.

이러한 상황과 영어가 특히 소프트웨어 비즈니스에서 "lingua franca"라는 점을 감안할 때 영어 자체가 수많은 비 원어민의 영향을받는 것은 불가피합니다. 그러나 영어 원어민에게는 SW 산업에 참여하기 위해 중국어를 배우는 것보다 여전히 낫습니다.

색깔입니까? 영어 누구의 버전은 어떻게 당신이 올바른 생각? 한 사람의 올바른 철자는 다른 사람이이기는 전쟁을 시작하는 변명입니다.

전쟁을 시작하려면 신중하게 전투를 선택하여 승리하십시오. 귀하의 경우 의견에 대해 걱정하지 말고 내부에 대해 걱정하지 말고 API에만 집중하십시오 (거의)

깔끔한 코드가 반드시 깔끔한 마음을 의미하는 것은 아니지만, 그 반대는 확실합니다 : 어수선한 코드, 어수선한 마음.

변수 이름을 정확하게 지정하고 주석을 올바르게 작성하는 데 시간을 소비하지 않는 프로그래머는 거의 다른 일을하는 데 거의 시간이 걸리지 않습니다. 프로그래머가 영어를 모국어로 사용하는지 여부는 실제 문제가 아닙니다. 그의 영어 문제는 동료 검토 중에 해결 될 수 있기 때문입니다.

예, 제품, 팀 및 개인에게 심각한 문제입니다.

• 제품의 경우 : 수정시 고객에게만 결함이 발생할 수 있습니다.
• 팀의 경우 : 팀은 가치를 창출하지 않고 조잡한 코딩을 수정하는 데 시간을 소비합니다.
• 개인의 경우 : 철자가 틀리면 어리석게 보이며 동료들 사이에서 전문적 지위가 낮아집니다.