짧은 식별자가 잘못 되었습니까? [닫은]

짧은 식별자가 잘못 되었습니까? 식별자 길이는 코드 이해와 어떻게 관련이 있습니까? 식별자를 명명 할 때 고려해야 할 다른 요소 (코드 이해 외에)는 무엇입니까?

이 것을 그냥 답변 최대의 품질을 유지 메모를 기쁘게하려고하는 일부 이미 주제에 대한 연구가!

편집하다

내가 제공 한 두 링크가 모두 큰 식별자가 유해 함을 나타낼 때 모든 사람이 길이가 적절하다고 생각하지 않거나 더 큰 식별자를 선호하는 경향이 궁금합니다!

깨진 링크

아래의 링크는 주제에 대한 연구를 지적했지만 지금은 깨졌습니다. 나는 종이 사본을 가지고 있지 않은 것 같습니다. 다른 사람이 알아낼 수 있도록 여기에 남겨두고 있습니다.

• http://evergreen.loyola.edu/chm/www/Papers/SCP2009.pdf

내가 들었던 가장 좋은 "규칙"은 이름 길이가 변수 범위의 길이에 비례해야한다는 것입니다. 따라서 i루프 본문이 몇 줄이면 색인이 좋습니다.하지만 15 줄보다 길면 좀 더 설명적인 것을 사용하고 싶습니다.

각 변수에는 의미가 있어야하며 그 이름은 그 의미의 일부입니다. 그리고 매우 중요한 부분은 독자가 알고리즘을 더 깊이 파지 않고도 자신이 무엇을 이해하는지 이해하는 데 도움이되기 때문입니다. i, j인덱스로 사용하는 것은 명백하지만 짧지 만 매우 유익합니다. bnt추악 close하거나 closeButton의미가 있습니다. 따라서 짧거나 길다는 것이 변수 이름의 가장 중요한 기준은 아니므로 의미가 있어야합니다. 의미는 상황에 따라 크게 달라집니다. 예를 들어, n코드의 작은 블록에 사용되는 10 줄의 로컬 문자열 변수 와 같이 매우 짧은 이름을 지정할 수 있으며 속성의 이름을 나타냅니다 ( v값은 또 다른 예입니다).

따라서 변수 이름은 정보를 제공해야하며 짧거나 긴 것은 중요하지 않습니다 .

길이에 관계없이 변수를 설명하는 식별자를 사용합니다.

i, j 및 k 의 경우 자체가 너무 많아서 스스로 설명하고 있으므로 루프 인덱스임을 자동으로 알 수 있습니다. 당신은 또한 같은 것을 말할 수 있습니다 :

foreach loop (Strings s : myString)

그러나 IDE는 이제 코드 완성 도구를 제공하므로 매우 길고 설명적인 식별자의 유일한 부작용은 사라졌습니다.

변수의 목적을 설명하는 데 필요한 경우 식별자에 단어를 추가하고 추가합니다.

오해의 소지가있는 식별자만큼 나쁘지 않습니다. 식별자가 하나의 문자 인 코드를 디버깅하는 것은 신경 쓰지 않지만 다른 명명 규칙이 등장하는 순간 성가 시게됩니다. 당신이 볼 어딘가에 경우 예는 strPersonID다음 다른 곳에서 당신이보고 s_EmployeeID, 이러한 문자열 모두와 어떤 차이가 있는지 있다면 알려 혼란. 또한 변수가 복사 붙여 넣기 ( pmapIntString = new std::map<int,int>)되어 완전히 잘못되면 걱정할 것입니다.

나에게 올 때, 사용되는 중요한 변수에 대한 코드에 주석을 추가하고 개발 지침에 주어진 표준을 유지하려고합니다. 표준이 없으면 코드 전체에서 동일한 명명 규칙을 유지하려고합니다.

힘들어 ...

나는 항상 설명적인 이름을 식별자로 사용하지만 최근에는 매우 짧은 식별자를 사용했습니다.

코드의 컨텍스트에 따라 다릅니다.

• 복잡한 함수 (알고리즘)를 작성하는 경우 항상 짧은 식별자를 사용하십시오 (단일 문자가 가장 좋습니다)
• 함수의 매개 변수 값을 작성할 때는 설명적인 이름을 사용하십시오.

코드의 밀도에 따라 달라집니다. 때때로 이름이 있으면 실제로 읽기가 더 어려워집니다.

때때로 이름이 없으면 완전히 비밀입니다!

내 생각은 그들이 나쁘지 는 않지만 매우 표준 적이 지 않으면 유익하지 않다는 것 입니다.

따라서 루프 변수 i, j 및 k 는 매우 표준이므로 인덱스 루프를 생성하는 경우 변수 를 사용하지 않을 이유가 없습니다.

