[posts] Add usage guideline summary of effective dart.

content/posts/effective_dart/contents.lr

@@ -0,0 +1,79 @@
+_model: post
+---
+title: Effective Dart
+---
+pub_date: 2016-11-13
+---
+author: -
+---
+body:
+
+지난 수 년간, 우리는 수 많은 다트 코드를 작성하면서 다트가 어떤 부분에서 잘 동작하고 어떤 부분에서 잘 동작하지 않는지 배웠습니다. 이 글을 공유하면서 여러분들이 일관성있고, 로버스트하고, 빠른 코드를 작성하는데 도움이 되길 바랍니다.
+
+### 효과적인 코드를 작성하기 위해 두 가지 주제가 있습니다.
+
+1. **일관성 있게 작성하십시오.** 포매팅, casing, 인자같은 것들은 대부분은 주관적인 부분으로 귀결하는 경향이 있기 때문에 해결하기 어렵습니다. 단지 우리가 아는 것은 일관성 있게 작성하는 것이 도움이 된다는 사실입니다.
+
+만약 두 코드가 다른 형태로 나타난다면, 그 두 코드는 각각 다른 의미를 담고 있어야 합니다. 코드 중 일부가 눈에 띈다면 그에 마땅한 이유가 있어야 합니다.
+
+2. **간결하게 작성하십시오.** 다트는 채택하기 쉽도록 설계되었습니다. C, Java, JavaScript 등 언어에서 쓰이는 많은 구문과 표현식을 그대로 사용할 수 있습니다. 그럼에도 우리가 다트를 만든 이유는 여전히 많은 부분에서 더 나은 방법들이 있기 때문입니다. String interpolation에서부터 Initializing formals까지 보다 간단하고 쉽게 당신의 의도를 표현할 수 있도록 다트에 많은 기능을 추가했습니다.
+
+어떤 의도를 표현하기 위해 많은 표현 방법이 존재한다면, 가장 간결한 하나를 선택하십시오. 한 줄에 모든 코드를 작성하기 위해 코드 골프를 하라는 것은 아닙니다. 간결함의 목적은 경제적이고 실속있는 코드이지 빽빽한 코드가 아닙니다.
+
+## 안내 영역
+가이드라인을 네 가지로 나누어 제공합니다.
+
+ * 스타일 안내 - 스타일 안내는 코드 포맷을 위한 규칙들을 정의합니다. 이 규칙들은 dartfmt 구현에 적용됩니다. 또한 식별자들이 camel case를 써야 하는지, 언더스코어를 써야하는지도 구분합니다.
+ * 문서화 안내 - 문서화 안내는 모든 주석이 어떻게 작성되어야 하는지에 대해 다룹니다. 문서화를 위한 주석부터 일반적인 주석까지 모두 이 안내에 포함됩니다.
+ * 사용 안내 - 사용 안내는 다트의 기능들을 잘 사용하는 방법에 대해 알려줍니다. 구문이나 표현식이 이 안내에 포함됩니다.
+ * 설계 안내 - 설계 안내에 있는 규칙들은 다른 안내에 있는 규칙에 비해, 꼭 지켜져야 한다는 내용은 아닙니다. 하지만 가장 폭넓게 적용되는 규칙들입니다. 우리가 알고 있는 일관성있고 사용 가능한 API에 관한 내용을 담고 있습니다. 타입 시그니처나 선언에 관한 내용이 이 안내에 포함됩니다.
+
+## 사용 안내
+
+문자열
+- [DO] 문자열 리터럴을 이어붙이는 데에는 Adjacent String을 사용한다.
+- [PREFER] 문자열과 값을 묶는데에는 Interpolation을 선호한다.
+- [AVOID] Interpolation에서 {}는 불필요한 경우 사용을 피한다.
+
+Collections 콜렉션
+- [DO] 가능하다면 콜렉션 리터럴을 사용한다.
+- [DON’T] 콜렉션이 비어있는지 확인하기 위해 length를 사용하지 않는다.
+- [CONSIDER] 시퀀스를 변환하기 위해 고차 함수를 쓰는 것을 고려한다.
+- [AVOID] Iterable.forEach() with a 함수 리터럴의 사용을 피한다.
+
+Functions 함수
+- [DO] 함수에 이름을 주기 위해 함수 선언을 사용하라
+- [DON’T] 불필요한 람다를 생성하지 않는다
+
+Variables 변수
+- [DON’T] 변수를 null로 명시적으로 초기화 하지 않는다.
+- [AVOID] 계산 가능한 것을 저장하는 것을 피한다.
+- [CONSIDER] 지역변수에는 타입을 쓰지 않는 것을 고려한다.
+
+Members 멤버
+- [DON’T] 필드를 불필요하게 getter와 setter로 감싸지 않는다.
+- [PREFER] 읽기 전용 프로퍼티에는 final 한정자를 쓰는 것을 선호한다.
+- [CONSIDER] 함수의 본문이 한 줄의 리턴문일 때는 => 문법을 쓰는 것을 고려한다.
+- [DON’T] shadowing을 피해야 하는 경우가 아니면 this를 쓰지 않는다.
+- [DO] 필드는 가능한 선언과 동시에 초기화한다.
+
+Constructors 생성자
+- [DO] 가능한 initializing formals를 사용한다.
+- [DON’T] initializing formals에 타입 어노테이트를 하지 않는다.
+- [DO] 생성자 본문이 빈 경우 {} 보다 ;를 사용한다.
+- [DO] super() 호출은 함수 초기화 리스트의 맨 마지막에 둔다.
+
+Error handling 에러 처리
+- [AVOID] catches without on clauses.
+- [DON’T] discard errors from catches without on clauses.
+- [DO]  Error를 구현한 클래스 오브젝트를 throw 할 때에는 반드시 programmatic error여야 한다.
+- [DON’T] explicitly catch Error or types that implement it.
+- [DO] rethrow를 사용한다.
+
+Asynchrony
+- [PREFER] future 기능을 사용할 때 async/await 키워드를 쓰는 것을 선호한다.
+- [DON’T] 불필요한 async 키워드를 사용하지 않는다.
+- [CONSIDER] stream 처리를 할 때에는 고차함수를 쓰는 것을 고려한다.
+- [AVOID] Completer를 직접적으로 사용하는 것을 피한다.
+
+