짧은 변수 이름에 대한 변명이 있습니까?

이것은 현재 작업중 인 코드베이스에 큰 좌절이되었습니다. 많은 변수 이름이 짧고 설명이 없습니다. 나는 프로젝트에 남은 유일한 개발자이며 대부분의 사람들에 대한 문서가 없으므로 그들이 나타내는 것을 추적하는 데 더 많은 시간을 소비해야합니다.

예를 들어, 광학 표면의 정의를 업데이트하는 일부 코드를 읽었습니다. 시작시 설정된 변수는 다음과 같습니다.

double dR, dCV, dK, dDin, dDout, dRin, dRout
dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1));
dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1));
... and so on

어쩌면 그것은 나뿐이지만 본질적으로 그들이 나타내는 것에 대해 아무 것도 말하지 않아 코드를 이해하는 것이 더 어려워졌습니다. 내가 아는 것은 변수가 특정 테이블의 특정 행에서 구문 분석 된 변수라는 것입니다. 몇 가지 검색 후, 나는 그들이 무엇을 의미하는지 알아 냈습니다.

dR = radius
dCV = curvature
dK = conic constant
dDin = inner aperture
dDout = outer aperture
dRin = inner radius
dRout = outer radius

나는 본질적으로 내가 가지고있는 것으로 이름을 바꿨습니다. 일부 라인이 길어 지지만 공정한 거래 인 것 같습니다. 그러나 이런 종류의 명명 체계는 많은 코드에서 사용됩니다. 오래된 시스템으로 작업하여 배운 개발자가 인공물인지 또는 그 뒤에 더 깊은 이유가 있는지 확실하지 않습니다. 이런 식으로 변수의 이름을 지정해야 할 이유가 있습니까?

이러한 변수 이름은 다양한 광학 문제를 다루는 물리 교과서에서 찾을 수있는 약어를 기반으로합니다. 이것은 짧은 변수 이름이 더 긴 변수 이름보다 선호되는 상황 중 하나입니다. Rin, Rout 등과 같은 일반적인 약어를 사용하는 데 익숙한 물리학 자 (또는 손으로 방정식을 익히는 데 익숙한 사람들)가있는 경우 코드가 더 긴 변수 이름보다 약어가 더 명확합니다. 또한 종이와 교과서의 수식을 코드와 비교하여 코드가 실제로 계산을 올바르게 수행하는지 확인하는 것이 훨씬 쉽습니다.

광학에 익숙한 사람은 즉시 Rin과 같은 것을 내부 반경으로 (물리학 논문에서는 in첨자로 렌더링 할 것입니다), Rout을 외부 반경으로 인식합니다. innerRadius보다 친숙한 명명법을 좋아 하면 그 사람에게는 코드가 덜 명확해질 것입니다. 익숙한 수식이 잘못 코딩 된 사례를 발견하기가 더 어려워지고 종이 또는 교과서에서 찾은 수식으로 코드에서 수식을 변환하는 것이 더 어려워집니다.

만약 당신이이 코드를 본 유일한 사람이라면, 코드와 표준 광학 방정식 사이에서 번역 할 필요가 없으며, 물리학자가 미래에 코드를 살펴볼 필요는 없을 것입니다. 약어의 이점이 더 이상 비용보다 크지 않기 때문에 리팩토링하는 것이 합리적입니다. 그러나 이것이 새로운 개발 이었다면, 문헌에서 찾을 수있는 코드에서 동일한 약어를 사용하는 것이 거의 당연 할 것입니다.