매우 짧은 식별자를 사용하는 다른 장소는 몇 줄로 범위를 벗어나는 임시 변수를 선언 할 때입니다 (예 : foreach 루프의 임시 변수). 다른 곳에서 언급되지 않으면 코드를 읽는 사람이 선언을보고 사용중인 내용을 따르는 것이 쉽습니다. 그래도 5 줄 이상 6 줄 이상 사용할 경우 더 명확한 이름을 지정하려고합니다.

유익한 길이의 식별자를 사용하려고하는 것 외에도, 특히 클래스 수준에서 변수가 무엇인지 읽고 이해할 수있는 식별자가 필요합니다. 그들이 너무 길어지면 (때로는 식별자에 대해 4-5 개의 단어가 함께 묶인 코드가 보임) 나는 코드 냄새로 간주하는 경향이 있습니다. 변수를 구별하기 위해 많은 텍스트가 필요하다면 실제로 그룹입니다. 해시 맵 또는 목록에 더 잘 저장 될 수 있습니까? 이 데이터를보다 정확하게 모델링하기 위해 어떤 종류의 객체를 만들 수 있습니까? 때때로 당신은 할 수 없지만 매우 긴 식별자는 여기서 볼만한 가치가 있음을 나타냅니다.

나는 여기에있는 다른 대답에 매우 동의하지만 종종 간과되는 다른 요인을 지적하고 싶습니다. 좋은 이름은 종종 코드에 관용적 인 이름입니다. 이것은 언어 수준, 알고리즘 수준 또는 현재 코드베이스에 대한 일부 내부 관용구에있을 수 있습니다. 요점은 이름이 코드의 도메인을 모르는 사람에게는 아무 의미가 없지만 주어진 맥락에서 여전히 최고의 이름 일 수 있다는 것입니다.

변수의 이름을 지정하는 것은 항상 독창성과 이해의 균형을 맞추기위한 연습입니다. 이름의 길이는 다른 방식으로 두 가지와 관련이 있습니다. 이름이 길수록 고유하게 만들 수 있습니다. 중간 길이의 이름은 너무 짧거나 긴 이름보다 이해하기 쉽습니다.

그것은 이해할 수 이력이 있으면 매우 짧은 변수 이름에만 유용하다 (예를 들어, i, j, k, 지수 용을 dx인용하는 경우는 모두 한 번에 표시 할 정도로 작은이거나 범위 축을 따른 거리) (예를 들어 , temp). 세계에서 최악의 변수 이름은 다음과 같습니다 t47. (이것은 무엇을 의미하며 왜 다른가 t46?) 고맙게도 네이밍 스타일은 대부분 FORTRAN과 함께 나왔지만, 이것이 더 긴 변수 이름에 대한 욕구에 뿌리를두고 있습니다.

원본 논문에서 알 수 있듯이 코드를 볼 때 미묘한 내부 차이를 놓칠 수 있으므로 너무 긴 이름도 읽기 어렵습니다. (사이의 차이 DistanceBetweenXAxisAbscissae&은 DistanceBetweenYAxisAbscissae빨리 데리러 정말 어렵습니다.)

NoteToSelf가 앞에서 지적한 것처럼 이름의 고유성 요구 사항은 주로 이름이 고유해야하는 범위에 따라 다릅니다. 5 라인 루프의 인덱스는 다음과 같습니다 i. 함수에서 함수로 전달되는 활성 레코드의 색인은 훨씬 더 설명적인 이름을 갖습니다.

함수에 지역 변수는 deltaX문제없이 작은 설명 이름을 가질 수 있습니다 . 모듈의 정적 델타 X 변수는이 델타 X를 동일한 모듈의 다른 델타 X와 구별하는 이름을 가져야합니다. 또한 전역 델타 X 변수는 모듈 이름을 다른 설명이 포함 된 이름으로 연결하여 모든 모듈과 생성 될 수있는 다른 모든 모듈에서 고유해야합니다. 이것은 세계적으로 많은 문제 중 하나입니다. 유용하게 고유하려면 이름을 읽기가 어려울 정도로 길어야합니다.

반대로, 나는 긴 식별자가 짧은 식별자보다 나쁘다고 생각합니다 (상수를 다루지 않는 한). 를 사용 TheVariableThatHoldsTheCapacityOfMyContainerClass하면 코드를 사용 하는 것보다 오류가 발생하기 쉽습니다 Capacity.

짧은 식별자는 나쁘지 않습니다. 코드 명을 명확하게하기 위해 좋은 이름 (짧거나 긴)을 선택하는 목적이 있습니다. 코드 명확성 서비스에서 식별자를 선택하는 것이 최소 길이 요구 사항을 충족시키는 것보다 중요합니다. 일반적으로 이것이 의미하는 것은 약간 더 긴 의미있는 이름을 쓰는 것입니다.

내가 몇 년 동안 가지고 왔으며 오늘날 10 년에서 15 년 전에 비해 덜 관측 된 결과. 입력 할 수없는 프로그래머는 변수 이름을 통해 치아와 손톱을 싸울 수 있습니다. 그것들은 1-3 글자 변수 이름을 가진 것들입니다.

