최근 자바 스크립트에서 세미콜론을 제거 / 제거하는 방법으로 전환 한 이유는 무엇입니까?

최근 자바 스크립트에서 세미콜론을 생략하는 것이 유행 인 것 같습니다. 몇 년 전 자바 스크립트에서 세미콜론은 선택 사항 이며 글의 요점은 불필요하기 때문에 귀찮게해서는 안되는 것처럼 보이는 블로그 게시물 이있었습니다 . 널리 인용 된이 포스트는 그것들을 사용 하지 않는 강력한 이유를 주지 않고 단지 부작용이 거의 없다고 말합니다.

GitHub 조차도 내부적으로 개발 된 코드에서 누락이 필요한 비 세미콜론 악 대차에 뛰어 들었고 , 최근 관리자가 zepto.js 프로젝트에 대한 커밋 을 통해 코드베이스에서 모든 세미콜론이 제거되었습니다. 그의 주요 정당화는 다음과 같습니다.

• 그의 팀이 선호하는 문제입니다.
• 덜 타이핑

제외해야 할 다른 이유가 있습니까?

솔직히 말해서 그것들을 생략 할 이유가 없으며 분명히 코드를 다시 지우지 않아도됩니다. 또한 ( 수년간의 ) 권장 연습 에 어긋납니다. 나는 실제로 "카고 컬트"에 대한 주장을 사지 않습니다. 그렇다면 왜 최근의 모든 세미콜론 증오? 부족한 것이 있습니까? 아니면 이것이 최신 자바 스크립트 유행일까요?

내 이유가 가장 늦다 고 생각합니다. 너무 많은 언어로 동시에 프로그래밍합니다 (Java, Javascript, PHP)- ';' 내 손가락과 눈을 훈련시키기보다는 ';' 자바 스크립트에는 필요하지 않으며 항상 ';'

다른 이유는 문서화입니다 : ';' 나는 진술이 끝날 것으로 예상되는 곳을 나 자신에게 분명히 진술하고있다. 그런 다음 다시 {}을 사용합니다.

전체 바이트 수 인수는 짜증나고 무의미합니다.

1) jquery와 같은 일반적인 라이브러리의 경우 : Google CDN을 사용하면 라이브러리가 이미 브라우저 캐시에있을 것입니다

2) 자신의 라이브러리를 버전 화하고 영원히 캐시되도록 설정하십시오.

3) 정말 필요한 경우 gzip을 사용하여 최소화하십시오.

그러나 실제로 자바 스크립트의 다운로드 속도가 가장 큰 속도 병목 현상을 일으키는 사이트는 몇 개입니까? 트위터, 구글, 야후 등과 같은 100 대 사이트에서 일한다면 아마도. 우리 중 나머지는 세미콜론 종교 전쟁이 아닌 코드 품질에 대해 걱정해야합니다.

메소드 체인을 쉽게하고 커밋 차이를 더 깨끗하게 만듭니다.

jQuerying에 대해 가지고 있다고 가정 해 봅시다.

$('some fancy selector')
  .addClass()
  .attr();

물건을 추가 하고 라인 기반 커밋 차이를 작게 유지하려면 attr 위에 추가해야합니다. 따라서 "끝에 추가"보다 더 오래 생각했습니다. 누가 생각하고 싶어? =)

$('some fancy selector')
  .addClass()
  // new method calls must go here
  .attr();

하지만 세미콜론을 떨어 뜨릴 때 하루 만 추가하면됩니다

  $('some fancy selector')
    .addClass()
    .attr()
+   .animate()
+   .click()

또한 마지막 방법을 사용하기로 결정한 경우 세미콜론을 다시 할당하고 커밋을 다시 오염시킬 필요가 없습니다.

  $('some fancy selector')
    .addClass()
    .attr()
    .animate()
-   .click()

구고와 비교

  $('some fancy selector')
    .addClass()
    .attr()
+   .animate();
-   .animate()
-   .click();

JavaScript의 세미콜론은 선택 사항입니다

세미콜론을 사용하지 않는 개인적인 이유는 OCD입니다.

세미콜론을 사용할 때 2 %를 잊어 버리고 끊임없이 다시 체크인 / 추가해야합니다.

