Thief of Wealth

=== 를 썼는지

depth가 2가 넘어가는지

세미콜론 붙어있는지

전역변수를 사용 안했는지

함수는 1가지의 기능만 사용하는지

캐멀케이스로 구현되어 있는지

기능별로 파일을 나누었는지

Const를 let보다 위에 선언했는지.

Const, let은 선언시점에 바로 할당했는지

함수 끝에 ; 붙였는지

값을 하드코딩하지 않았는지

Space, tab 혼용하지 않았는지

private한 변수에 _를 적절히 적용했는지

(function내부에 this는 기본적으로 모두 접근가능하고 const/let/var로 선언하면 외부에서 접근할 수 없다!)

 

혹시 모르니 arrow function보다 그냥 function 사용하기

(arrow function 은 this 바인딩을 갖지 않는다 / arrow function은 new를 호출할 수 없다. 오잉?)

 

이름을 통해 의도를 드러내었는가?

: 이름을 통해 변수의 역할, 함수의 역할, 클래스의 역할에 대한 의도를 드러내어야 한다.

: 연속적인 숫자를 덧붙인 이름 a1,a2,a3 또는 불용어 info, Data, a, an, the 는 적절하지 못하다.

 

축약하지말것

: 의도를 드러낼 수 있다면 이름이 길어져도 상관없다.

 

linter, code formatter 기능 활용하기

: eslint와 prettier를 이용해서 더욱 생산적으로 코드를 작성해야 한다.

 

for/while/if 문 사이의 space도 컨벤션이다.

 

불필요하게 공백 라인을 만들지 않는다.

 

함수 또는 클래스의 구현 순서를 통일하면서 프로그래밍하는 것도 컨벤션이다.

 

최대한 중복을 피하고 컴포넌트화 하여 재사용해야 한다.

 

space/tab을 혼용하지 않는다.

 

변수이름/함수 이름을 통해 어떤 의도인지가 드러난다면 굳이 주석을 달지마라.

 

var 사용금지 (scorp 특성)

 

git commit 메세지를 의미있게 작성한다. (작업한 내용에 대한 이해가 가능하도록)

 

README.md에 기능목록은 기능 구현을 하면서 변경될 수 있다. 기능을 구현하면서 문서를 계속 업데이트 하자.

 

기능목록을 너무 상세하게 작성하지 않는다. 너무 세세한 부분까지 정리하기 보다, 구현해야할 기능 목록을 정리하는데 집중한다.

(정상적인 경우도 중요하지만, 예외적인 상황도 기능 목록에 정리한다. 예외상황을 기능을 구현하면서 계속해서 추가해 나간다.)

 

READMD.md는 어떤 프로젝트이고 어떤 기능을 담고 있는지 표현하는 파일이므로 상세히 작성한다.

 

미션 + 모듈 분리가 제대로 되었는가?

 

함수(또는 메소드)의 길이가 15라인을 넘어가지 않도록 구현한다

 

클래스나 함수를 내보낼 땐 세미콜론을 붙이지 않는다.

 

* 객체안에서 변수 선언하여 전역변수처럼 사용하기

* 커밋을 깔끔하게하기 README 기능별로 커밋하기

* README.md 깔끔하게 작성하기

 

import 알파벳 순으로 배치하기

 

eslint, prettier 셋팅하기 ==> feynubrick.github.io/2019/05/20/eslint-prettier.html

 

VS Code에서 ESlint와 Prettier 함께 사용하기

혼자서만 코드를 짜다가, 여러 사람과 프로젝트를 하다보면 여러 문제를 겪습니다. Git을 잘못 써서 사람들과 충돌이 생기기도 하고, 나와는 다른 방식으로 작성된 코드 때문에 두통이 생기기도

feynubrick.github.io

velog.io/@recordboy/ESLint-Prettier-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0

feat(파일이름): Add ~~ function 이라고 쓰기

 

실제 셰게에서와 같이 객체지향적으로 프로그래밍했는가?

 

좋은 git commit을 위한 약속 meetup.toast.com/posts/106

profile on loading

Loading...