수명이 짧은 변수의 이름을 짧게 지정해야합니다. 예를 들어, 당신은 쓰지 않습니다 for(int arrayCounter = 0; arrayCounter < 10; arrayCounter++) { .... 대신을 사용 for(int i ...합니다.

일반적으로 일반적으로 변수 범위가 짧을수록 이름이 짧아야한다고 말할 수 있습니다. 루프 카운터는 종종 단일 문자 (예 i: j및) k입니다. 지역 변수는 baseor from와 비슷 to합니다. 예를 들어 전역 변수는 다소 정교 EntityTablePointer합니다.

아마도 이와 같은 규칙을 사용하는 코드베이스가 따르지 않을 것입니다. 그래도 리팩토링을하는 좋은 이유입니다!

코드의 문제는 짧은 이름이 아니라 약어를 설명하거나 변수가 파생 된 수식에 대한 유용한 자료를 가리키는 주석이 부족하다는 것입니다.

코드는 단순히 문제 영역의 친숙 함을 가정합니다.

문제 영역에 대한 친숙 함은 코드를 이해하고 유지하는 데 특히 코드를 "소유하는 사람"의 역할에 필요하기 때문에 이름이 길어지기보다는 친숙 함을 얻는 것이 좋습니다.

그러나 코드가 스프링 보드 역할을하는 힌트를 제공한다면 좋을 것입니다. 도메인 전문가조차도 그것이 dK원뿔 상수 라는 것을 잊을 수 있습니다. 주석 블록에 작은 "치트 시트"를 추가해도 아무런 문제가 없습니다.

문제 영역에서 잘 알려진 특정 변수 (여기있는 경우와 같이)에는 변수 이름이 합리적입니다. 나는 게임에 일하고 있어요, 난 내 게임 엔티티 위치 변수를 갖고 싶어 x하고 y,하지 horizontalPosition와 verticalPosition. 색인을 넘어 어떤 의미가없는 마찬가지로 루프 카운터, 내가 볼 것으로 예상 i, j, k.

"클린 코드"에 따르면 :

변수 이름은 다음과 같아야합니다.

• 의도를 밝히십시오
• 잘못된 정보를 피하십시오
• 의미있는 구별
• 발음 가능
• 검색 가능

i,j,k,m,nfor 루프에서 사용되는 속담은 예외 입니다.

당신이 적절하게 불평하는 변수 이름은 위의 아무것도 수행하지 않습니다. 그 이름은 나쁜 이름입니다.

또한 모든 메소드는 짧아야하므로 접두어를 사용하여 범위 또는 유형이 더 이상 사용되지 않음을 나타냅니다.

이 이름이 더 좋습니다 :

radius
curvature
conicConstant
innerAperture
outerAperture
innerRadius
outerRadius

한 제안자는 이것이 긴 변수 이름으로 너무 복잡하다고 말합니다.

짧은 변수 이름으로도 간단하지 않습니다.

fnZR = (r^2/fnR(1+Math.sqrt((1+k) * (r^2/R^2)))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;

대답은 당신이 끝에 이것을 얻을 때까지 긴 이름과 중간 결과입니다 .

thisNiceThing =  ( thisOKThing / thisGreatThing ) + thisAwsomeThing;

레거시 코드에서 변수의 이름을 바꾸지 않는 데는 두 가지 이유가 있습니다.

(1) 자동화 된 리팩토링 도구를 사용하지 않는 한 버그가 발생할 가능성이 높습니다. 따라서 "깨지지 않았 으면 고치지 마십시오"

(2) 현재 버전과 이전 버전을 비교하여 변경된 사항을 확인하는 것은 불가능합니다. 이렇게하면 향후 코드 유지 관리가 더 어려워집니다.

이런 식으로 변수의 이름을 지정해야 할 이유가 있습니까?

더 작은 이름을 사용하는 이유는 원래 프로그래머가 쉽게 작업 할 수 있기 때문입니다. 아마도 그들은 그러한 경우를 찾을 권리가 있고, 당신과 같은 개인적 취향을 갖지 않을 권리가 있습니다. 개인적으로 나는 ...

dDin better than dDinnerAperture
dDout better than dDouterAperture

... 길고 복잡한 계산에 사용하는 경우. 수학 표현이 작을수록 모든 것을 한 번에 더 쉽게 볼 수 있습니다. 이 경우 dIn 및 dOut보다 우수 할 수 있으므로 반복적 인 D가 없어서 쉽게 오타가 발생할 수 있습니다.

반면에, 작업하기가 더 어렵다면, 자신을 기절시키고 이름을 바꾼 다음 더 긴 형식으로 바꾸십시오. 특히 해당 코드를 담당하는 경우.

일반적으로,이 규칙은 특정 코드의 "기술에 능숙한"사람들이 해당 변수 이름의 참조를 즉시 이해할 것이라는 매우 짧은 변수 이름을 사용할 수 있어야한다고 생각합니다. (어쨌든이 경우를 제외하고는 항상 의견이 있으며) 변수의 지역화 된 사용법은 사용 방법에 따라 쉽게 식별 할 수 있습니다.

이것을 확장한다는 것은 변수 이름을 난독 화하지 않아야한다는 것을 의미하지만 변수 이름에 약어를 사용하면 코드의 기본 개념을 이해하는 사람만이 가능하다는 것을 알 수 있습니다 어쨌든 그것을 읽을 수 있습니다.

실제 예제를 사용하기 위해 최근 에 위도를 측정하고 주어진 날짜에 예상되는 햇빛의 양을 알려주 는 Javascript 클래스를 만들고있었습니다 .

이 Sundial 클래스 를 만들기 위해 , 아마도 십여 개의 자원, 천문학 Almanac 및 다른 언어의 스 니펫 (PHP, Java, C 등)을 언급했습니다.

거의 모든 것에서, 그들은 비슷한 약어를 사용했는데, 그 의미에서 절대적인 의미는 없습니다.

K, T, EPS, deltaPsi, eot, LM,RA

그러나 물리학에 대한 지식이 있다면 그것들이 무엇인지 이해할 수 있습니다. 다른 사람 이이 코드를 만질 것으로 기대하지 않으므로 자세한 변수 이름을 사용하는 이유는 무엇입니까?

julianTime, nutationOfEclipticalLongitudeExpressedInDegrees, equationOfTime, longitudeMean, rightAscension.

또한 변수 이름이 일시적인 경우, 즉 일부 값을 임시로 할당하는 데만 사용되는 경우가 많으며, 특히 변수의 상황에서 자세한 버전을 사용하는 것은 종종 의미가 없습니다 목적을 설명합니다.

절대적으로있다; 종종 짧은 변수 이름 만 있으면됩니다.

필자의 경우 수석 Robotics 클래스에서 웨이 포인트 탐색을 수행하고 KISS-C에서 로봇을 프로그래밍합니다. 우리는 현재와 목적지 (x, y) 좌표, (x, y) 거리, 현재와 목적지 표제뿐만 아니라 회전 각도에 대한 변수가 필요합니다.

특히 x 및 y 좌표의 경우, 긴 변수 이름은 완전히 불필요하며 xC (현재 x), yD (대상 y) 및 pD (대상 phi)와 같은 이름은 충분하며 이해하기 가장 쉽습니다. 이 경우

프로그래머 프로토콜이 지시하는 것처럼 '설명 변수 이름'이 아니라고 주장 할 수도 있지만 이름은 간단한 코드 (d = destination, c = current)를 기반으로하기 때문에 처음부터 매우 간단한 주석은 모든 설명입니다 그들은 필요합니다.

이런 식으로 변수의 이름을 지정해야 할 이유가 있습니까?

일반적으로 복잡한 알고리즘은 matlab (또는 유사한 언어)으로 구현됩니다. 내가 본 것은 사람들이 변수 이름을 인수하는 것입니다. 그렇게하면 구현을 비교하는 것이 간단합니다.

다른 모든 대답은 거의 정확합니다. 이러한 약어는 수학과 물리학에서 찾을 수 있습니다 d(예에서 와 같이 시작하지 않음 ). d로 시작하는 변수는 일반적으로 미분 을 나타내도록 명명됩니다 .

모든 일반 코딩 안내서는 유형을 나타내는 첫 번째 문자로 변수의 이름을 지정하지 말라고 지시합니다 (모든 경우).

변수 이름이 합리적으로 짧은 이유를 생각할 수 있습니다.

짧은 이름은 짧은 눈 범위를 사용하여 읽기 쉽기 때문에 주의력이 짧습니다.

예를 들어, svdb가 "데이터베이스에 저장"을 의미한다는 사실에 익숙해지면 SaveToDatabase를 읽을 때 대신 4 자만 빠르게 스캔해야하기 때문에 소스 코드를 스캔하는 속도가 좋아집니다 (14 자, 상황이 더 나빠짐) 더 복잡한 작업 이름). 소스 코드 분석의 주요 부분을 차지하기 때문에 "읽기"가 아닌 "스캔"이라고 말합니다.

많은 양의 소스 코드를 스캔 할 때 좋은 성능 향상을 제공 할 수 있습니다.

또한 게으른 프로그래머가 코드를 작성할 때 이러한 짧은 이름을 입력하는 데 도움이됩니다.

물론, 이러한 모든 "속기"는 소스 코드의 일부 표준 위치에 나열 될 것으로 예상됩니다.

@zxcdw가 말한 내용을 약간 다른 방식으로 구성하고 접근 방식에 대해 자세히 설명하려면 다음을 수행하십시오.

기능은 순수 하고 간결하며 일부 기능을 완벽하게 캡슐화 해야합니다 . 블랙 박스 로직 (Black Box logic ) 40 년 동안 손대지 않은 상태에 관계없이 인터페이스 (in / out)로 인해 설계된 작업을 계속 수행합니다. 내부를 전혀 모르더라도 소리입니다.

이것은 작성하려는 코드의 종류입니다. 지속되는 코드이며 이식하기가 쉬운 코드입니다.

필요한 경우 코드를 세밀하게 유지하기 위해 다른 (인라인) 함수 호출 에서 함수를 작성하십시오 .

이제 적절하게 설명하는 함수 이름 (필요한 경우 자세한 정보!)을 사용하면 범위가 너무 작아서 단축 된 변수 이름이 잘못 해석 될 가능성을 최소화합니다.

변수 이름은 프로그램의 가독성을 돕기 위해 가능한 한 설명 적이어야합니다. 당신은 그것을 스스로 경험했습니다 : 이름이 잘못되어 프로그램이 무엇을했는지 식별하는 데 많은 어려움이있었습니다.

설명적인 이름을 사용하지 않을 이유는 없습니다. 그것은 당신과 프로젝트에서 일하거나 일할 다른 사람들을 도울 것입니다. 그럼 실제로이 단일 루프 카운터 : 짧은 이름 유효 사용.

분명히 이것은 // 주석에 대한 것입니까?

과제물에 설명이 포함 된 주석이있는 경우 두 가지 이점 을 모두 얻을 수 있습니다. 변수에 대한 설명 과 방정식은 해당 교과서의 내용과 쉽게 비교할 수 있습니다.

인터페이스 (예 : 메소드 서명, 함수 서명)의 경우 매개 변수 선언에 주석을 달아서이 문제를 해결하는 경향이 있습니다. C / C ++의 경우 .h 파일과 구현 코드를 장식합니다.

변수의 사용법을 아는 것이 문맥과 이름에서 명확하지 않은 변수 선언에 대해서도 마찬가지입니다. (이는 강력한 타이핑이없는 언어에도 적용됩니다.)

변수 이름을 막고 싶지 않은 것이 많이 있습니다. 각도는 라디안 또는도, 정밀도 또는 범위에 대한 허용 오차가 있습니까? 정보는 올바르게 처리해야하는 특성에 대한 귀중한 주장을 제공 할 수 있습니다.

나는 그것에 대해 종교적이지 않습니다. 나는 명확성에 관심이 있고 다음에 잊어 버린 자기 자신이 코드를 방문 할 때 그것이 무엇인지 확인하는 데 관심이 있습니다. 그리고 내 어깨 너머로보고있는 사람은 무엇인가가 어디에서 벗어 났는지, 무엇이 필수적인지 (적절한 유지 보수를 위해 마지막으로 중요한) 것을 알기 위해 알아야 할 것이 있습니다.

지나치게 짧은 변수 이름에 대한 변명이 있습니까?

첫째 : E = MC2와 같은 공식을 계산하는 동안 에너지 e에 대한 변수의 이름을 짓는 것은 지나치게 짧은 이름 이 아닙니다 . 인수로 문자 사용 에 대한 짧은 이름이 유효하지 않습니다

이 질문은 나에게 흥미로웠다. 나는 단지 하나의 변명 만 생각할 수있다. 그리고 그것은 돈이다.

예를 들어 파일이 초당 여러 번 다운로드된다는 것을 알고있는 클라이언트를 위해 자바 스크립트를 배선한다고 가정 해보십시오 . 파일 (바이트 수)이 가능한 작 으면 저렴하고 사용자 경험이 향상됩니다.

(예를 '현실적'으로 유지하기 위해 축소 도구를 사용할 수 없었습니다. 보안 문제, 외부 도구가 코드 기반을 건드릴 수 없었습니다.)

다른 답변에는 헝가리 표기법의 사용에 대해서는 언급되어 있지 않습니다. 이것은 긴 논쟁과 직교하지만 일반적으로 명명 체계와 관련이 있습니다.

double dR, dCV, dK, dDin, dDout, dRin, dRout

이러한 모든 변수의 시작 부분에있는 "d"는 변수가 두 배임을 나타냅니다. 그러나 언어는 어쨌든 이것을 시행하고 있습니다. 이 이름의 간결함에도 불구하고 최대 50 % 중복됩니다 !

명명 규칙을 사용하여 오류를 줄이려면 언어로 확인 되지 않은 정보를 인코딩하는 것이 훨씬 좋습니다 . 예를 들어, dK + dR길이에 차원이없는 숫자를 추가하는 것은 의미가 없지만 위의 코드에서 불평하는 언어는 없습니다 .

이러한 오류를 방지하는 좋은 방법은 더 강력한 유형을 사용하는 것입니다. 그러나 복식을 사용하려는 경우 더 적절한 이름 지정 체계가 다음과 같습니다.

// Dimensions:
// l  = length
// rl = reciprocal length
double lR, rlCV, K, lDin, lDout, lRin, lRout

이 언어는 여전히을 쓸 수 K + lR있지만 이제는 이름이 잘못되었음을 암시합니다.

이것은 시스템 헝가리어 (일반적으로 불량)와 Apps 헝가리어 (아마도 좋음) 의 차이점입니다.

http://en.wikipedia.org/wiki/Hungarian_notation

단지 그들이 스크립트에 존재하고 (일반적으로 네트워크를 통해) 해당 스크립트의 처리량이 중요한 경우 illegibly 짧은 변수 이름은 현대 소프트웨어 공학에서 허용되는 경우입니다. 그럼에도 불구하고 소스 제어에서 긴 이름을 가진 스크립트를 유지하고 프로덕션에서 스크립트를 축소 하십시오.