Integer types refactoring guidelines - minsuk-jang/teamproject GitHub Wiki

많은 다른 작업에서 정수 유형을 refactoring 하는 것이 필요합니다 :

• 부호가 있거나 부호없는 유형과 암시적 변환이 혼합되어 오류가 발생하지 않도록 하십시오.
• 적절한 경우 크기 의미를 강조합니다.
• 형변환 할 필요없이 `size_t '값을 반환하는 시스템 함수를 준수합니다.
• 우리가 조작 할 수 있는 것들의 크기에 불필요한 제한이 부과되지 않도록 하십시오.
• 명시적 형변환으로 인해 데이터가 잘릴 수 있습니다.
• 기타.

이러한 종류의 refactoring을 어떻게 수행해야 하는지에 동의하는 것이 중요합니다. 하나 :

• 완전히 옳다는 하는 것은 어려운 일입니다. 모든 가능한 상황에 대해 굳건한 규칙 집합은 어울리지 않습니다.
• 이 지침은 새로운 사람들이 이러한 문제에 직면 할 수 있도록 돕고 더 많은 경험이있는 사람들이 코드가 동질화되도록 합의를 도출하기위한 원칙을 수립하는 기본 틀이 될 것입니다.
• 더 이상 생각하지 않고 적용하는 것과 같은 일련의 기계적인 규칙이 될 의도는 없습니다.
• 모든 특정 사례는 조치를 취하기 전에 신중하게 분석해야 합니다.

즉, 조언은 다음과 같습니다.

• size_t의 의미를 지닌 long_u
• uint64_t의 의미가 없는 long_u
• long의 의미:
  • 간편한 전환을 쉽게 할 수 있습니다. --> size_t
    (일반적인 문제가 발생하지 않는 문제를 확인하십시오.)
  • 부호가 있는 변환이 어렵다. --> ssize
    (예를 들어, 빼기가 포함 된 복잡한 코드)
    참고 :ssize는 src / nvim / types.h에 정의된 프로젝트 차원의 typedef입니다.
• 크기 의미없는 long --> int64_t

• 크기 의미를 갖는 int:
  • 간편한 전환을 쉽게 할 수 있습니다. --> size_t
    (일반적인 문제가 발생하지 않는 문제를 확인하십시오.)
  • 부호가 있는 변환이 어렵다. --> ssize
    (예를 들어, 빼기가 포함 된 복잡한 코드)
    
• 크기 의미없는 int --> int

위의 일반적인 조언에도 불구하고 더 엄격한 타이핑을 선호하는 경우가 있습니다.

가능한 경우 구조체를 작게 유지해야합니다. 마지막까지:

• 가능한 경우 고정 너비 유형 (int32_t,uint32_t 등)을 사용하십시오. 이것은:
• 지정된 너비가 항상 충분하다는 것을 확신 할 수 있는 경우에만 수행하십시오. 그래서:
• 필드에 임의 / 불필요한 제한을 두지 마십시오.
• 예 : 필드가 명확한 크기 의미를 가지고 있고 특별한 이유가 없으면 size_t /ssize를 사용하십시오. 필드에 임의 / 불필요한 제한을 두지 마십시오.

• 전송 / 직렬화 메커니즘을 통해 다른 프로세스를 연결하는 함수의 경우 고정 폭 유형이 선호됩니다. 예를 들어msgpack_rpc.h에서 :

bool msgpack_rpc_integer_result(uint32_t result, msgpack_object *req, msgpack_packer *res);

- 공용 API의 함수 부분에는 기본 유형이 선호됩니다. 예를 들어, 가상의 `libneovim.h`에서 :

  ```c
int neovim_get_current_buffer(void);

구조체 필드, 함수 매개 변수 또는 전역 변수가 될 수 있는 입력 변수가 있으면 해당 유형을 다루는 코드에서 해당 유형을 계단식으로 배열할지 또는 보다 잘 간주하면 더 넓은 유형을 사용할지 결정해야 합니다 전형적인 예를 들자면, 일단 고정 너비의 구조체 필드가 ​​있다면, 그것을 다루는 코드 (함수 변수 / 매개 변수)는 고정 폭 타입을 사용해야 하며, 다른 유형으로 넓혀야 할 수도 있습니다. 원칙은 다음과 같습니다.

• 입력 변수에 대한 액세스가 읽기 전용인 경우 값을 상향 조정 하기만 하면 다른 이유로 더 선호하는 경우 더 넓은 유형을 사용하는 것이 안전합니다.
• 입력 변수에 대한 액세스가 읽기/쓰기가 가능한 경우 중간 변수/ 매개 변수는 가능한 한 입력 변수의 유형을 유지하려고 시도해야 합니다.

우리는 this가 오류가 발생하지 않도록 세심한 주의를 기울이고 있음을 알게 되었습니다. here에 설명되어 있습니다. 그로부터 결론을 내릴 수 있습니다.

루프에는 counter 변수와 limit 표현이 있습니다 (조건은 counter와 limit의 비교 입니다.) condition (즉, counter 및 limit이 다른 부호의 유형을 가질 때)에서 다른 부호 유형을 혼합할 뿐만 아니라 limit 표현의 암시적 변환으로 인해 주로 문제가 발생할 수 있습니다. 암시적 변환 및 type-signedness-mixing 문제를 방지하고 감소시키기 위해서는 다음을 수행하십시오.

• 가능한 경우 condition 표현식 내의 변수에서 다른 서명 유형을 피하십시오 (많은 오류는 부호 유형에서 부호없는 유형으로 암시적으로 변환되기 때문에 발생합니다).
• 원칙적으로, limit expression의 타입은 counter의 타입을 결정합니다. limit 표현식이 size_t인 경우 counter도 마찬가지입니다. limit 표현식이 ssize인 경우 counter도 마찬가지입니다. 등등.
• counter 및 limit의 결과 유형이 부호가 없는 경우 :
  • 한계 값에 대한 limit 표현식을 확인하십시오 (예 : 크기가 0 인 경우).
  • (조건이 항상 양수가 될 수 있음을 증명할 수 없도록 하지 않는 한) substraction을 사용하여 condition을 피하십시오.
• 최적화로 ssize 대신 int를 사용하거나 size_t 대신 unsigned int를 사용할 수 있습니다. 단, 이러한 유형이 항상 충분할 것이라는 확신이 있어야만 최적화 할 수 있습니다. 임의/불필요한 제한을 두지 마십시오.