C에서 가장 일반적인 명명 규칙은 무엇인가?

C에서 가장 일반적인 명명 규칙은 무엇인가?

C에서 일반적으로 사용되는 명명 규칙은 무엇인가?난 적어도 두 가지가 있다는 것을 안다.

1. lower_case_functions가 있는 GNU/linux / K&R
2. ? 이름 ? UpperCaseFoo 기능 포함

나는 여기서만 C에 대해 이야기하고 있다.우리 프로젝트의 대부분은 우리가 C를 사용하는 작은 임베디드 시스템이다.

다음 프로젝트에 사용하려고 하는 제품은 다음과 같다.

---

C 명명 규칙

Struct              TitleCase
Struct Members      lower_case or lowerCase

Enum                ETitleCase
Enum Members        ALL_CAPS or lowerCase

Public functions    pfx_TitleCase (pfx = two or three letter module prefix)
Private functions   TitleCase
Trivial variables   i,x,n,f etc...
Local variables     lower_case or lowerCase
Global variables    g_lowerCase or g_lower_case (searchable by g_ prefix)

여기서 가장 중요한 것은 일관성이다.그렇기는 하지만, 나는 다음과 같이 요약할 수 있는 GTK+ 코딩 규약을 따른다.

1. 캡의 모든 매크로 및 상수:MAX_BUFFER_SIZE,TRACKING_ID_PREFIX.
2. 구조체 이름 및 형식 지정(카멜케이스):GtkWidget,TrackingOrder.
3. 구조체에서 작동하는 기능: 클래식 C 스타일:gtk_widget_show(),tracking_order_process().
4. 포인터: 여기엔 화려하지 않다.GtkWidget *foo,TrackingOrder *bar.
5. 전역 변수: 전역 변수를 사용하지 마십시오.그들은 사악하다.
6. 존재하지만 직접 호출해서는 안 되는 기능 또는 모호한 용도를 가진 기능: 시작 부분에 하나 이상의 밑줄:_refrobnicate_data_tables(),_destroy_cache().

난 단순하게 하는 걸 좋아하지만..그래서 여기 내가 쓰는게 있어, C:

• 사소한 변수:i,n,c,etc... (한 글자만)문자 하나가 명확하지 않으면 로컬 변수)
• 로컬 변수:camelCase
• 전역 변수:g_camelCase
• 항상 변수:ALL_CAPS
• 포인터 변수: a 추가p_접두사까지글로벌 변수의 경우 다음과 같다.gp_var, 로컬 변수의 경우p_var, const 변수의 경우p_VAR. 원거리 포인터를 사용할 경우fp_대신에p_.
• 구조체:ModulePascalCase(모듈 = 전체 모듈 이름 또는 2-3글자 약어, 그러나 여전히 사용 중임PascalCase.)
• 구조 구성원 변수:camelCase
• 열거형:ModulePascalCase
• 열거형 값:ALL_CAPS
• 공용 기능:ModulePascalCase
• 개인 기능:PascalCase
• 매크로:PascalCase

나는 구조체를 입력했지만 태그와 입력란에 모두 같은 이름을 사용한다.그 태그는 일반적으로 사용되도록 되어 있지 않다.대신에 타이페프를 사용하는 것이 더 좋다.나는 또한 캡슐화를 위해 공공 모듈 헤더에 타이핑된 ef를 선언하고, 정의에 타이핑된 ef'd 이름을 사용할 수 있도록 한다.

가득찬 struct 예:

typdef struct UtilsExampleStruct UtilsExampleStruct;
struct UtilsExampleStruct{
    int var;
    UtilsExampleStruct *p_link;
};

"구조화 포인터"는 그것들을 다루기 위해 명명 규칙 조항이 필요한 실체가 아니다.그들은 그저 그렇다.struct WhatEver *. 영리하고 "명료한" 타이페프와 관련된 포인터가 있다는 사실을 숨기지 마십시오.그것은 목적이 없고, 타이핑이 더 길며, 선언과 접근 사이의 균형을 파괴한다.