그래서 많은 조언자가 말한 다음 입력하는 법을 배우는 것처럼 내 조언은 의미있는 이름을 사용합니다. 나는 사람들이 어디에 있는지 확인하기 위해 인터뷰에 타이핑 테스트를 추가하는 것을 고려하고 있었지만 컴퓨터가 사회의 더 큰 부분이됨에 따라 비타이 퍼가 훨씬 적어지기 시작했습니다.

첫 번째 링크는 흥미로워 보이지만 결론은 의미있는 변수 이름을 포함한 "접지 힌트"가 코드 이해에 도움이된다는 가설에 대한 중요한 증거를 찾지 못했다는 결론입니다. 사용 된 시선 체류 시간은 코드 이해를위한 프록시로서 흥미롭지 만 슬램 덩크는 아닙니다.

나는 두 번째 논문이 어리석은 것을 발견했다. 첫 번째 문제는 그들이 제공하는 긴 이름의 예제가 너무 길어서 추가 정보를 제공하지 않는다는 것입니다. 변수 이름을 더 길게 만들기 만하면 더 길다는 것에 동의 할 수 있습니다. dx 대신 가변 distance_between_abscissae를 명명하는 그들의 예는 짚맨입니다.

더 중요한 것은 그들의 실험은 이해력보다는 단순한 암기의 시험입니다. 문맥 이 없는 목록에 표시 될 때 변수 이름의 누락 된 부분을 채우는 주제의 능력을 테스트합니다 . 예, 더 긴 이름은 암기하기 어렵지만 코딩 할 때 변수 이름을 암기하지 않고 컨텍스트를 제공하는 데 사용합니다. 긴 변수를 기억하기가 어렵 기 때문에 코드를 작성하기가 더 어렵다고 생각할 수 있지만 코드를 작성하는 것보다 훨씬 자주 읽으므로 어떤 활동을 최적화해야합니까?

코드 행을 읽을 수 있는지 여부를 결정하는 주요 메트릭 중 하나는 다른 행의 다른 컨텍스트를 읽어야 실제로 행의 내용을 이해할 수 있습니다.

"i, j 및 k는 루프 변수라는 것을 누구나 이해할 수 있어야합니다"라고 말하기 쉽습니다. 그리고 대부분의 경우 정말 분명합니다. 그러나 나는 여전히 이것에 대해 겸손하고 전문성을 유지하려고 노력하며 프로그래밍 할 때 실수를 저지르기가 쉽다고 가정합니다. 따라서 Grobbles 배열을 반복하는 경우 루프 변수의 이름을 grobbleIndex로 지정합니다. 또한 i를 색인의 약어로 받아 들일 수 있습니다. ij 및 k를 사용하는 경우 잘못된 배열 등으로 잘못된 색인을 사용하는 것과 같은 오류를 찾기가 더 어렵습니다. 내부 루프가 있으면 더 나빠집니다.

추신. 이 대답을 쓸 당시에는 수직 분할 화면이있는 10 인치 미니 랩톱에서 일부 자바 스크립트를 코딩하고 있었고 여전히 루프 변수의 이름을 rowIndex 및 columnIndex로 지정했습니다.

일부 응용 프로그램에서 짧은 변수는 단순히 변수의 데이터를 설명 할 수 없습니다. 짧거나 긴 것은 관련이 없습니다. 더 긴 변수를 사용하면 코드가 느려지지 않습니다. 긴 변수 이름을 입력하는 것이 더 많은 노력이지만 6 개월 후에 코드를 읽는 사람 (적어도 될 수 있음)은 가능한 한 흔적을 남기지 않고도 무슨 일이 일어나고 있는지 알아낼 수 있습니다.

이상적으로는 이름이 설명 적이 지 않는 것이 이상적이라고 생각합니다 ...

이름이 제한적이라면 이름이 더 짧을 수 있고 따라서 의미를 덜 설명 할 수 있다는 생각 은 이상적인 것에서 벗어나는 한 가지 이유 일뿐 입니다.

개인적으로 자주 반복 참조되는 소수의 엔티티에 짧은 이름을 사용합니다. 예를 들어, 종종 앱 특정 서브 루틴이라고합니다.

4-5 자 미만의 식별자 이름은 절대 사용하지 않을 것입니다. 예를 들어 루프 변수는 무언가를 달성하는 데 필요한 내부 루프 수에 따라 Index 또는 jIndex 또는 kIndex 일 수 있지만 다른 이름의 경우 "키"라고합니다. "String LKey"또는 "int LKey", "L"로컬 인 경우 메소드 변수 인 경우 또는 "F"개인 클래스 변수 인 경우, 앞에서 언급 한 다른 모든 식별자는 이름에 존재하는 이유를 설명해야합니다. "식별자"범위가 쓸모 없습니까?!