하나의 밑줄로 사용하지 않는 변수의 이름을 지정하는 것은 나쁜 습관입니까?

언어의 구문에서 사용되지 않는 변수의 이름을 지정해야하는 경우가 종종 있습니다 _.

내 생각에 이것은 혼란을 줄이고 코드의 의미있는 변수에 집중할 수있게합니다. 나는 그것이 "눈에 보이지 않고, 마음에 들지 않는"효과를 낼 수 있도록 눈에 거슬리지 않는 것을 발견했다.

이 작업을 수행하는 일반적인 예는 SQL에서 하위 쿼리의 이름을 지정하는 것입니다.

SELECT *
FROM
(
    SELECT *
    FROM TableA
    JOIN TableB
        ON TableA.ColumnB = TableB.ColumnB
    WHERE [ColumnA] > 10
) _ --This name is required, but never used here
ORDER BY ColumnC

또 다른 예는 사용되지 않는 루프 변수입니다.

array = [[] for _ in range(n)] # Defines a list of n empty lists in Python

설명적인 이름이 코드에 아무 것도 추가하지 않는다는 느낌이들 때만이 기법을 매우 아예 사용하지 않으며, 어떤 의미에서는 기억할 이름을 더 추가하여 코드를 제거합니다. 어떤면에서는 varC # 의 키워드 와 비슷하게 보이며 드물게 사용합니다.

동료들이 동의하지 않습니다. 그들은 하나의 (알파벳) 문자 이름을 갖는 것보다 낫다고 말합니다 _.

내가 잘못? 이것을하는 것은 나쁜 습관입니까?

모든 이름은 의미가 있어야합니다. 경우 _기업이나 넓은 지역 사회에 잘 알려진 표준이고, 다음은 '중요하지 않습니다 이름 "과 같은 의미가있을 것입니다. 그렇지 않은 경우 나쁜 습관이라고 말할 수 있습니다. 특히 나중에 이름이 중요 할 수 있으므로 참조하는 내용에 대해 설명적인 이름을 사용하십시오.

나는 그것이 허용되는 관행이라고 말하고 싶습니다. 이것은 내가 대다수를 잘못 생각하고 최근 프로그래밍 아이디어에 대한 지식을 업데이트 해야하는 드문 경우입니다. 많은 언어, 특히 Haskell 및 OCaml과 같은 ML 기반 기능 언어 _에서 "사용하지 않는"변수 로 사용하는 것이 매우 일반적 입니다. 명시적인 언어 지원을 제공하지 않는 Lua조차도 _규칙에 따라 자리 표시 자로 사용하도록 권장합니다 .

여러 언어 (Haskell, Lua 및 DI는 내 머리 위로 생각)는 밑줄로 시작하는 변수가 _사용하지 않는 변수를 가장 짧게 만드는 "사용하지 않은 로컬 변수"에 대한 컴파일러 경고를 생성하지 않는 규칙을 제공합니다 . 당신은 같은 것을 사용할 수는 _unused있지만 그것이 혼란 스럽습니다.

파이썬 _에서는 확실하게 받아 들일 수 있습니다. 그러나 gettextalias 와 충돌 할 수 있습니다 _().

다른 일반적인 규칙은 다음 dummy과 같습니다 unused. 단독으로 또는 접두사로.

일부 코드 분석 도구는 이러한 규칙을 알고 있으며 사용되지 않은 변수 경고를 발행하지 않습니다.

• PyLint 에 대한 _또는dummy
• 를 PyDev는 어떤 변수로 시작 _, unused또는dummy

이 코드가 적용되는 생태계에 따라 다릅니다. _"더미 변수"/ "사용되지 않은 출력"을 나타내는 허용 된 표준 이라면 반드시 준수하십시오. 그렇지 않은 경우 무엇인지 찾아서 사용하십시오.

일부 프로그래밍 언어 (예 : Haskell)에는 정확히 언급 한 목적을 위해이 '특별한'식별자가 구문에 내장되어 있습니다.

_는 이미 일부 언어에서 본질적인 의미를 가지고 있습니다.

파이썬에서 :

9.6. 개인 변수 및 클래스 로컬 참조

링크 설명을 여기에 입력하십시오 . 파이썬 내부에는 객체 내부를 제외하고는 액세스 할 수없는“비공개”인스턴스 변수가 있습니다. 그러나 대부분의 Python 코드가 따르는 규칙이 있습니다. 밑줄 (예 : _spam)이 붙은 이름은 API의 비공개 부분 (함수, 메소드 또는 데이터 멤버인지 여부)으로 취급해야합니다. . 구현 세부 사항으로 간주되어야하며 사전 통지없이 변경 될 수 있습니다.

PEP 8 (Python 코드 용 스타일 가이드)에는 또 다른 언급이 있습니다.

설명 : 이름 지정 스타일

_single_leading_underscore : "내부 사용"표시가 약합니다. 예를 들어 M import *에서 이름이 밑줄로 시작하는 객체는 가져 오지 않습니다.

C #에서 :

일반적으로 공개 / 내부 속성을 가진 개인 변수를 표시하는 데 사용됩니다. 그러나 이러한 관행은 일반적으로 요즘 내려져있다 .

자바 스크립트에서 :

비표준 프로토 타입 확장을위한 접두사로 밑줄을 사용하는 underscore.js라는 라이브러리가 있습니다.

예:

var object = { some:'stuff' };
var newObject = _.clone(object);

내 요점으로 이끈다. 기존 자리 표시 자 변수 규칙에 문제가 있습니다.

var i, j, k, l; // iterator placeholders
var x, y, z, xx, yy, zz // value placeholders
var foo, bar, bas, fixx, buzz, qux, etc... // demonstration placeholders

