자료 추상화 - 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스 - 객체에서 자료는 숨기고 자료를 다루는 함수만 제공 - 아무 생각 없이 get, set 함수를 추가하는 것이 가장 나쁘다 (선생님 swift의 private(set)은요...?) 자료/객체 비대칭(이해 못함) - (자료구조를 사용하는) 절차적인 코드는 기존 자료구조를 변경하지 않으면서 새 함수를 추가하기 쉽다. 반면, 객체지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다. - 절차적인 구조는 새로운 자료구조를 추가하기 어렵다. 그러려면 모든 함수를 고쳐야 한다. 객체지향 코드는 새로운 함수를 추가하기 어렵다. 그러려면 모든 클래스를 고쳐야 한다. (--> 새로운 함..
목적: 원활한 의사소통 적절한 행 길이 유지 - 파일의 길이가 짧게 유지되도록 - 첫부분: 고차원 개념과 알고리즘 설명 - 마지막: 저차원 함수와 세부 내역 (아래로 내려갈수록 세세하게 묘사) - 개념 사이는 빈 행으로 구분 (새로운 개념을 시작한다는 시각적 개념) - 밀접한 코드들끼리는 가까이 둔다 (주석이 끼면 멀어지므로 주의) - 수직거리 - 변수 선언: 사용하는 위치에 최대한 가깝게 - 인스턴스 변수: 클래스 맨 처음에 선언 - 종속함수: 한 함수가 다른 함수를 호출하면 세로 가까이 (호출하는 함수 - 호출되는 함수 순서로) - 개념적 유사성: 유사한 메서드끼리 가까이 둔다 가로 형식 맞추기 - 행 길이가 짧은 걸 대체로 선호 - 가로 공백과 밀집도 - 밀접한 개념은 붙여서, 요소가 나뉘는 지점은..
코드 자체만으로 의도를 표현하는 게 좋다. - 주석을 안 좋게 보는 이유: 코드를 고칠 때 함께 고치지 않으면 틀린 설명이 된다. --> 나쁜 코드에 주석 달아서 그럴싸해보이게 하지 말고 코드를 가독성있게 다시 짜라! 좋은 주석? - 법적인 주석 (copyright...) - 정보를 제공하는 주석 (ex. 어떤 인스턴스인지 / 정규 표현식 설명) --> 함수나 클래스로 분리해 주석을 없애는 게 더 낫다 - 의미를 명료하게 밝히는 주석 (ex. 모호한 인수나 리턴값) --> 명확한 표현을 써서 만들면 좋지만 라이브러리 코드처럼 변경이 안되는 경우 - 결과를 경고하는 주석 - TODO 주석 - 중요성을 강조하는 주석 (남들이 대수롭지 않게 생각할 것 같은 부분인데 사실 그러면 안되는 포인트인 곳들) 나쁜 주..
함수는 작게, 최대로 작게! - 들여쓰기 1 ~ 2단, 중첩 if / while은 최대한 제거하기 함수 하나에 하나의 기능만 넣자. - 판별: 함수 내에서 다른 함수로 추출이 가능한 코드가 있는가? 코드 아래로 내려갈수록 추상화 수준이 낮아지도록 함수를 배치 switch문 많이 쓰지 않기 서술적인 이름 사용 - 이름으로 기능을 유추하기 쉽도록 (ex. testableHTML -> setupTeatdownIncluder.render) 함수 인수 - 0개가 이상적, 최대 2개, 3개는 지양 - 1개 - 인수에게 질문 던지기 (boolean fileExist("MyFile")) - 인수를 반환 후 변환하는 함수 - flag 인수 - 제발 하지 마라, True와 False 결과에 해당하는 코드를 두 함수로 쪼개..
