21
21
6 . [ 테스트(Testing)] ( #테스트testing )
22
22
7 . [ 동시성(Concurrency)] ( #동시성concurrency )
23
23
8 . [ 에러 처리(Error Handling)] ( #에러-처리error-Handling )
24
- 9 . [ 포멧팅 (Formatting)] ( #포멧팅formatting )
24
+ 9 . [ 포맷팅 (Formatting)] ( #포맷팅formatting )
25
25
10 . [ 주석(Comments)] ( #주석comments )
26
26
27
27
## 소개(Introduction)
@@ -170,7 +170,7 @@ function paintCar(car) {
170
170
```
171
171
** [ ⬆ 상단으로] ( #목차 ) **
172
172
173
- ### short-circuit 트릭이 조건문 보다 깔끔합니다
173
+ ### short circuiting 트릭이 조건문 보다 깔끔합니다
174
174
175
175
** 안좋은 예:**
176
176
``` javascript
@@ -554,7 +554,7 @@ console.log(newName); // ['Ryan', 'McDermott'];
554
554
### 전역 함수를 사용하지 마세요
555
555
전역 환경을 사용하는 것은 Javascript에서 나쁜 관행입니다. 왜냐하면 다른 라이브러리들과의 충돌이 일어날 수 있고,
556
556
당신의 API를 쓰는 유저들은 예외를 발견할 때까지 그것을 이해하지 못 할 것입니다. 예제를 하나 생각해봅시다.
557
- JavaScript의 네이티브 Array 메서드를 확장하여 두 배열 간의 차이를 보여줄 수있는 ` diff` 메서드를 사용하려면 어떻게해야할까요?
557
+ JavaScript의 네이티브 Array 메소드를 확장하여 두 배열 간의 차이를 보여줄 수있는 ` diff` 메소드를 사용하려면 어떻게해야할까요?
558
558
새로운 함수를 ` Array .prototype ` 에 쓸 수도 있지만, 똑같은 일을 시도한 다른 라이브러리와 충돌 할 수 있습니다.
559
559
다른 라이브러리가 ` diff` 메소드를 사용하여 첫번째 요소와 마지막 요소의 차이점을 찾으면 어떻게 될까요?
560
560
이것이 단순히 ES2015/ES6의 classes를 사용하여 전역 ` Array ` 를 확장하는 것이 좋은 이유입니다.
@@ -680,7 +680,7 @@ if (shouldShowSpinner(fsmInstance, listNodeInstance)) {
680
680
` ` `
681
681
**[⬆ 상단으로](#목차)**
682
682
683
- ### 조건문의 조건을 부정적인 의미로 사용하지 마세요
683
+ ### 부정조건문을 사용하지 마세요
684
684
685
685
**안좋은 예:**
686
686
` ` ` javascript
@@ -809,7 +809,7 @@ function combine(val1, val2) {
809
809
` ` `
810
810
**[⬆ 상단으로](#목차)**
811
811
812
- ### 과도하게 최적화 하지 마세요
812
+ ### 과도한 최적화를 지양하세요
813
813
최신 브라우저들은 런타임에 많은 최적화 작업을 수행합니다. 대부분 당신이 코드를 최적화 하는 것은 시간낭비일 가능성이 많습니다.
814
814
최적화가 부족한 곳이 어딘지를 알려주는 [좋은 자료](https://github.com/petkaantonov/bluebird/wiki/Optimization-killers)가 여기 있습니다.
815
815
이것을 참조하여 최신 브라우저들이 최적화 해주지 않는 부분만 최적화를 해주는 것이 좋습니다.
@@ -1254,7 +1254,7 @@ const $ = new DOMTraverser({
1254
1254
` ` `
1255
1255
**[⬆ 상단으로](#목차)**
1256
1256
1257
- ### 의존 관계 역전 원칙 (DIP)
1257
+ ### 의존성 역전 원칙 (DIP)
1258
1258
이 원칙은 두가지 중요한 요소를 가지고 있습니다.
1259
1259
1260
1260
1. 상위 모듈은 하위 모듈에 종속되어서는 안됩니다. 둘 다 추상화에 의존해야 합니다.
@@ -1775,7 +1775,7 @@ getdata()
1775
1775
1776
1776
**[⬆ 상단으로](#목차)**
1777
1777
1778
- ## **포멧팅 (Formatting)**
1778
+ ## **포맷팅 (Formatting)**
1779
1779
포맷팅은 주관적입니다. 여기에있는 많은 규칙과 마찬가지로 따르기 쉬운 규칙들이 있습니다.
1780
1780
여기서 알아야 할 것은 포맷팅에대해 과도하게 신경쓰는 것은 의미없다는 것입니다.
1781
1781
포맷팅 체크를 자동으로 해주는 [많은 도구들](http://standardjs.com/rules.html)이 있기 때문입니다.
@@ -1965,7 +1965,7 @@ doStuff();
1965
1965
` ` `
1966
1966
**[⬆ 상단으로](#목차)**
1967
1967
1968
- ### 코드의 기록에대해 주석으로 남기지 마세요
1968
+ ### 코드 기록을 주석으로 남기지 마세요
1969
1969
버전 관리 도구를 이용해야하는 것을 꼭 기억하세요. 죽은 코드도 불필요한 설명도 특히 코드의 기록에대한 주석도
1970
1970
필요하지 않습니다. 코드의 기록에대해 보고 싶다면 ` git log` 를 사용하세요!
1971
1971
@@ -1991,7 +1991,7 @@ function combine(a, b) {
1991
1991
**[⬆ 상단으로](#목차)**
1992
1992
1993
1993
### 코드의 위치를 설명하지 마세요
1994
- 이건 정말 쓸 때 없습니다. 적절한 들여쓰기와 포맷팅을 하고 함수와 변수의 이름에 의미를 부여하세요.
1994
+ 이건 정말 쓸데 없습니다. 적절한 들여쓰기와 포맷팅을 하고 함수와 변수의 이름에 의미를 부여하세요.
1995
1995
1996
1996
**안좋은 예:**
1997
1997
` ` ` javascript
0 commit comments