C 사용자 식별자의 길이에 제한이 있습니까?

C 언어 식별자의 길이는 컴파일러에 의해 제한되며 일부 문자 (예 : 처음 31) 만 지원할 수 있습니다. 이식성 문제를 피하고 오류 가능성을 줄이려면 간결하고 명확한 식별자가 필요합니다.

C 사용자 식별자의 길이에 제한이 있습니까? 대답은 예, 그렇습니다. 그러나 실제 제한은 컴파일러에 따라 다르며 표준에 의해 엄격하게 규정되어 있지 않습니다.

이 질문은 간단 해 보이지만 숨겨진 미스터리가 있습니다. 많은 초보자들은 64 또는 128과 같은 특정 숫자를 초과하지 않는 한, 실제 상황은 이것보다 훨씬 더 복잡하다고 생각합니다. C 표준은 문자 나 밑줄로 시작하는 것과 같은 식별자의 구성 규칙 만 지정하며 문자, 숫자 또는 밑줄이 뒤 따릅니다. 그러나 길이의 경우 표준 문서는 모호하며 일반적으로 "충분히 길다"고 말합니다.

이 "충분히"뒤에는 컴파일러 구현의 차이가 있습니다. 다른 컴파일러는 식별자 길이를 다르게 처리합니다. 일부 컴파일러는 처음 31 자만 지원할 수 있으며 후속 문자는 무시됩니다. 일부 컴파일러는 더 많은 또는 수백 개의 문자를 지원할 수 있습니다. 안전은 얼마입니까? 절대 숫자를 줄 방법이 없습니다.

궁극적 인 코드 가독성을 추구하기 위해 process_incoming_network_data_packet_from_client_socket 과 같은 프로젝트에서 긴 식별자를 사용했습니다. 당시 사용 된 GCC 컴파일러에서는 모든 것이 괜찮 았습니다. 그러나 코드를 임베디드 시스템에 포팅하고 다른 컴파일러를 사용했을 때 문제가 발생했습니다. 컴파일러는 직접 오류를보고하여 식별자가 너무 길었다 고 말합니다. 이것은 "충분히 길다"라고 불리는 것이 컴파일러에 전적으로 의존한다는 것을 이해하게한다.

그렇다면 모범 사례는 무엇입니까? 불을 가지고 놀지 마세요! 소위 "발현 능력"을 추구하기 위해 너무 긴 식별자를 사용하지 마십시오. 이를 통해 이식성 문제가 발생할뿐만 아니라 코드를 읽고 유지하기가 어렵습니다. 이 코드는 사람들이 볼 수 있도록 작성되었으며 두 번째는 기계에 대해 실행됩니다.

명확하고 간결한 식별자는 길고 복잡한 식별자보다 훨씬 낫습니다. 예를 들어, 위의 예에서는 여러 기능으로 분할되거나 process_network_data 또는 procNetData 와 같은 짧은 이름을 사용하는 것을 고려할 수 있습니다. 이것은 코드의 가독성을 향상시킬뿐만 아니라 오류의 가능성을 줄입니다.

다른 예를 들어, 일부 컴파일러에서는 다음 코드가 적합 할 수 있지만 다른 컴파일러에서 오류를보고하거나 예상치 못한 결과를 생성합니다.

 <code class="c">#include <stdio.h> int incredibly_long_variable_name_that_might_cause_problems_on_some_compilers = 10; int main() { printf("%d\n", incredibly_long_variable_name_that_might_cause_problems_on_some_compilers); return 0; }</stdio.h></code>

이 위험을 감수하는 대신 처음부터 좋은 프로그래밍 습관을 개발하고 간결하고 명확한 식별자를 사용하는 것이 좋습니다. 이것은 불필요한 번거 로움을 피할뿐만 아니라 코드를보다 우아하고 유지 관리하기 쉽게 만듭니다. 프로그래밍은 실행할 수있는 코드를 작성하는 것뿐만 아니라 고품질, 이해하기 쉬운 코드를 작성하는 것입니다. 이것은 큰 황소가되는 진정한 방법입니다.

위 내용은 C 사용자 식별자의 길이에 제한이 있습니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!