Angular-styleguide: public/private 회원을 중심으로 한 컨벤션

나는 그것에 전적으로 동의합니다. 죄송합니다, 그 부분을 놓쳤습니다.

시원한.

그리고 귀하의 문제에는 가이드에 추가해야 할 중요한 관점이 있다고 생각하므로 다시 열겠습니다. :)

이 가이드에 이름 지정에 대한 부분을 추가하고 싶습니다. 당신이 묻는다면 다른 사람도 마찬가지일 것입니다.

멤버가 아닌 개인 함수 이름에 밑줄을 사용하는 이유는 무엇입니까? 그것도 비공개로? 또는 밑줄이 함수 자체에 다른 의미를 부여합니까?

이제 당신이 그것을 언급 했으므로 예, 속성에 대해서도 밑줄을 선호합니다. 다음과 같은 것을 가질 수 있습니다.

private _foo: string;

@Input()
set foo(value) { this._foo = value; }

get foo() { return this._foo; }

물론 더 복잡한 setter와 getter를 사용합니다.

네, 오타

개인적으로 밑줄을 좋아하지 않는데... 하지만 자바스크립트에는 진짜 private도 public도 없기 때문에 구별할 수 있는 방법이 있으면 도움이 많이 됩니다. 그래서 나는 그것들을 사용한다

업데이트: 저는 ES5를 언급하고 있었습니다... Typescript로 밑줄을 사용하지 않습니다

밑줄이 생략되면 혼란이 있을 것이라고 생각하십니까?

TypeScript/JavaScript에는 진정한 개인 변수가 없으며 클래스를 사용한다는 것은 클래스 이전의 JavaScript보다 변수를 숨길 수 있는 능력이 훨씬 더 적다는 것을 의미합니다. 우리를 구할 '_' 규칙만 있습니다.

'_' 규칙의 주요 가치는 " 만지지 마십시오! "라고 외치는 것입니다. JavaScript를 디버깅할 때 계속 진행해야 하는 모든 것입니다.

사람들이 디버거에서 something.foo 를 볼 때 foo 가 (a) 공개적이고 문서화되지 않았는지 또는 (b) 비공개인지 확실히 알 수 없습니다. 적절한 통지 없이 자신의 코드에서 자유롭게 참조할 수 있습니다. 그 순간 개발자는 지원 의무가 발생합니다.

독자가 _foo 볼 때 한계를 벗어났다 는 것을 알아야 합니다. _foo 를 참조하는 경우 _자신의 위험 부담_입니다. 개발자가 제거하거나 동작을 변경할 때 눈물이 없어야 합니다.

문서와 샘플에서 private 멤버는 '_'로 시작해야 합니다. private 접두사 '_'를 생략한 경우 신속하게 수정합니다.

Ward의 가정은 우리가 자바스크립트를 디버깅할 것이라는 것입니다. .... 이상해 보일 수 있지만 소스맵이 너무 뜨겁게 작동하지 않거나 무슨 일이 일어나고 있는지 더 명확하게 이해하기를 원하는 경우 훌륭한 백업 계획으로 봅니다.

또한 사용 방법에 대한 훌륭한 시각적 지표입니다.

워드가 말한 모든 것.

또한 ng2를 사용하면 다음과 같은 참조를 가질 수 있습니다.

<my-dir #myDir>

내부 속성에 액세스합니다. 그들 중 하나에 밑줄이 있으면 "내일 고장날 수 있으니 하지 마세요"의 신호입니다.

동의합니다. 더 나은 구별 방법은 없습니다. 개발자를 위한 오래된 학교입니다. 편의성 빼고는 나쁘지 않습니다.

Angular 2 문제는 이제 angular.io 리포지토리의 A2 스타일 가이드로 이동합니다.

현재 Angular codeStyle(규칙 03-04) 이 @johnpapa 의 제안과 비교하여 여기에서 변경되었으며 이제 개인 변수에 밑줄을 사용하지 말 것을 권고합니다.

Avoid prefixing private properties and methods with an underscore.
- Why? Follows conventional thinking for properties and methods.
- Why? JavaScript lacks a true private property or method.
- Why? TypeScript tooling makes it easy to identify private vs. public properties and methods.

따라서 이것은 이 문제에서 제안된 것과 반대입니다.

이 문제를 처음 읽었을 때 차이점을 발견했다고 생각했지만 업데이트된/뒤집힌 규칙은 타이프스크립트 코딩 지침 (이름에 대한 규칙 nr 6)과 일치합니다.

TypeScript tooling 논쟁이 John을 흔들었을 수도 있다고 생각합니다. 그가 Gulp에 매우 능숙하기 때문에 디버깅을 위해 작동하는 .map 파일이 없는 것은 실행할 수 없는 상황일 뿐이며 코드에서 밑줄을 사용하여 수정하는 대신 직접 해결해야 한다고 결정했을 수도 있습니다.