세미콜론을 사용하지 않을 때 실수로 실수로 콜론을 넣지 않았으므로 확인하거나 제거 할 필요가 없습니다.

나는 최근 JavaScript를위한 파서 / 분석기를 작성했는데, 여기서 ASI를 힘들게 구현해야했고 , 항상 세미콜론을 사용 하도록 옹호하는 Crockford의 JavaScript : 나의 책장에있는 좋은 부분 도 가지고있다 . 의도는 좋았지 만 실제로 도움이되는 것은 아닙니다.

분명히 jQuery, zepto 등과 같은 프레임 워크를 작성하는 사람들은 JavaScript 구문 마스터이므로 다음과 같은 차이점을 알고 있습니다.

return
{
    status: true
};

과

return {
    status: true
};

JavaScript는 강력하지만 초급 언어 이며 for루프가 무엇인지 배우는 사람에게 이것을 설명하는 행운을 빕니다 . 대부분의 사람들에게 새로운 기술을 소개하는 것과 같이, 당신이 바로 설명하고 싶지 않은 더 복잡한 것들이 있기 때문에, 대신에 특정 것들에 대해 "화물 숭배"신념을 심어 놓으면됩니다. 따라서 초보자에게 JavaScript 작성 방법을 가르 칠 때 두 가지 선택이 있습니다.