C에서 프로그램할 때 다음 규칙을 사용할 것이다.

정의들	접두사를 붙이다	예
변수 - 로컬(일반)	/	i,n,a,b... ii,nn,aa,bb... iii,nnn,aaa,bbb...
변수 - 로컬(일반)	/	variable,conection...
가변 - 전역	g_	g_variable,g_connection...
변수 - 상수	c_	c_variable,c_connection...
포인터	p_	p_variable,p_connection...
배열하다	a_	a_variable,a_connection...
구조상의	s_	s_variable,s_connection...
결합하다	u_	u_variable,u_connection...
열거하다	e_	e_variables,e_connection...
구조체(구성원) 조합(회원) 열거(멤버)	m_ m_ m_	m_variable,m_connection... m_variable,m_connection... m_variable,m_connection...
구조체(비트 필드)	b_	b_variable,b_connection...
기능을 발휘하다	f_	f_variable,f_connection...
매크로	o_	o_variable,o_connection...

참고:

변수를 제외한 각 정의는 하나의 문자 접두사를 가지므로, 이 접두사를 결합한 다음 잘못 이해되지 않을 수 있다.

참고:

왜냐하면 나는 편지가 다 떨어졌고 소문자 접두어, 접두어 "만을 고집했기 때문이다.o_매크로에 사용되는 "은 정의의 첫 글자(macro)와 일치하지 않지만 마지막 글자(macro)와 일치한다.

만약 네가 어떤 제안을 한다면 나는 마음이 열려 있다.

자동이름 완성을 쉽게 하기 위해서는 단어의 순서도 생각해야 한다.

모범 사례: 라이브러리 이름 + 모듈 이름 + 액션 + 제목

부품이 관련이 없다면 그냥 건너뛰기만 하면 되지만, 최소한 모듈 이름과 조치가 항상 제시되어야 한다.

예:

• 함수 이름:os_task_set_prio,list_get_size,avg_get
• 정의(여기서는 일반적으로 수행 부분이 없음): OS_TASK_PRIO_MAX

여기 (명백하게) 흔치 않은 것이 있는데, 내가 유용하다고 생각한 것은 CamelCase에 있는 모듈 이름, 그 다음에 밑줄, 그리고 CamelCase에 있는 기능 또는 파일 범위 이름이다.예를 들면 다음과 같다.

Bluetooth_Init()
CommsHub_Update()
Serial_TxBuffer[]

우선 C는 공공/민간/가상 기능을 가지고 있지 않다.그것은 C++이고 그것은 다른 관습을 가지고 있다.C에서는 일반적으로 다음과 같은 이점을 얻을 수 있다.

• ALL_CAPS의 상수
• 구조체 또는 함수 이름으로 단어를 구분하는 밑줄, C에서 낙타 케이스를 거의 볼 수 없음;
• 구조체, 타이페프, 조합, 조합원(조합과 구조체의 조합) 및 열거값은 일반적으로 첫 글자를 대문자로 만드는 C++/Java/C#/etc 관례보다는 (내 경험상) 낮은 경우에 있지만, C에서도 가능할 것 같다.

