[C++] Philosophy 3 & 4

[C++] Philosophy 3 : Express intent

 

Reason (이름이나 주석 처럼) 일부 코드의 의도가 명시되지 않는 한, 코드가 해야할 일을 하고 있는 지 여부를 알 수 없다.

 

Example

v의 element들을 반복하는 의도는 분명하게 나타나지 않는다. index의 구현 세부사항이 (오용될 수 있도록) 노출되었고, i 변수는 (의도되었건 의도되지 않았건) 루프의 범위를 초과해서 남아 있다. Code를 읽는 사람은 코드의 이 부분만 봐서는 알 수가 없다.

 

Better:

이제 반복 메커니즘에 대한 명시적인 언급은 없으며, 루프는 우발적인 변경이 일어나지 않도록 상수(const) 요소에 대한 reference로 작동한다. 만약 element들에 대한 수정이 필요한 경우 다음과 같이 작성한다.

때때로 더 나은 것은, named 알고리즘을 사용하는 것이다. 이 예는 다음과 같은 의도를 직접적으로 표현하기 때문에 Ranges TS의 "for_each"를 사용한다.

마지막 variant은 우리가 v의 element들이 처리되는 순서에 관심이 없음을 분명히 해줍니다.

 

개발자는 아래 3개에 익숙해야 합니다.

● The guidelines support library

● The ISO C++ Standard library

● 현재 project에 쓰이는 기본 library들

 

어떻게 되야 하는지를 말하지 말고, 뭐가 되야 하는지를 말해라. 몇몇의 언어 구조들은 다른 것들보다 의도를 더 잘 표현한다.

 

Example 2D 점들의 좌표가 2개의 integer들로 되어 있다면, 다음과 같이 작성해라.

Enforcement 더 나은 대안이 있는 일반적인 pattern을 찾아봐라.

● 일반 for 반복문 vs. 범위 기반 for 반복문

● f(T*, int) interfaces vs. f(span<T>) interfaces

● 너무 큰 범위의 반복 변수

● naked new and delete

● 기본 제공 유형의 많은 parameter들이 있는 함수

 

영리하고 반자동화된 프로그램 변환을 위한 huge scope이 있다.

 

원문 출처

isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#p3-express-intent

C++ Core Guidelines

 

[C++] Philosophy 4: Ideally, a program should be statically type safe

 

Reason 이상적으로 프로그램은 (compile-time에) 완전하게 정적으로 type safe해야 한다. 불행하게도 이것은 불가능한데 문제가 되는 영역은 아래와 같다.

● unions

● casts

● array decay

● range errors

● narrowing conversions

 

Note 이러한 영역은 심각한 문제(예: crash 및 security violations)의 원인이다. 우리는 대체 기법을 제공하려고 노력한다.

 

Enforcement 개별 프로그램에 필요하고 실현 가능한 개별 문제 범주를 개별적으로 금지, 제한 또는 탐지할 수 있다. 항상 대안을 제시하라. 예를 들면 다음과 같다.

 

● unions - use variant (in C++17)

● casts - 사용을 최소화하고 template이 도움을 줄 수 있다.

● array decay - span 사용 (from the GSL)

● range errors - span 사용

● narrowing conversions - 사용을 최소화 하고 narrow나 narrow_cast를 적절히 사용해라 (from the GSL)

 

원문 출처

isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#p4-ideally-a-program-should-be-statically-type-safe

C++ Core Guidelines