자바 스크립트의 한 측면은 정보를 찾기가 어렵다는 것입니다. 케이스 연습으로, 어떤 요소 (생성자, 개인 함수, 공용 함수)에 어떤 케이싱 스타일 (즉, 카멜 케이스, 파스칼 케이스 등)을 사용해야 하는지를 의미합니다.자바 스크립트에 가장 적합한 케이스 스타일은 무엇입니까? 왜?
내가 들었던 유일한 규칙은 YUI 극장의 Douglas Crockford 강의에서 생성자가 대문자로 시작하는 유일한 기능이어야한다는 것입니다.
그 밖에도 자바 스크립트에서 사람들이 따르는 많은 표준이있는 것처럼 보이지 않습니다.
누구나 자바 스크립트의 모범 사례를 알고 있으며 왜 사용하는 것이 합리적입니까?
또한 .js 파일의 케이스 스타일을 따르십니까?
나는 다른 모든 것에 대해서는 생성자와 camelCase에 대해 PascalCase를 선호합니다. JS 표준 라이브러리가 사용하는 스타일입니다. 지금까지 본 모든 JS 프레임 워크 :
그리고 웹에서 제공되는 모든 파일에 대해 all_lowercase 명명 규칙을 사용합니다. 대/소문자를 구분하지 않는 파일 시스템이 인 경우입니다.
저는 생성자를 제외한 모든 것에 대해 camelCase를 선호합니다. 이유는 (그리고 이것이 Mr. Crockford가 이것을 제안한 이유라고 생각합니다.) Java와 같은 다른 언어에서는 컨스트럭터가 사용되는 클래스를 대문자로 사용하기 때문입니다.
그건 내 $ 0.02입니다.
핵심 언어는 메서드 및 속성 (예 : something.toString(), quantity.valueOf(), regexp.ignoreCase)에 대해 생성자 (예 : Object, Date, Number, RegExp) 및 CamelCase에 InitialCaps를 사용합니다. 이 규칙은 DOM 사양 및 구현 (예 : HTMLElement.setAttribute())에서도 제공됩니다. 그래서 같은 규칙을 채택하기에 가장 적합한하거나 같은 스타일의 끔찍한 뒤범벅으로 마무리 : 읽기, 단지뿐만 아니라 훨씬 더 중요한 것은, 입력하되, 완전히 혼란하게
var number_of_fish_requested = document.getElementById("fish").value;
var fish_count = parseInt(number_of_fish_requested, 10);
. 밑줄 분리와
(. 당신이 이제까지 먼저 그것을 기록 할보다 당신이 그것을 디버깅하려고하거나 수정, 코드를 읽고 더 많은 시간을 보내고)
큰 설명 주셔서 감사합니다! –
모든 소문자 읽기 쉬운이다; 그것은 자연 언어를 따른다. "최고"는 거룩한 전쟁으로 인도 할 것입니다. 현실은 다른 디자인 문제만큼 중요하지 않지만 극성 화는 쉬운 주제입니다.
ALongButNotReallyReadableIdentifier
an_even_longer_but_completely_readable_identifier
그러나 '가장 쉬운'은 특히 거룩한 전쟁을 피하지 않습니다. * I * 파스칼과 낙타의 경우는 언더 스코어보다 읽기 쉽다. * 당신이 말하는 것은 '가장 쉬운'것이다. 이제 누가 옳은가? – AakashM
당신은 저를 "틀린"것으로 증명할 방법이 없습니다. 뇌가 어떻게 분열 하는지를 연구하는 대부분의 사람들은 뇌가 문장을 공간으로 분리 된 단어로 나눌 것이라고 관찰합니다. 두뇌는 각 단어의 처음과 마지막 문자, 단어의 대략적인 길이에 패턴 인식을 수행하고 의미를 유도하기 위해 컨텍스트를 적용합니다. 사실, 다른 유형의 스크립트를 읽도록 가르 칠 수 있지만 표준 영어에서 벗어나는 좋은 이유가 있어야합니다. – clemahieu
귀하의 예는 흥미 롭습니다. AnEvenLongerButCompletelyReadableIdentifier는 처음에 두 개의 대문자가 서로 붙어 있지 않기 때문에 정상적으로 작동합니다. –
허용되는 대답은 사실이지만 몇 가지 예외가 있습니다. window.JSON 및 window.XMLHttpRequest에서 용어는 대문자입니다.
또한 대부분의 사람들은 Javascript에서 열거 형 객체에 PascalCase를 사용하고 그 안에 대문자로 된 값을 사용합니다. 때로는 네임 스페이스가 PascalCase에서도 수행됩니다.
예 : MyCompany.Web.UI.MyComponent.ThemeOption = {BLACK : 0,은 1, BLUE 2}
I는 본 것을XML과 JSON은 약자입니다. – HerrSerker
지금까지 케이싱 표준 매우 큰 다이버 시티이다.
필자는 JavaScript 코드 작성을 위해 C# 스타일링을 사용합니다. 저는 클래스를 많이 사용합니다 (클래스로서의 기능은 물론 독립적 인 함수가 없습니다). 그래서 클래스 이름, 공용 메소드, 속성 및 모든 전역 변수와 인수, 로컬 변수 및 개인 함수에 대한 camelCase에 PascalCase를 사용합니다. 이것은 어떻게 든 내 공통 환경을 반영하여 변수 범위를 구별하는 데 도움이됩니다. 또한 클래스 이름 (ClassName.js, ClassName.min.js)과 동일한 이름의 별도 파일에 클래스 기능을 유지하는 경향이 있습니다.
이것은 제 접근 방법입니다.
Ruby on Rails 프로그래머는 underscore_separated_var_name과 같은 고유 한 명명 표준을 따릅니다. Java 프로그래머는 Java 규칙을 따르며 작성 스타일은 Java 언어와 비슷합니다.
앞서 언급했듯이 저자가 Linux/오픈 소스 커뮤니티 및 Microsoft 개발자 (jQuery, knockout.js, JSJaC 등)와 같은 다른 커뮤니티에서 온 매우 유명한 프레임 워크에서 pascalCase를 많이 사용하는 경향이 있습니다. .)
JS와 관련하여 이러한 방법이 잘못되었거나 올바르지 않습니다. 명명 규칙 및 파일 구조화의 주요 목적은 가독성입니다. 당신이 일관성이 있다면 미래에 당신과 동료 개발자는 당신의 코드를 빨리 이해하고 나아갈 것입니다.
대다수의 대문자와 소문자가 구별되지 않는 OS XD가 있다면 어떨까요? – theonlygusti