C++는 더 복잡하다.여기서 진짜 혼동을 본 적이 있다.클래스 이름 또는 소문자+언더스코어의 경우 낙타 케이스(카메라 케이스가 내 경험에서 더 일반적이다).구조물은 거의 사용되지 않는다(일반적으로 라이브러리에 구조물이 필요하기 때문에 그렇지 않으면 클래스를 사용할 수 있다.

C#, Java, C, C++, 그리고 객관적인 C로 동시에 코딩하면서 나는 내 삶을 단순화하기 위해 매우 간단하고 명확한 명명 규칙을 채택했다.

First of all, it relies on the power of modern IDEs (such as eclipse, Xcode...), with the possibility to get fast information by hovering or ctrl click... Accepting that, I suppressed the use of any prefix, suffix and other markers that are simply given by the IDE.

Then, the convention:

• Any names MUST be a readable sentence explaining what you have. Like "this is my convention".
• Then, 4 methods to get a convention out of a sentence:
  1. THIS_IS_MY_CONVENTION for macros, enum members
  2. ThisIsMyConvention for file name, object name (class, struct, enum, union...), function name, method name, typedef
  3. this_is_my_convention global and local variables,
     parameters, struct and union elements
  4. thisismyconvention [optional] very local and temporary variables (such like a for() loop index)

And that's it.

It gives

class MyClass {
    enum TheEnumeration {
        FIRST_ELEMENT,
        SECOND_ELEMENT,
    }

    int class_variable;

    int MyMethod(int first_param, int second_parameter) {
        int local_variable;
        TheEnumeration local_enum;
        for(int myindex=0, myindex<class_variable, myindex++) {
             localEnum = FIRST_ELEMENT;
        }
    }
}

There could be many, mainly IDEs dictate some trends and C++ conventions are also pushing. For C commonly:

• UNDERSCORED_UPPER_CASE (macro definitions, constants, enum members)
• underscored_lower_case (variables, functions)
• CamelCase (custom types: structs, enums, unions)
• uncappedCamelCase (oppa Java style)
• UnderScored_CamelCase (variables, functions under kind of namespaces)

Hungarian notation for globals are fine but not for types. And even for trivial names, please use at least two characters.

I would recommend against mixing camel case and underscore separation (like you proposed for struct members). This is confusing. You'd think, hey I have get_length so I should probably have make_subset and then you find out it's actually makeSubset. Use the principle of least astonishment, and be consistent.

I do find CamelCase useful to type names, like structs, typedefs and enums. That's about all, though. For all the rest (function names, struct member names, etc.) I use underscore_separation.

I'm confused by one thing: You're planning to create a new naming convention for a new project. Generally you should have a naming convention that is company- or team-wide. If you already have projects that have any form of naming convention, you should not change the convention for a new project. If the convention above is just codification of your existing practices, then you are golden. The more it differs from existing de facto standards the harder it will be to gain mindshare in the new standard.

내가 덧붙이고 싶은 유일한 제안은 uint32_t와 size_t의 유형 끝에서 _t를 좋아했다는 것이다.비록 몇몇은 그것이 "역행" 헝가리인이라고 불평할지 모르지만, 그것은 나에게 매우 시시하다.

초심자에게 도움이 될 수 있다고 생각한다: c에 변수의 명칭을 붙이기

1. 알파벳 문자(a-z, A-Z), 숫자(0-9) 및 점수 미달(_)을 사용해야 한다.%, $, #, @ 등 어떤 특별한 캐릭터도 사용할 수 없다.따라서 user_name은 변수로 사용할 수 있지만 user&name은 사용할 수 없다.
2. 단어 사이에 공백을 사용할 수 없음.따라서 user_name이나 username이나 username이나 username을 변수로 사용할 수는 있지만 user name은 사용할 수 없다.
3. 숫자로 이름을 지정할 수 없음.따라서 user1 또는 user2를 변수로 사용할 수 있지만 1명의 사용자는 사용할 수 없다.
4. 대소문자를 구분하는 언어다.대문자와 소문자가 유의하다.만약 당신이 사용자 이름과 같은 변수를 사용한다면, 당신은 아버지에 대해 사용자 이름이나 사용자 이름을 사용할 수 없다.
5. 변수 선언에는 어떤 키워드(char, int, if, for, while 등)도 사용할 수 없다.
6. ANSI 표준은 변수 이름에 대해 31자의 길이를 인식함

나는 네가 이 문서를 읽기를 추천한다.

추상적
이 문서는 마지막 세 명의 저자가 수정한 인도 Hill C Style and Coding Standards 논문의 최신 버전이다.C 프로그램에 권장되는 코딩 표준을 설명한다.범위는 기능적 조직이 아닌 코딩 스타일이다.

https://www.doc.ic.ac.uk/lab/cplus/cstyle.html#N1026F

참조URL: https://stackoverflow.com/questions/1722112/what-are-the-most-common-naming-conventions-in-c