인간을 위한 코드

공백도 코드입니다...

훌륭합니다. 코드가 프로덕션 환경에서 작동하고 충분히 빠릅니다.
축하하지만...

충분히 읽을 수 있습니까?

새로운 개발자가 그것을 선택하고 모든 의미를 이해하는 것이 얼마나 쉬운가요?

코드를 읽는 것이 구축된 시스템의 좋은 정신적 모델을 제시합니까?

이것은 완전한 목록은 아니지만 위의 질문에 대한 대답이 아니오인 경우 다시 방문하여 몇 가지 외관상의 변경을 고려해야 합니다.

다음은 코드를 작성/읽을 때 따르는 몇 가지 지침입니다.

공백

- white-spaces are code too


leave a blank line between method definitions
a blank line when there is a changes in context within method body 

들여 쓰기

- indent code well
follow consistent indent length, 2 spaces or 4 spaces
be consistent with use of tabs or spaces, choose one and stick to it across the team(s)

변수 및 메서드 이름 지정

- use concise and meaningful names
variable names should reflect the value they refer
method names should reflect the process / business logic contained

선적 서류 비치

- unless it is a framework, module, class, method, variable names should be self documenting without need of additional documentation
comments should not be a tool to justify messy code segments

코드를 디자인하다

- every code is a piece of art uniquely conceived by it's developer
visualise the interactions between objects before beginning to code
visualise message exchanges needed before beginning to code

오른쪽 추상화

- abstraction does not mean hiding the complexity detail
know the behavioural traits to model
have a api spec to refer to
know before hand methods, variables, constants to expose
do not make decisions based on speculations
requirements are the corner stone

언어 관용구

- make use of language idioms
Ruby Example: [1, 2, 3, 4].sum  v/s  [1, 2, 3, 4].each {|ele| sum = sum + ele}

인간을 위한 코드

표지 이미지 크레디트: Unsplash