1. 그들에게 "이 규칙 하나를 따르고 왜 그런지 묻지 말라고" 모든 줄 끝에 항상 세미콜론 을 넣으라고합니다 . 불행히도 이것은 위의 예 또는 ASI가 방해가되는 다른 예에서는 도움이되지 않습니다. 그리고 위의 코드가 실패하면 Mr. 또는 Ms. 초보자 프로그래머가 혼란에 빠지게됩니다.
2. 그들에게 "이 두 가지 규칙을 따라야 왜 물어 보지 않는다"모든 라인의 끝에 세미콜론 귀찮게하지 말라고 말하고, 대신에에게 항상 A)에 따라 return로모그래퍼 {및 b)는 라인이 시작되면 (, 앞에 추가 와 함께 ;.

옵션 2를 선택하는 것이 더 나은 "화물 컬트"규칙 세트이며 (ASI 관련 버그가 거의 발생하지 않음) 주제를 깊이 이해하더라도 화면에 불필요한 문자가 줄어 듭니다.

정보 과부하와 같은 것은 없으며 나쁜 디자인 만 있습니다.

— 에드워드 툭테

노이즈를 줄이기 위해 불필요한 요소와 장식을 생략하는 것이 그래픽 디자인 의 일반적인 규칙입니다 .

화면에 시각적 요소가 적을수록 뇌가 실제 유용한 정보를 파싱하는 작업이 줄어 듭니다.

let foo = 1

vs.

let /* variable */ foo = 1; // EOL

물론 과장된 예이지만 일반적인 원칙을 보여줍니다. 추가 시각적 요소는 목적에 부합하는 경우에만 추가되어야합니다. 세미콜론이 목적을 달성합니까?

JavaScript에서 세미콜론을 사용해야하는 역사적 이유는 다음과 같습니다.

• C / Java와 유사성을 유지
• 잘못 작성된 브라우저 및 도구와의 호환성 문제 방지
• 사람과 기계가 코드 오류를 감지하도록 지원
• 자동 세미콜론 삽입으로 성능이 저하됩니다

호환성 문제는 오늘날 거의 문제가되지 않습니다. 현대 린터은 코드 오류를 감지 할 수 있습니다 단지뿐만 아니라 세미콜론없이. C / Java / PHP와의 유사성은 여전히 ​​고려할 수 있습니다 ( Pat 의 승인 된 답변 참조 ). 다른 언어에 불필요한 구문 요소가 포함되어 있다고해서 반드시 다른 언어 (Coffeescript, Python, Ruby, Scala, Lua)는 필요하지 않습니다.

V8에 성능 저하가 있는지 확인하기 위해 빠른 테스트를 수행했습니다. 이것은 세미콜론으로 세미콜론을 제거한 다음 41MB JavaScript 파일 (Lodash를 100 번 반복)을 구문 분석하는 Io.js입니다.

$ time node lodashx100.js
node lodashx100.js  2.34s user 1.30s system 99% cpu 3.664 total
$ time node lodashx100s.js
node lodashx100s.js  2.34s user 1.15s system 99% cpu 3.521 total

누구나 자신의 프로젝트에 대해 선호하는 코딩 스타일을 결정해야하지만 더 이상 세미콜론을 사용하는 데 따른 실질적인 이점이 없으므로 시각적 소음을 줄이기 위해 중단했습니다.

프로그래밍 규칙을 선택하는 것은 대상 언어의 하위 집합을 선택하는 것과 사실상 동일합니다. 코드 가독성, 유지 관리 성, 안정성, 이식성 등의 일반적인 이유 때문에 유연성을 희생 할 수 있습니다. 이러한 이유는 실제 비즈니스 이유입니다.

"키 스트로크 저장"및 "프로그래머가 JavaScript 규칙을 배워야합니다"와 같은 이유는 거의 비즈니스상의 이유가 아니므로 실질적인 무게는 거의 없습니다.

필자의 경우 JavaScript에서 매우 빠르게 속도를 내야했기 때문에 언어의 제한된 하위 집합을 활용하는 것이 유리했습니다. 그래서 JavaScript의 JSLint 하위 세트를 선택하고 Eclipse의 Rockstar 앱 JSLinter를 내가 할 수있는 가장 제한적인 설정으로 설정했지만 되돌아 보지 않았습니다.

"=="와 "==="의 차이점이나 세미콜론 삽입의 세부 사항을 피할 수있어서 기쁩니다. 이미 마일이 많은 작업 목록이 있고 세부 사항이 없기 때문입니다. 일을 빨리 끝내도록 도와주세요.

물론 컨벤션에서 가장 중요한 것은 일관성이며 언어 하위 집합으로 생각하면이 명령을 강화하는 데 도움이됩니다. 이것이 OP의 질문에 대답하는 데 도움이되지는 않지만 실용적인 프레임에 도움이 될 것이라고 생각합니다.

꽤 오래된 질문이지만 아무도 언급하지 않은 것에 놀랐습니다.

축소 : 세미콜론 문자로 명령문을 명시 적으로 종료하지 않는 JavaScript 스 니펫을 축소하면 축소하기 전에 작동했던 스 니펫의 문제점을 파악하기가 어려울 수 있습니다. 지금은 작동하지 않습니다.

모호성 : 세미콜론은 선택 사항이지만 사실은 소스 코드에서 제거하여 모호한 시나리오를 파서가 결정하여 자체적으로 결정할 수 있습니다. 온라인 상점을 위해 100 줄의 코드를 작성하는 경우에는 문제가되지 않지만보다 심각한 작업에는 100 % 선명도가 필요합니다.

오래 전에 나는 다른 것에 대해 아주 좋은 비유를 읽었지만이 경우에도 마찬가지입니다. 결국 괜찮을 수도 있고 트럭에 맞을 수도 있습니다.

요즘 왜 인기가 높아지고 있습니까?

개인적으로 서버 측에서 JavaScript를 실행하면 JavaScript 커뮤니티 자체에 많은 영향을 미쳤다고 생각합니다. 우리의 경우 서버 측에서 JavaScript를 축소 할 사람이 아무도 없습니다 (소스 코드가 클라이언트의 웹 브라우저에 제공되지 않기 때문에). 그러나이 책, 기사 및 비디오에서 배우는 다른 개발자들은 불행히도 서버 측의 JavaScript가 클라이언트 측의 JavaScript와 정확히 동일하지 않다는 사실을 무시합니다.

그것들을 보관해야 할 좋은 이유가 있습니다.

그것들은 실제로 선택 사항이 아니며 JS는 누락 될 때 자동 세미콜론 삽입으로 다시 추가 할 수 있지만 같은 것은 아닙니다.

Douglas Crockford의 JavaScript : The Good Parts는 두 가지 경우에 대해 나쁜 생각이라고 말합니다. 자동 세미콜론 삽입은 프로그램의 버그를 숨기고 모호성을 만듭니다.

JSLint가 승인되지 않습니다.

자바 스크립트는 10 년 이상 문장을 끝내기 위해 세미콜론이 필요하지 않았습니다. 줄 바꿈 문자는 문장 종결 자로 간주되기 때문입니다 (이는 ECMAScript 초기 사양에서도 언급되어 있다고 생각합니다). 자바 스크립트가 세미콜론을 자주 사용해야하지만 루비 나 파이썬과 같은 다른 해석 가능한 선언적 언어는 필요하지 않은 이유가 없기 때문에 정말 의미가 있습니다.

세미콜론을 요구하면 언어에 대한 파서를 작성하는 것이 더 쉬워 질 수 있지만, 모든 인터프리터가 세미콜론 생략을 지원하면 정확히 무엇입니까?

프로그래머가 얼마나 지식이 많은가에 따라 달라집니다. 세미콜론을 생략 할 수 있다는 것을 알고 있다면 결과가있을 수도 있고 없을 수도 있다는 것을 자유롭게 이해하십시오. 인간은 의사 결정 기계이며 거의 모든 결정에는 타협이나 절충이 필요합니다. 코드 주위에 세미콜론을 던지는 것의 단점은 (필요하지 않은 곳에서도) 코드를 읽을 수 없게되고 (요청한 사람에 따라 다름) JSLint가 불만을 제기하지 않는다는 것입니다 ). 다른 한편으로 세미콜론을 생략하는 것의 단점은 JavaScript 프로그래머의 90 %가 당신을 쫓아 갈 것이라는 사실이지만, 그 때문에 자바 스크립트 작성을 더 좋아하게 될 수도 있습니다.