이미 사용 가능한 공통 규칙이 많을 때 잘못 해석 할 수있는 사용자 지정 규칙을 사용하는 이유는 무엇입니까?

나는 그런 종류의 것을 위해 "더미"를 사용합니다. 또는 그냥 무언가를 테스트하고 있다면 "쓰레기": 변수가 무엇인지 설명하기 위해 변수의 이름을 지정하십시오. 그것들이 더미의 사용되지 않는 변수라면 그 이름을 지정하십시오.

나는 그것이 나쁜 습관이라고 생각합니다.

• 코드에 보이지 않는 변수가 없어야합니다. 당신이 느끼면 당신은 아마 이유를 논의 할 수 있습니다.

• Go 언어는이 키워드를 사용하여 변수가 함수의 여러 반환 값 중 하나의 대상이 아님을 나타냅니다. 언어가 여러 번 반환되지 않으면 필요하지 않습니다. _를 표준 언어 표기법으로 사용하는 언어를 사용하는 날에는 네이밍 규칙이 손상 될 수 있습니다.

(나는 파이썬을 모른다 :이 구조는 정말로 필요한가?)

구문 상 유효 할 수 있으며 표준의 일부로 괜찮을 수 있습니다.

그 말로 누군가에게 코드 검토에서 변경하도록 요청하는 것입니다. 또한 코딩 표준에 넣지 않았으며 기존 표준에서 제거하려고 시도했습니다. 읽기가 더 어렵고 의미가 없습니다.

나는 그것이 틀렸다고 생각한다.

1) 픽셀이 많지 않아보기가 어렵습니다.

2) 둘 이상인 경우 _어떤 것을 알고 있습니까? -또는 새로운 개발자가 '규칙을 따랐으며'범위 내에서 극도로 지역적으로 사용하고 있습니까?

3) 도움이되지 않는 연습입니다. 단일 문자 변수 이름을 사용하는 것은 너무 오래된 학교입니다 (예 : 나의 원래 교육!). 나는 그들을 볼 것이다 ... 그리고 코드가 무엇을하는지 말을 추가 한 주석을 보아라. 그것은 오늘날 세계에서 나쁜 습관이다. 프로그래밍 변수 나 코드에 익숙하지 않더라도 모든 사람이 영어처럼 거의 "읽을"수 있도록 긴 변수 이름을 가능한 많이 사용합니다. 1 개의 문자 이름을 사용하는 것은 오래된 코드와 나이든 프로그래머 (나를 포함하여)에게 매우 일반적인 관행이지만 괜찮지는 않습니다.

네임 스페이스 충돌을 피하고 디버깅을 허용하려면 변수 이름이 유일한 단서 인 경우 "joined_ab_unused"라고 부르는 것이 좋습니다.

Birfl에서 영감을 얻었습니다.

예, 두 가지 이유로 나쁜 습관입니다.

1. 사용하지 않는 변수에 밑줄을 붙이는 것은 널리 인정되지 않는 표준입니다. "시작되지 않은"무시 될 것입니다.
2. 일부 사람들은 개인 멤버 변수 앞에 밑줄을 붙이는 것을 보았습니다. 표준은 그러한 사람들을 크게 혼란스럽게 할 것 입니다.

당신이하려는 것은 쓸모없는 무언가의 이름을 강요하는 문제가없는 더 좋은 SQL 버전으로 코딩하는 것입니다.

밑줄은 거의 보이지 않으므로 해당 언어로되어있는 것처럼 보입니다. 공백 만 식별자로 사용할 수 있다면 완벽할까요?

그러나 당신은 다른 언어로되어 있지 않으며, 당신이하고있는 일은 언어 확장을 만드는 확실한 방법이 아닙니다.

언어에 따라 다릅니다. 에서 자바 , 그래이, 나쁜 및 코드에 추가 할 위험 추세 할 수 있습니다 때문에 크게 그들이 자바 변수 명명 규칙의 외부에 있기 때문에 사용 반사, 아주 잘 밑줄을 처리하지 않는 도구를 제공합니다. 에서 파이썬 ,이 또한 나쁘지하지만 나쁜 같습니다. 에서 Clojure에 자사의 100 % 좋아, 사실, 그 관용적는하자 문에 장소 소지자 _의를 사용합니다.

각 언어에는 고유 한 구문과 관용구 세트가 있으므로 절대 용어가 아닌 이러한 관용구의 관점에서 좋은 / 나쁜 점을 평가해야합니다.

이것은 perl에서 좋지 않을 것인데, $ _ (때로는 _)를 특수 변수로 사용합니다.

일반적으로, 나는 _가 특정 언어 변수 인 것처럼 보이기 때문에 멀리 떨어져 있습니다. 내가 당신의 코드를 본다면, 나는 그것이 더미라는 것을 깨달을 때까지 _가 무엇인지 찾는 문서에있을 것입니다. DUMMY, $ DUMMY에 문제가 없습니다.

주어진 언어 또는 프레임 워크에서 다른 용도로 많이 사용하지 않는 것이 확실하지 않으면 var 시작 부분에서 밑줄을 피하십시오. 예를 들어, 파이썬에서 이중 밑줄은 마술 var를 나타내는 경향이 있습니다. JQuery 및 기타 JS 라이브러리에서 단일 밑줄은 네임 스페이스 덮어 쓰기에 대한 대체 변수를 나타내는 경향이 있습니다. 또한 포함 파일을 처리하는 데 사용되는 이름 지정 규칙으로, var 형식의 포함 코드를 처리하는 경향이 있습니다.