STL 알고리즘 함수를 활용해 주세요.

-> 지난 강좌 글에서 설명했습니다.

검색 반복문을 분리해주세요.

-> 재사용될 수 있는 여지가 큽니다.

-> 한 번에 결과를 내 놓는 함수인지, 순차나 2진 탐색을 통해 결론을 내는 함수인지

-> 함수명을 통해 분명히 구별해주는게 무분별한 사용을 통한 성능저하를 막을 수 있습니다.

-> find, search, seek, query, indexof 등의 네이밍으로 구별.

반복문 내의 처리는 최소한으로 만들어 주세요.

-> 당연하긴 한데, 성능을 위한 루프 언롤링은 별개 문제.

-> 반복문 안에서 변화하는 값이 아닌, 반복문 밖에서 결정될 수 있는 모든 값들은

-> 반복문 안에서 계산시켜서는 안됩니다.

반목분 내부에서는 1개의 처리만 수행하세요.

-> 요건 좀 위에꺼랑 중언 부언에 오버임.

람다식을 사용해서 반복문을 일반화하세요.

-> 람다식을 사용한다는건 지역화, 익명화의 장점을 가짐과 동시에,

-> 이름을 가진 변수에 대입해 두고 다른곳에서 사용할 수 있는 반대의 의미도 있습니다.

-> 일반화를 통해 파라메터를 정리하게 되는데, 그 과정에서 성능을 높일수 있는 여지가 다시 발생하게 됩니다.

-> 하지만 반대로 값이 계산되어 조건 안에 들어가게 되기 때문에, short circuit 효율이 떨어지는,

-> 인자로 사용된 값들이 미리 모두 계산되어야 하는 단점도 있습니다.

-> 알고 쓸 노릇입니다.

case 내부는 함수화해주세요.

-> 코드가 길어지면 좋을게 없습니다. 30줄 이내로 맞춰주세요.

-> case 를 탄다는건 상태 변화에 대응한다는 것인데,

-> 요구사항 변화에 따라 매번 코드 블럭을 붙였다 내렸다 하는것도 미개한 방법입니다.

부정확한 상태를 assert로 확인해주세요.

-> 이것도 중언 부언

상태에 따른 분기는 다형성을 사용해야 하는 신호에요.

-> 상태를 상수로 정의할 수 있는지 타입으로 정의할 수 있는지 고민하고,

-> 템플릿의 파라메터로 넣어버리것이 코드를 정리하는 방법입니다.

1개의 함수에는 1개의 역할만 주세요

-> 당연. 그래야 재사용성이 높아집니다.

-> 대신 당연하게도 상위 함수에선 여러개의 단위 함수를 부르는 구조면 됩니다.

-> 즉 역할이 두꺼워지는 상위함수는 있을 수 있지만,

-> 그 내부는 함수 호출 네이밍으로 간결히 정리되어 있어야 한다는거죠.

단순한 함수일수록 재사용하기 좋아요

-> 절대적입니다. 위와 같은 말이죠.

복잡한 복합 조건은 피해주세요.

-> 앞서 다 이야기 한 내용.

자연어처럼 읽을 수 있게 코드를 작성하세요.

-> 역시 설명함.

조건 분기 블록 내부는 함수화해야 하는 후보랍니다.

-> 모든 블럭은 함수, 클래스, namespace 의 후보입니다.

1개의 반복문에는 1개의 함수만 사용해주세요.

-> 좀 과도해서 멍청한 이야기. 병렬화 때 약간의 이점은 가져갈 수 있습니다.

반복문 블록 내부는 함수화 후보랍니다.

-> 또 중언 부언.

데이터 변환 부분은 함수화해주세요.

-> 자주 쓰입니다.

데이터 확인 부분은 함수화해주세요.

-> evaluation 과 validation, verification test 는 간과하기 쉽지만,

-> 굉장히 중요한 부분입니다. 잘 정리해 두셔야 합니다.

배열 랜덤 접근 부분을 함수화해주세요.

-> 이미 정리된 이야기 입니다.

취약한 기본 자료형 배열을 사용하지 말아 주세요.

-> 구조체나 클래스로 한 번 싸주란 이야깁니다.

-> 그게 코드가 더 구조적이되고 관리포인트를 줄일 수 있습니다.

-> 명시적이기도 하구요.

주석으로 말하지 말고 함수로 말하세요.

-> 프로그래머는 코드로 말해야 합니다 암요~

매개 변수가 너무 많다면 함수를 분할하라는 신호랍니다.

-> MS API 코드들을 보면 얼마나 개떡같은지 알 수 있습니다.

-> 덕분에 코드 재사용성이 거의 없어지지요.

-> 뭔 당장 필요치도 않은 구조체를 얼마나 원하는지. 181818

매개 변수가 너무 많다면 클래스화하라는 신호랍니다.

-> 동일 매개 변수가 여러 함수에 반복될때 클래스화 하라는 신호입니다.