인간을 위한 코드


공백도 코드입니다...

훌륭합니다. 코드가 프로덕션 환경에서 작동하고 충분히 빠릅니다.
축하하지만...
  • 충분히 읽을 수 있습니까?
  • 새로운 개발자가 그것을 선택하고 모든 의미를 이해하는 것이 얼마나 쉬운가요?
  • 코드를 읽는 것이 구축된 시스템의 좋은 정신적 모델을 제시합니까?

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

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

    공백



    - 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

    좋은 웹페이지 즐겨찾기