당신에게 더 나은 소리; 정보에 입각 한 의사 결정 또는 맹목적인 의사 결정 / 군집?

두 가지 이론이 있습니다.

에이)

이 선택에 대한 것은 JSLint 등이 적용 가능했던 당시, 모호한 구문 오류를 잡기 위해 많은 시간을 소비하거나 코드에 대한 표준 정책을 시행하기 위해 합리적인 시간을 소비하기로 선택했다는 것입니다.

그러나 단위 테스트 중심의 코드와 지속적인 통합으로 나아가 면서 구문 오류를 포착하는 데 필요한 시간 (및 사람의 상호 작용)이 크게 줄었습니다. 테스트의 피드백은 코드가 최종 사용자 근처에 오기 훨씬 전에 코드가 예상대로 작동하는지 여부를 신속하게 나타냅니다.

비)

게으른 프로그래머는 자신의 삶을 단기간에 편하게하기 위해 무엇이든 할 것입니다. 타이핑이 적고 노력이 적고 쉬워집니다. (또한 세미콜론을 사용하지 않아도 RSIness를 피하면서 오른쪽 링 핑거를 변형시키지 않아도됩니다).

(NB 는 진술 을 모호하게 하는 것을 생략한다는 아이디어에 동의하지 않습니다 ).

나는 그것들을 남기지 않지만 삽입 할 때 규칙을 변경합니다.

대부분의 사람들이 사용하는 규칙은

• 각 줄이 끝나기 전에
• 행이 }함수 명령문에서 오는 것을 제외하고
• 그러나 함수 리터럴에는 할당되지 않은 함수 명령문 만

나의 규칙은 : 여는 괄호 / 브래킷으로 시작하는 모든 한 줄의 시작 부분에.

광산은 더 간단하고 따라 가기 쉽고 버그가 적습니다. 또한 세미콜론 수가 적 으면 버그를 남기지 않고 쉽게 버그를 찾을 수 있습니다.

또 다른 주장은 악명 높은 return\nvalue버그가 ASI에 대해 알지 못한다는 것입니다. 내 규칙에 따라 ASI에 대해 알게되므로 내 규칙을 사용하는 사람들이 해당 버그의 함정에 빠질 가능성이 줄어 듭니다.

바이트 수 알다시피 악의적 인 사람들은 대개 한 줄의 코드에 너무 많이 들어 가려고합니다. 기술적으로 말하자면 세미콜론이 없으면 불가능합니다. 내 생각에 그것은 단지 프로그래밍 방식의 요구 사항보다 보안 수단에 가깝다는 것입니다. 어쨌든 이것은 제안이 아닌 요구 사항이 될 때 XSS를 크게 줄입니다.