柚子快報激活碼778899分享：c語言 C 語言編碼規(guī)范
柚子快報激活碼778899分享：c語言 C 語言編碼規(guī)范
工作中養(yǎng)成良好的代碼編寫規(guī)范
一、文件結構
????????每個 C++/C 程序通常分為兩個文件。一個文件用于保存程序的聲明（declaration）， 稱為頭文件。另一個文件用于保存程序的實現(xiàn)（implementation），稱為定義（definition） 文件。 ????????C++/C 程序的頭文件以“.h”為后綴，C 程序的定義文件以“.c”為后綴，C++程序 的定義文件通常以“.cpp”為后綴（也有一些系統(tǒng)以“.cc”或“.cxx”為后綴）。
1、版權和版本的說明
版權和版本的聲明位于頭文件和定義文件的開頭（參見示例 1-1），每個源文件都應該有文件頭說明，主要內容有： （1）版權信息。 （2）文件名稱，摘要。 （3）當前版本號，作者/修改者，完成日期。 （4）版本歷史信息。
示例1-1 版權和版本的聲明
/*
* Copyright (c) 2021,Shenzhen xxxxxx Co.,Ltd
* All rights reserved.
*
* Filename：filename.h
* Description：簡要描述本文件的內容
*
* Version：1.1
* Author：作者（或修改者）名字
* Date：2021.07.01
*
* Version：1.0
* Author：原作者（或修改者）名字
* Date：2021.05.10
*/
2、頭文件的結構
頭文件由三部分內容組成： （1）頭文件開頭處的版權和版本聲明（參見示例 1-1）。 （2）預處理塊。 （3）函數(shù)和類結構聲明等。 假設頭文件名稱為 graphics.h，頭文件的結構參見示例 1-2。為了防止頭文件被重復引用，應當用 ifndef/define/endif 結構產生預處理塊；用 #include
示例 1-2 C++/C 頭文件的結構
// 版權和版本聲明見示例 1-1，此處省略。
#ifndef _GRAPHICS_H _// 防止 graphics.h 被重復引用
#define _GRAPHICS_H_
#include
…
#include “myheader.h” // 引用非標準庫的頭文件
…
void Function1(…); // 全局函數(shù)聲明
…
class Box // 類結構聲明
{
…
};
#endif
3、定義文件的結構
定義文件有三部分內容： （1） 定義文件開頭處的版權和版本聲明（參見示例 1-1）。 （2） 對一些頭文件的引用。 （3） 程序的實現(xiàn)體（包括數(shù)據(jù)和代碼）。 假設定義文件的名稱為 graphics.cpp，定義文件的結構參見示例 1-3。如果一個軟件的頭文件數(shù)目比較多（如超過十個），通常應將頭文件和定義文件分別保存于不同的目錄，以便于維護，例如可將頭文件保存于 include 目錄，將定義文件保存于 source 目錄（可以是多級目錄）；如果某些頭文件是私有的，它不會被用戶的程序直接引用，則沒有必要公開其聲明，為了加強信息隱藏，這些私有的頭文件需要和定義文件存放于同一目錄下。
示例 1-3 C++/C 定義文件的結構
// 版權和版本聲明見示例 1-1，此處省略。
#include “graphics.h” // 引用頭文件
…
// 全局函數(shù)的實現(xiàn)體
void Function1(…)
{
…
}
// 類成員函數(shù)的實現(xiàn)體
void Box::Draw(…)
{
…
}
二、程序的版式
版式雖然不會影響程序的功能，但會影響可讀性。程序的版式追求清晰、美觀，是程序風格的重要構成因素。
1、空行
空行起著分隔程序段落的作用?？招械皿w（不過多也不過少）將使程序的布局更加清晰。在每個類聲明之后、每個函數(shù)定義結束之后都要加空行。參見示例 2-1(a)。在一個函數(shù)體內，邏揖上密切相關的語句之間不加空行，其它地方應加空行分隔。參見示例 2-1(b)。
示例 2-1(a) 函數(shù)之間的空行
// 空行
void Function1(…)
{
…
}
// 空行
void Function2(…)
{
…
}
// 空行
void Function3(…)
{
…
}
示例 2-1(b) 函數(shù)內部的空行
// 空行
while (condition)
{
statement1;
// 空行
if (condition)
{
statement2;
}
else
{
statement3;
}
// 空行
statement4;
}
2、代碼行
一行代碼只做一件事情，如只定義一個變量，或只寫一條語句；if、for、while、do 等語句自占一行，執(zhí)行語句不得緊跟其后。不論執(zhí)行語句有多少都要加{}，這樣可以防止書寫失誤。在定義變量的同時初始化該變量（就近原則），如果變量的引用處和其定義處相隔比較遠，變量的初始化很容易被忘記。如果引用了未被初始化的變量，可能會導致程序錯誤。本建議可以減少隱患。例如 int width = 10; // 定義并初紿化 width int height = 10; // 定義并初紿化 height int depth = 10; // 定義并初紿化 depth示例 2-2（a）為風格良好的代碼行
//示例 2-2（a）
int width; // 寬度
int height; // 高度
int depth; // 深度
x = a + b;
y = c + d;
z = e + f;
if (width < height)
{
dosomething();
}
for (initialization; condition; update)
{
dosomething();
}
// 空行
other();
3、空格與縮進
關鍵字之后要留空格。象 const、virtual、inline、case 等關鍵字之后 至少要留一個空格，否則無法辨析關鍵字。函數(shù)名之后不要留空格，緊跟左括號‘（’?！ā蚝缶o跟，‘）’、‘，’、‘;’向前緊跟，緊跟處不留空格‘，’之后要留空格，如 Function(x, y, z)。如果‘;’不是一行的結束符號，其后要留空格，如 for (initialization; condition; update)。賦值操作符、比較操作符、算術操作符、邏輯操作符、位域操作符，如“=”、“+=” “>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”,“^”等二元操作符的前后應當加空格。一元操作符如“!”、“~”、“++”、“--”、“&”（地址運算符）等前后不加空格。“［］”、“.”、“->”這類操作符前后不加空格。對于表達式比較長的 for 語句和 if 語句，為了緊湊起見可以適當?shù)厝サ粢恍┛崭?，?for (i=0; i<10; i++)和 if ((a<=b) && (c<=d))每行縮進 4 個空格。如果地位相等，則不需要縮進；如果屬于某一個代碼的內部代碼， 就需要縮進
?4、對齊
程序的分界符‘{’和‘}’應獨占一行并且位于同一列，同時與引用它們的語句左對齊；{ }之內的代碼塊在 ‘{’ 右邊數(shù)格處左對齊；
5、長行拆分
代碼行最大長度宜控制在 70 至 80 個字符以內，代碼行不要過長；長表達式要在低優(yōu)先級操作符處拆分成新行，操作符放在新行之首（以便突出操作符）。拆分出的新行要進行適當?shù)目s進，使排版整齊，語句可讀。
6、修飾符位置
應當將修飾符 * 和 ＆ 緊靠變量名，例如： char *name; int *x, y; // 此處 y 不會被誤解為指針。
7、注釋
C 語言的注釋符為“/*…*/”。C++語言中，程序塊的注釋常采用“/*…*/”，行注釋一 般采用“//…”。注釋通常用于：
（1）版本、版權聲明；
（2）函數(shù)接口說明；
（3）重要的代碼行或段落提示。
雖然注釋有助于理解代碼，但注意不可過多地使用注釋。注釋是對代碼的“提示”，而不是文檔。程序中的注釋不可喧賓奪主，注釋太多了會讓人眼花繚亂，注釋的花樣要少；邊寫代碼邊注釋，修改代碼同時修改相應的注釋，尤其是對參數(shù)、返回值、異常、核心的邏輯等修改，以保證注釋與代碼的一致性，不再有用的注釋要刪除；注釋的位置應與被描述的代碼相鄰，可以放在代碼的上方或右方，不可放在下方，盡可能使用右方(尾部)注釋；當代碼比較長，特別是有多重嵌套時，應當在一些段落的結束處加注釋，便于閱讀；及時清理不再使用的代碼段或配置信息，避免程序過度臃腫、代碼冗余，謹慎注釋掉代碼，要在上方詳細說明，而不是簡單地注釋掉，如果無用則刪除；典型的算法前都要有注釋，尾部注釋使用“//”、頭部使用塊注釋“/* */”。
三、命名規(guī)則
標識符應當直觀且可以拼讀，可望文知意，不必進行“解碼”。標識符采用英文單詞或其組合，便于記憶和閱讀，切忌使用漢語拼音來命名。程序中的英文單詞一般不會太復雜，用詞應當準確，例如不要把 CurrentValue 寫成 NowValue。
標識符的長度應當符合“min-length && max-information”原則。幾十年前老 ANSI C 規(guī)定名字不準超過 6 個字符，現(xiàn)今的 C++/C 不再有此限制。一般來說，長名字能更好地表達含義，所以函數(shù)名、變量名、類名長達十幾個字符不足為怪。單字符的名字也是有用的，常見的如 i,j,k,m,n,x,y,z 等，它們通?？捎米骱瘮?shù)內的局部變量。
太長的單詞可以使用縮寫或者助記符形式，基本規(guī)則是取其中的 3-4 個字母，具體是： (1)首尾兩個字母，中間取每個音節(jié)的首個字母(1-2 個); (2)或者取最前面的 3-4 個字母； (3)一般不取元音字母； (4)如果已經有了公認的縮寫形式，則以公認的形式為準，不受上面 3 條規(guī)則限制。
單詞縮寫單詞縮寫ArgumentArgBufferBufClearClrClockClkCompareCmpConfigurationCfgContextCtxControlCtlDelayDlyDeviceDevDisableDisDisplayDispEnableEnErrorErrFunctionFnHexadecimalHexHigh Priority Task?HPTI/O System?IOSInitializeInitMailboxMboxManagerMgrManualManMaximumMaxMessageMsgMinimumMinMultiplexMuxOperation SystemOSOverflowOvfParameterParamPointerPtrPreviousPrevPriorityPrioReadRdReadyRdyRegisterRegScheduleSchedSemaphoreSemStackStkSynchronizeSyncTimerTmrTriggerTrigWriteWr
標識符應采用駝峰規(guī)則，即“大小寫”混排的方式，所有單詞首字母都要大寫，如 AddChild。程序中不要出現(xiàn)僅靠大小寫區(qū)分的相似的標識符。程序中不要出現(xiàn)標識符完全相同的局部變量和全局變量，盡管兩者的作用域不同而不會發(fā)生語法錯誤，但會使人誤解。變量的名字應當使用“名詞”或者“形容詞＋名詞”。全局函數(shù)的名字應當使用“動詞”或者“動詞＋名詞”（動賓詞組）。類的成員函數(shù)應當只使用“動詞”，被省略掉的名詞就是對象本身。用正確的反義詞組命名具有互斥意義的變量或相反動作的函數(shù)等。宏全用大寫的字母，用下劃線分割單詞。
四、運算符的優(yōu)先級
1、運算符
如果代碼行中的運算符比較多，用括號確定表達式的操作順序，避免使用默認的優(yōu)先級。成對的符號一定要成對書寫，如()、{}等，以免漏掉右括號。
2、表達式
不要編寫太復雜的復合表達式。不要有多用途的復合表達式。不要把程序中的復合表達式與“真正的數(shù)學表達式”混淆。復雜的表達式需提取出去，做成中間變量。避免使用自增減表達式?？梢允褂煤陙矶x符號常量，但應盡量減少用宏來定義表達式，定義表達式時，要使用完備的括號。
3、if語句
不可將布爾變量直接與 TRUE、FALSE 或者 1、0 進行比較。根據(jù)布爾類型的語義，零值為“假”（記為 FALSE），任何非零值都是“真”（記為TRUE）。 假設布爾變量名字為 flag，它與零值比較的標準 if 語句如下： if (flag) // 表示 flag 為真 if (!flag) // 表示 flag 為假
應當將整型變量用“==”或“！=”直接與 0 比較。假設整型變量的名字為 value，它與零值比較的標準 if 語句如下： if (value == 0) if (value != 0)
不可將浮點變量用“==”或“！=”與任何數(shù)字比較，應該設法轉化成“>=”或“<=”形式。假設浮點變量的名字為 x，應當將 if (x == 0.0) // 隱含錯誤的比較 轉化為 if ((x>=-EPSINON) && (x<=EPSINON)) 其中 EPSINON 是允許的誤差（即精度）。
應當將指針變量用“==”或“！=”與 NULL 比較。需采用 if (NULL == p) 這樣的格式、而非 if(p == NULL)格式。
避免采用取反邏輯運算符。取反邏輯不利于快速理解，并且取反邏輯寫法必然存在對應的正向邏輯寫法。
4、循環(huán)語句的效率
在多重循環(huán)中，應當將最長的循環(huán)放在最內層，最短的循環(huán)放在最外層，以減少 CPU 跨切循環(huán)層的次數(shù)。如果循環(huán)體內存在邏輯判斷，并且循環(huán)次數(shù)很大，宜將邏輯判斷移到循環(huán)體的外面。
5、for語句的循環(huán)控制變量
不可在 for 循環(huán)體內修改循環(huán)變量，防止 for 循環(huán)失去控制。for 語句的循環(huán)控制變量的取值采用“半開半閉區(qū)間”寫法，即 0 <= i < n; 而非 0 <= i <= n-1;
6、switch語句
每個 case 語句的結尾不要忘了加 break。不要忘記最后那個 default 分支。即使程序真的不需要 default 處理，也應該保留語句 default : break;?
7、goto語句
主張少用、慎用 goto 語句，最好不用。
五、常量
常量是一種標識符，它的值在運行期間恒定不變。C 語言用 #define （稱為宏常量）和 const （稱為 const 常量）來定義常量。
1、常量的使用
盡量使用含義直觀的常量來表示那些將在程序中多次出現(xiàn)的數(shù)字或字符串。
2、const 與 #define比較
C 語言可以用 const 來定義常量，也可以用 #define 來定義常量。但是前者比后者有更多的優(yōu)點： （1） const 常量有數(shù)據(jù)類型，而宏常量沒有數(shù)據(jù)類型。編譯器可以對前者進行類型安全檢查。而對后者只進行字符替換，沒有類型安全檢查，并且在字符替換可能會產生意料不到的錯誤（邊際效應）。 （2） 有些集成化的調試工具可以對 const 常量進行調試，但是不能對宏常量進行調試。
3、常量定義規(guī)則
需要對外公開的常量放在頭文件中，不需要對外公開的常量放在定義文件的頭部。為便于管理，可以把不同模塊的常量集中存放在一個公共的頭文件中。
如果某一常量與其它常量密切相關，應在定義中包含這種關系，而不應給出一些孤立的值。例如： const float cnfRadius = 100.0f; const float cnfDiameter = cnfRadius * 2;
六、函數(shù)設計
函數(shù)接口的兩個要素是參數(shù)和返回值。C 語言中，函數(shù)的參數(shù)和返回值的傳遞方式有兩種：值傳遞（pass by value）和指針傳遞（pass by pointer）。
1、函數(shù)頭注釋
每個函數(shù)都要有函數(shù)頭注釋。注釋內容包含功能說明（brief）、函數(shù)名（function name）、參數(shù)說明（param）、返回值(return)等。
/*!
*@brief Initialises an i2c device and its control structure.
* function name: sk_hdi_i2c_init
* @param: pInitParas: A pointer to an initialisation parameter block
* @return SK _NO_ERROR: no errors
*/
2、參數(shù)的規(guī)則
參數(shù)的書寫要完整，不要貪圖省事只寫參數(shù)的類型而省略參數(shù)名字。如果函數(shù)沒有參數(shù)，則用 void 填充。參數(shù)命名要恰當，順序要合理。參數(shù)的順序應將目的參數(shù)放在前面，源參數(shù)放在后面。如果參數(shù)是指針，且僅作輸入用，則應在類型前加 const，以防止該指針在函數(shù)體內被意外修改。避免函數(shù)有太多的參數(shù)，參數(shù)個數(shù)盡量控制在 5 個以內。不要使用類型和數(shù)目不確定的參數(shù)。不要出現(xiàn)與業(yè)務無關的輸入參數(shù)。應明確規(guī)定對接口函數(shù)參數(shù)的合法性檢查由函數(shù)的調用者、還是由接口函數(shù)本身負責。缺省是由函數(shù)編寫者負責，除非函數(shù)內部無法判斷參數(shù)的合法性(比如指針所指向的空間大小，這時調用者必須保證空間足夠)。
非調度函數(shù)應減少或限制控制參數(shù)，盡量只使用數(shù)據(jù)參數(shù)。此規(guī)則的目的是防止函數(shù)間的控制耦合。調度函數(shù)是指根據(jù)輸入的消息類型或控制命令，來啟動相應的函數(shù)，而本身并不完成具體功能。控制參數(shù)是指改變函數(shù)功能行為的參數(shù)，即函數(shù)要根據(jù)此參數(shù)來決定具體怎么工作。非調度函數(shù)的控制參數(shù)增加了函數(shù)間的控制耦合，很可能使函數(shù)間的耦合度增大，并使函數(shù)的功能不唯一。
如下函數(shù)構造不太合理：
int add_sub(int a, int b, unsigned char add_sub_flg)
{
if (add_sub_flg == INTEGER_ADD)
{
return (a + b);
}
else
{
return (a - b);
}
}
更好的做法是分成兩個函數(shù)：
int add(int a, int b)
{
return (a + b);
}
int sub(int a, int b)
{
return (a - b);
}
在調用函數(shù)填寫參數(shù)時，應盡量減少沒有必要的默認數(shù)據(jù)類型轉換或強制數(shù)據(jù)類型轉換，因為數(shù)據(jù)類型轉換或多或少存在危險(建議：將編譯器的所有警告開關全部打開，讓編譯器幫助發(fā)現(xiàn)此類危險)。
3、返回值的規(guī)則
不要省略返回值的類型。規(guī)定任何 C++/ C 函數(shù)都必須有類型。如果函數(shù)沒有返回值，那么應聲明為 void 類型。返回應該返回的數(shù)據(jù)。函數(shù)名字與返回值類型在語義上不可沖突。不要將正常值和錯誤標志混在一起返回。正常值用輸出參數(shù)獲得，而錯誤標志用 return 語句返回。
函數(shù)除了有正常的返回值，也應該有表示出錯情況的返回值。如果二者不可兼得，應該使用異常機制。有時候函數(shù)原本不需要返回值，但為了增加靈活性如支持鏈式表達，可以附加返回值。
4、函數(shù)內部實現(xiàn)的規(guī)則
不同功能的函數(shù)其內部實現(xiàn)各不相同，看起來似乎無法就“內部實現(xiàn)”達成一致的觀點，但可以在函數(shù)體的“入口處”和“出口處”從嚴把關，從而提高函數(shù)的質量。
在函數(shù)體的“入口處”，對參數(shù)的有效性進行檢查。在函數(shù)體的“出口處”，對 return 語句的正確性和效率進行檢查。 注意事項如下： （1）return 語句不可返回指向“棧內存”的“指針”或者“引用”，因為該內存在函數(shù)體結束時被自動銷毀。
（2）要搞清楚返回的究竟是“值”、“指針”還是“引用”。
（3）如果函數(shù)返回值是一個對象，要考慮 return 語句的效率。例如?return String(s1 + s2); 我們不要將? return int(x + y); // 創(chuàng)建一個臨時變量并返回它 寫成 int temp = x + y; return temp;
5、其他規(guī)則
函數(shù)的功能要單一，不要設計多用途的函數(shù)。一個復雜的功能可由多個功能單一的函數(shù)實現(xiàn)。函數(shù)體的規(guī)模要小，盡量控制在 100 行代碼之內(不包含注釋和空行)。盡量避免函數(shù)帶有“記憶”功能。相同的輸入應當產生相同的輸出。不僅要檢查輸入參數(shù)的有效性，還要檢查通過其它途徑進入函數(shù)體內的變量的有效性，例如全局變量、文件句柄等。用于出錯處理的返回值一定要清楚，讓使用者不容易忽視或誤解錯誤情況。循環(huán)、分支層次不要超過 5 層。共用代碼應提取出來定義成獨立的工具類函數(shù)。復雜的邏輯需提取出去做成“幫助函數(shù)”。將可能的變化封裝成函數(shù)。明確函數(shù)功能，精確(而不是近似)地實現(xiàn)函數(shù)設計。盡量不使用遞歸函數(shù)，盡可能從算法上消除遞歸，能用迭代的、堅決不能使用遞歸。如果不能消除遞歸，則用自行管理堆棧的形式來消除形式上的遞歸。不要編寫依賴于其他函數(shù)內部實現(xiàn)的函數(shù)，此為函數(shù)獨立性的基本要求。功能不明確較小的函數(shù)，特別是僅有一個上級函數(shù)調用它時，應考慮把它合并到上級函數(shù)中、而不必單獨存在。對于所調用函數(shù)的錯誤返回碼要仔細、全面的處理。
6、使用斷言
使用斷言捕捉不應該發(fā)生的非法情況。不要混淆非法情況與錯誤情況之間的區(qū)別，后者是必然存在的并且是一定要作出處理的。在函數(shù)的入口處，使用斷言檢查參數(shù)的有效性（合法性）。在編寫函數(shù)時，要進行反復的考查，并且自問：“我打算做哪些假定？”一旦確定了的假定，就要使用斷言對假定進行檢查。防錯設計的編程風格可能會隱瞞錯誤。當進行防錯設計時，如果“不可能發(fā)生”的事情的確發(fā)生了，則要使用斷言進行報警。正式的軟件產品中應將斷言及其他調試代碼去掉(即將所有調試開關關掉)。
七、指針與數(shù)組
避免數(shù)組或指針的下標越界，特別要當心發(fā)生“多 1”或者“少 1”操作。使用指針前需先判斷指針是否為 NULL。用 free 或 delete 釋放了內存之后，立即將指針設置為 NULL，防止產生“野指針”。常量字符串的內容是不可以被修改的。不能對數(shù)組名進行直接復制與比較。如果函數(shù)的參數(shù)是一個指針，不要指望用該指針去申請動態(tài)內存。如果非得要用指針參數(shù)去申請內存，那么應該改用“指向指針的指針”。指針變量在創(chuàng)建的同時應當被初始化，要么將指針設置為 NULL，要么讓它指向合法的內存。指針操作不能超越了變量的作用范圍。
八、其他規(guī)則
不要一味地追求程序的效率，應當在滿足正確性、可靠性、健壯性、可讀性等質量因素的前提下，設法提高程序的效率。以提高程序的全局效率為主，提高局部效率為輔。在優(yōu)化程序的效率時，應當先找出限制效率的“瓶頸”，不要在無關緊要之處優(yōu)化先優(yōu)化數(shù)據(jù)結構和算法，再優(yōu)化執(zhí)行代碼。有時候時間效率和空間效率可能對立，此時應當分析那個更重要，作出適當?shù)恼壑?。例如多花費一些內存來提高性能、或者以空間換效率。不要追求緊湊的代碼，因為緊湊的代碼并不能產生高效的機器碼。當心那些視覺上不易分辨的操作符發(fā)生書寫錯誤。 我們經常會把“＝＝”誤寫成“＝”，像“||”、“&&”、“<=”、“>=”這類符號也很容易發(fā)生“丟 1”失誤。然而編譯器卻不一定能自動指出這類錯誤。變量（指針、數(shù)組）被創(chuàng)建之后應當及時把它們初始化，以防止把未被初始化的變量當成右值使用。當心變量的初值、缺省值錯誤，或者精度不夠。當心數(shù)據(jù)類型轉換發(fā)生錯誤。盡量使用顯式的數(shù)據(jù)類型轉換（讓人們知道發(fā)生了什么事），避免讓編譯器輕悄悄地進行隱式的數(shù)據(jù)類型轉換。當心變量發(fā)生上溢或下溢，數(shù)組的下標越界當心忘記編寫錯誤處理程序，當心錯誤處理程序本身有誤當心文件 I/O 有錯誤避免編寫技巧性很高代碼不要設計面面俱到、非常靈活的數(shù)據(jù)結構如果原有的代碼質量比較好，盡量復用它。但是不要修補很差勁的代碼，應當重新編寫盡量使用標準庫函數(shù)和公共函數(shù)，不要“發(fā)明”已經存在的庫函數(shù)盡量不要使用與具體硬件或軟件環(huán)境關系密切的變量把編譯器的選擇項設置為最嚴格狀態(tài)如果可能的話，使用 PC-Lint、LogiScope 等工具進行代碼審查?？勺x性第一、效率第二。先將眼前的問題解決掉、解決好，再考慮將來的擴展問題先寫出可用的代碼，反復推敲，再考慮是否需要重用的問題。先寫出可用、簡單、明顯沒有 bug 的代碼，再考慮測試的問題高內聚、低耦合。僅引用需要的頭文件系統(tǒng)運行之處，要初始化有關變量及運行環(huán)境，防止未經初始化的變量被引用
九、總結
以上為目前工作中總結出的編碼規(guī)范，后續(xù)會不斷完善，如有問題歡迎指正與補充
?
柚子快報激活碼778899分享：c語言 C 語言編碼規(guī)范
精彩文章
本文內容根據(jù)網絡資料整理，出于傳遞更多信息之目的，不代表金鑰匙跨境贊同其觀點和立場。
轉載請注明，如有侵權，聯(lián)系刪除。
UMKA出海優(yōu)選集
