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
매개 변수가 너무 많다면 클래스화하라는 신호랍니다.
-> 동일 매개 변수가 여러 함수에 반복될때 클래스화 하라는 신호입니다.
댓글 0