diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md index 926a772c6b..f96858f6fb 100644 --- a/1-js/03-code-quality/02-coding-style/article.md +++ b/1-js/03-code-quality/02-coding-style/article.md @@ -1,12 +1,12 @@ -# Coding Style +# 코딩 스타일 -Our code must be as clean and easy to read as possible. +코드는 깨끗하고 읽기 쉽게 작성하는 것이 실질적으로 프로그래밍의 기술입니다. -That is actually the art of programming -- to take a complex task and code it in a way that is both correct and human-readable. +복잡한 작업을 수행하고 사람이 읽을 수 있는 방식으로 코드를 작성합니다. -## Syntax +## 문법 -Here is a cheatsheet with some suggested rules (see below for more details): +다음은 몇 가지 규칙이 제안된 요약한 치트시트입니다. (아래에 자세한 내용 참조) ![](code-style.png) -Now let's discuss the rules and reasons for them in detail. +위의 치트 시트에 기재된 규칙과 세세한 내용을 설명하겠습니다. ```warn header="Irony Detected" -Nothing is set in stone here. These are style preferences, not religious dogmas. +꼭 해야만 하는 정해진 규칙이 아닙니다. ``` -### Curly Braces +### 중괄호 -In most JavaScript projects curly braces are written in "Egyptian" style with the opening brace on the same line as the corresponding keyword -- not on a new line. There should also be a space before the opening bracket, like this: +대부분의 자바스크립트 프로젝트에서 중괄호는 "Egyptian" 스타일입니다. "Egyptian" 스타일은 새로운 키워드가 아닌 해당 키워드와 같은 행에 여는 중괄호로 작성되는 것입니다. 아래의 예시 코드에서 처럼 여는 중괄호 앞에는 공백 한 칸이 있어야 합니다. + +예시 : ```js if (condition) { @@ -52,10 +54,9 @@ if (condition) { } ``` -A single-line construct is an important edge case. Should we use brackets at all? If yes, then where? - -Here are the annotated variants so you can judge their readability for yourself: +단일 행 구조는 에지 케이스에서 중요합니다. 그렇다면 대괄호를 사용해야할까요? 그렇다면 어디에 대괄호를 사용할까요? +다음은 주석이 달린 코드 입니다. 코드를 보면 가독성을 판단할 수 있습니다. ![](figure-bracket-style.png) -In summary: -- For very short code, one line is acceptable. For example: `if (cond) return null`. -- But a separate line for each statement in brackets is usually easier to read. +요약 : -### Line Length +- 짧은 코드 작성을 위해서 한 행은 허용합니다. ex) `if (cond) return null`. +- 그러나 작성한 구문을 중괄호를 사용하여 행을 구분한 코드는 읽기 쉽습니다. -No one likes to read a long horizontal line of code. It's best practice to split them up and limit the length of your lines. +### 행 길이 -The maximum line length should be agreed upon at the team-level. It's usually 80 or 120 characters. +가로로 긴 행의 코드를 읽는 것은 힘듭니다. 행을 분리하고 행의 길이를 제한하는 것이 가장 좋습니다. -### Indents +최대 행의 길이는 팀 내에서 합의 해야 합니다. 일반적으로 80에서 120자입니다. -There are two types of indents: +### 들여쓰기 -- **Horizontal indents: 2 or 4 spaces.** +2가지 타입의 들여쓰기가 있습니다. - A horizontal indentation is made using either 2 or 4 spaces or the "Tab" symbol. Which one to choose is an old holy war. Spaces are more common nowadays. +- **가로 들여쓰기 : 2칸 또는 4칸의 공백** + 가로 들여쓰기는 2칸 또는 4칸의 공백을 사용하거나 "Tab"으로 적용합니다. 2칸 또는 4칸의 공백을 사용할지 "Tab"을 적용할지에 대한 논쟁은 오랫동안 이뤄져 왔습니다. 요즘은 공백을 좀 더 많이 사용하고 있습니다. - One advantage of spaces over tabs is that spaces allow more flexible configurations of indents than the "Tab" symbol. + 공백이 "Tab"보다 유연한 구성을 허용한다는 한 가지 장점이 있습니다. - For instance, we can align the arguments with the opening bracket, like this: + 예를 들어, 중괄호를 열 때 아래의 예시 코드처럼 인자를 정렬할 수 있습니다. ```js no-beautify show(parameters, - aligned, // 5 spaces padding at the left + aligned, // 왼쪽에서 5칸 공백 one, after, another @@ -105,9 +106,10 @@ There are two types of indents: } ``` -- **Vertical indents: empty lines for splitting code into logical blocks.** +- **세로 들여쓰기 : 로직이 있는 블록 사이를 나눌 때 빈 행** - Even a single function can often be divided into logical blocks. In the example below, the initialization of variables, the main loop and returning the result are split vertically: + 단일 함수에서 자주 로직 블록으로 나눌 수 있습니다. + 아래의 예시 코드에서 변수의 초기화, 메인 반복문 그리고 결과를 반환하는 부분에서 세로로 구분할 수 있습니다. ```js function pow(x, n) { @@ -120,24 +122,23 @@ There are two types of indents: return result; } ``` + 새로운 행을 추가하면 읽기 쉬운 코드를 작성할 수 있습니다. 세로로 들여쓰기가 없는 코드는 9줄을 초과해서는 안됩니다. - Insert an extra newline where it helps to make the code more readable. There should not be more than nine lines of code without a vertical indentation. +### 세미콜론 -### Semicolons +세미콜론은 구문을 건너띌 수 있는 경우에도 각각 구문 다음에 있어야 합니다. -A semicolon should be present after each statement, even if it could possibly be skipped. +세미콜론이 실제로 선택사항이고, 거의 사용하지 않는 언어도 있습니다. 자바스크립트에서는 줄 바꿈이 세미콜론으로 해석되지 않아 오류에 취약한 경우가 있습니다. -There are languages where a semicolon is truly optional and it is rarely used. In JavaScript, though, there are cases where a line break is not interpreted as a semicolon, leaving the code vulnerable to errors. +프로그래머로서 더욱 성장하게 되면 [StandardJS](https://standardjs.com/)처럼 세미콜론을 작성하지 않는 스타일을 선택할 수 있습니다. 그렇게 될 때까지 함정에 빠지지 않기 위해서 세미콜론을 사용하는 것이 좋습니다. -As you become more mature as a programmer, you may choose a no-semicolon style like [StandardJS](https://standardjs.com/). Until then, it's best to use semicolons to avoid possible pitfalls. +### 중첩 레벨 -### Nesting Levels +깊이 있는 코드들을 너무 많은 중첩하여 작성하지 마세요. -Try to avoid nesting code too many levels deep. +반복문에서 추가적인 중첩을 피해기 위해 ["continue"](info:while-for#continue)지시자를 사용하는 것이 좋습니다. -Sometimes it's a good idea to use the ["continue"](info:while-for#continue) directive in a loop to avoid extra nesting. - -For example, instead of adding a nested `if` conditional like this: +예를 들면 아래의 코드처럼 중첩된 `if` 조건문을 사용하는 것 대신 ```js for (let i = 0; i < 10; i++) { @@ -146,8 +147,7 @@ for (let i = 0; i < 10; i++) { } } ``` - -We can write: +아래의 코드를 사용할 수 있습니다. ```js for (let i = 0; i < 10; i++) { @@ -155,12 +155,11 @@ for (let i = 0; i < 10; i++) { ... // <- no extra nesting level } ``` +이와 마찬가지로 `if/else`와 `return`을 사용하여 중첩을 피할 수 있습니다. -A similar thing can be done with `if/else` and `return`. +예를 들어, 아래의 2가지 구조는 동일합니다. -For example, two constructs below are identical. - -Option 1: +선택사항 1: ```js function pow(x, n) { @@ -178,7 +177,7 @@ function pow(x, n) { } ``` -Option 2: +선택사항 2: ```js function pow(x, n) { @@ -197,13 +196,13 @@ function pow(x, n) { } ``` -The second one is more readable because the "edge case" of `n < 0` is handled early on. Once the check is done we can move on to the "main" code flow without the need for additional nesting. +선택사항 2가 더 읽기 쉽습니다. 왜냐하면 에지 케이스에서 `n < 0`이 초기에 처리되기 때문입니다. 검사가 끝나면 추가 중첩을 하지 않고도 "main" 코드로 이동할 수 있습니다. -## Function Placement +## 함수 배치 -If you are writing several "helper" functions and the code that uses them, there are three ways to organize the functions. +만약 "헬퍼" 함수와 이를 사용하는 코드를 작성한다면, 3가지 방법으로 함수를 구성할 수 있습니다. -1. Functions declared above the code that uses them: +1. 아래의 코드 처럼 함수를 사용하는 코드 위에 선언합니다. ```js // *!*function declarations*/!* @@ -224,7 +223,8 @@ If you are writing several "helper" functions and the code that uses them, there setHandler(elem); walkAround(); ``` -2. Code first, then functions + +2. 사용하는 코드가 먼저, 그다음 함수를 선언합니다. ```js // *!*the code which uses the functions*/!* @@ -245,54 +245,55 @@ If you are writing several "helper" functions and the code that uses them, there ... } ``` -3. Mixed: a function is declared where it's first used. -Most of time, the second variant is preferred. +3. 1,2 둘 다 섞습니다. 함수는 처음 사용된 곳에 선언됩니다. -That's because when reading code, we first want to know *what it does*. If the code goes first, then it provides that information. Then, maybe we won't need to read the functions at all, especially if their names are descriptive of what they actually do. +대부분의 경우 두번째 방법을 많이 선호합니다. -## Style Guides +왜냐하면 코드를 읽을 때, 먼저 코드가 무엇인지 알고 싶어하기 때문입니다. 만약 코드가 먼저 선언이 된다면, 해당 정보가 제공됩니다. 그러고 나면 함수를 읽을 필요는 없습니다. 그래서 함수 이름이 무엇을 하는지 알 수 있어야 합니다. -A style guide contains general rules about "how to write" code, e.g. which quotes to use, how many spaces to indent, where to put line breaks, etc. A lot of minor things. +## 스타일 가이드 -When all members of a team use the same style guide, the code looks uniform, regardless of which team member wrote it. +스타일 가이드는 "작성하는 방법"에 대해 '사용할 따옴표', '들여쓰기의 공백', '줄바꿈을 넣을 위치'와 같은 일반적인 규칙을 포함하고 있어야 합니다. 사소하게 포함해야할 규칙들이 많습니다. -Of course, a team can always write their own style guide. Most of the time though, there's no need to. There are many existing tried and true options to choose from, so adopting one of these is usually your best bet. +팀의 모든 구성원이 동일한 스타일 가이드를 사용하면 팀원이 개별적으로 작성한 코드와 관계없이 코드가 동일하게 보입니다. -Some popular choices: +물론 팀은 항상 자신의 스타일 가이드를 작성할 수 있습니다. 대부분의 경우, 필요가 없습니다. 왜냐하면 잘 만들어 놓아진 스타일 가이드들이 존재하여 선택해서 사용할 수 있는 스타일 가이드들이 많습니다. 가장 잘된 것들을 하나 채택하여 사용하면 됩니다. + +유명한 스타일들 : - [Google JavaScript Style Guide](https://google.github.io/styleguide/javascriptguide.xml) - [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript) - [Idiomatic.JS](https://github.com/rwaldron/idiomatic.js) - [StandardJS](https://standardjs.com/) -- (plus many more) +- 등등 -If you're a novice developer, start with the cheatsheet at the beginning of this chapter. Once you've mastered that you can browse other style guides to pick up common principles and decide which one you like best. +초보자인 경우 이 장의 첫 번째에 있는 치트시트부터 시작하세요. 일단 마스터하면 다른 스타일 가이드들을 찾아서 일반적인 원칙들을 선택하고, 어떤 스타일이 좋은지 결정할 수 있습니다. -## Automated Linters +## 자동화된 린트 -Linters are tools that can automatically check the style of your code and make suggestions for refactoring. +린트는 코드의 스타일을 자동으로 체크하고, 정의한 코드 스타일대로 리팩토링해줍니다. -The great thing about them is that style-checking can also find some bugs, like typos in variable or function names. Because of this feature, installing a linter is recommended even if you don't want to stick to one particular "code style". +린트의 가장 우수한 부분은 변수 또는 함수의 이름의 오류와 버그를 찾아내는 것입니다. 왜냐하면 이 기능으로 인해 특정 "코드 스타일"을 고집하지 않으려해도 린트 설치가 권장됩니다. -Here are the most well-known linting tools: +가장 잘 알려진 린트 툴들: -- [JSLint](http://www.jslint.com/) -- one of the first linters. -- [JSHint](http://www.jshint.com/) -- more settings than JSLint. -- [ESLint](http://eslint.org/) -- probably the newest one. +- [JSLint](http://www.jslint.com/) -- 린트들 중 가장 많이 사용 +- [JSHint](http://www.jshint.com/) -- JSLint 보다 더 많은 환경 세팅 가능 +- [ESLint](http://eslint.org/) -- 아마 린트들 중 가장 최신 -All of them can do the job. The author uses [ESLint](http://eslint.org/). +이 린트툴들은 린트를 수행합니다. 책 저자는 [ESLint](http://eslint.org/)을 사용합니다. -Most linters are integrated with many popular editors: just enable the plugin in the editor and configure the style. +대부분의 린트들은 많은 유명한 에디터와 함께 사용할 수 있습니다. 에디터에서 플러그인으로 사용할 수 있고 스타일을 환경 세팅할 수 있습니다. -For instance, for ESLint you should do the following: +예를 들어, ESLint의 경우 다음을 수행해야 합니다. -1. Install [Node.js](https://nodejs.org/). -2. Install ESLint with the command `npm install -g eslint` (npm is a JavaScript package installer). -3. Create a config file named `.eslintrc` in the root of your JavaScript project (in the folder that contains all your files). -4. Install/enable the plugin for your editor that integrates with ESLint. The majority of editors have one. +1. [Node.JS](https://nodejs.org/)를 설치합니다. +2. 명령어로 `npm install -g eslint` (npm은 자바스크립트 패키지 설치 프로그램입니다.)을 ESLint를 설치합니다. +3. 자바스크립트 프로젝트의 루트(프로젝트의 파일들이 모두 포함된 폴더)에 `.eslintrc` 파일 이름으로 환경 세팅 파일을 생성합니다. +4. ESLint와 함께 사용할 에디터의 플러그인 설치하고 활성화하세요. 다수의 에디터는 설치, 활성화 되어 있습니다. -Here's an example of an `.eslintrc` file: +`.eslintrc` 파일 작성의 예: ```js { @@ -308,17 +309,16 @@ Here's an example of an `.eslintrc` file: "indent": 2 } ``` +`"extends"` 지시자는 설정이 "eslint : recommended"설정을 기반으로한다는 것을 나타냅니다. 그 후에는 직접 지정합니다. -Here the directive `"extends"` denotes that the configuration is based on the "eslint:recommended" set of settings. After that, we specify our own. - -It is also possible to download style rule sets from the web and extend them instead. See for more details about installation. +웹에서 스타일 규칙 세트들을 다운로드하여 대신 사용할 수도 있습니다. 더 많은 자세한 사항과 설치는 'http://eslint.org/docs/user-guide/getting-started'에서 볼 수 있습니다. -Also certain IDEs have built-in linting, which is convenient but not as customizable as ESLint. +또한 IDE는 린트들이 내장되어 있어 편하지만 ESLint 변형을 할 수 없습니다. -## Summary +## 요약 -All syntax rules described in this chapter (and in the style guides referenced) aim to increase the readability of your code, but all of them are debatable. +읽기 쉬운 코드를 작성하는 것을 목표로 모든 문법의 규칙 그리고 스타일 가이드의 참고 자료는 이 장에서 설명이 되어 있습니다. 그러나 모두 논쟁의 여지가 있습니다. -When we think about writing "better" code, the questions we should ask are, "What makes the code more readable and easier to understand?" and "What can help us avoid errors?" These are the main things to keep in mind when choosing and debating code styles. +훨씬 "더 나은" 코드를 작성하는 것에 대한 생각을 할 때, 우리가 묻는 질문은 "코드를 읽기 쉽고,보다 이해하기 쉬운 코드를 만드는 이유"와 "오류를 방지하는데 도움이 되는 것은 무엇입니까?" 입니다. 이러한 것들이 코드 스타일을 선택하고 토론할 때 염두에 두어야 할 주요 사항입니다. -Reading popular style guides will allow you to keep up to date with the latest ideas about code style trends and best practices. +인기있는 스타일 가이드를 읽으면 코드 스타일 동향 및 모범 사례에 대한 최신 아이디어를 최신으로 유지할 수 있습니다. \ No newline at end of file diff --git a/1-js/03-code-quality/02-coding-style/code-style.png b/1-js/03-code-quality/02-coding-style/code-style.png index 1c6d355dd5..e72cbb314c 100644 Binary files a/1-js/03-code-quality/02-coding-style/code-style.png and b/1-js/03-code-quality/02-coding-style/code-style.png differ diff --git a/1-js/03-code-quality/02-coding-style/figure-bracket-style.png b/1-js/03-code-quality/02-coding-style/figure-bracket-style.png index b04db65c67..b8b163015f 100644 Binary files a/1-js/03-code-quality/02-coding-style/figure-bracket-style.png and b/1-js/03-code-quality/02-coding-style/figure-bracket-style.png differ