c語言編程規范華為
A. 用華為c語言編碼規范會不會侵權
只是編碼和命名規范應該是沒問題的，又不是代碼。
B. 華為編程規范
華為編程規范舉例：
1-1：程序塊要採用縮進風格編寫，縮進的空格數為4個。
說明：對於由開發工具自動生成的代碼可以有不一致。
1-2：相對獨立的程序塊之間、變數說明之後必須加李余空行。
1-3：較長的語句（>80字元）要分成多行書寫，長表達式要在低優先順序操作符處劃分新行，操作符放在新行之首，劃分出的新行要進行適當的縮進，使排版整齊，語句可讀。
1-4：不允許把多個短語句寫在一行中，即一行只寫一條語句。
1-5：if、for、do、while、case、switch、default等語句自佔一行，且if、for、do、while等語句的執行語句部分無論多少都要加括弧{}。
1-6：對齊只使用空格鍵，不使用TAB鍵。
說明：以免用不同的編輯器閱讀程序時，因TAB鍵所設置的空格數目不同而造成程序布局不整齊，不要使用BC作為編輯器合版本，因為BC會自動將8個空格變為一個TAB鍵，因此使用BC合入的版本大多會將縮進變亂。
1-7：函數或過程的開始、結構的定義及循環、判斷等語句中的代碼都要採用縮進風格，賀伏case語句下的情況處理語句也要遵從語句縮進要求。
1-8：程序塊的分界符（如C/C++語言的大括弧『{』和『}』）應各獨佔一行並且位於同一列，同時與引用它們的語句左對齊。在函數體的開始、類的定義、結構的定義、枚舉的定義以及if、for、do、while、switch、case 語句中的程序都要採用如上的縮進方式。
1-9：一行程序以小於80字元為宜，不要寫得過長。
2-1：一般情況下，源程序有效注釋量必須在20％以上。
說明：注釋的原則是有助於對程序的閱讀理解，在該加的地方都加了，注釋不宜太多也不能太少，注釋語言必須准確、易懂、簡潔。
2-2：文件頭部應進行注釋，注釋必須列出：版權說明、版本號、生成日期、作者、內容、功能、修改日誌等。
示例：下面這段頭文件的頭注釋比較標准，當然，並不局限於此格式，但上述信息建議要包含在內。
2-3：函數頭部應進行注釋，列出：函數的目的/功能、輸入參數、輸出參數、返回值、調用關系（函數、表）等。
示例：下面這段函數的注釋比較標准，當然，並不局限於此格式，但上述信息建議要包含在內。
2-4：邊寫代碼邊注釋，修改代碼同時修改相應的注釋，以保證注釋與代碼的一致性。不再有用的注釋要刪除。
2-5：注釋的內容要清楚、明了，含義准確，防止注釋二義性。
說明：錯誤的注釋不但無益反而有害。
2-6：注釋應與其描述的代碼相近，對代碼的注釋應放在其上方或右方（對單條語句的注釋）相鄰位置，不可放在下面，如放於上方則需與其上面的代碼用空行隔開。
2-7：對於所有有物理含義的變數、常量，如果其命名不是充分自注釋的，在聲明時都必須加以注釋，說明其物理含義。變數、常量、宏的注釋應放在其上方相鄰位置或右方。
2-8：數據結構聲明(包括數組、結構、類、枚舉等)，如果其命名不是充分自注釋的，必須加以注釋。對數據結構的注釋應放在其上方相鄰位置，不可放在下面；對哪拍滾結構中的每個域的注釋放在此域的右方。
2-9：全局變數要有較詳細的注釋，包括對其功能、取值范圍、哪些函數或過程存取它以及存取時注意事項等的說明。
2-10：注釋與所描述內容進行同樣的縮排。
說明：可使程序排版整齊，並方便注釋的閱讀與理解。
2-11：避免在一行代碼或表達式的中間插入注釋。
說明：除非必要，不應在代碼或表達中間插入注釋，否則容易使代碼可理解性變差。
2-12：通過對函數或過程、變數、結構等正確的命名以及合理地組織代碼的結構，使代碼成為自注釋的。
說明：清晰准確的函數、變數等的命名，可增加代碼可讀性，並減少不必要的注釋。
2-13：在代碼的功能、意圖層次上進行注釋，提供有用、額外的信息。
說明：注釋的目的是解釋代碼的目的、功能和採用的方法，提供代碼以外的信息，幫助讀者理解代碼，防止沒必要的重復注釋信息。
C. 我想自學c語言 求推薦一本通俗易懂的好書 因為開學還有1個月 所以想自學試試 謝謝
譚浩強的C程序設計，國內最普遍襪粗激使用的C入門教材，講解告襪清晰易懂
看完上面那本，看Stephen Prata的C Primer Plus，因為凳鏈譚浩強的書還有很多東西沒講清楚甚至沒講，通過這本書可以對C有更進階的了解
D. 華為c語言編程規范是怎樣的
代碼總體原則
清晰第一。清晰性是易於維護、易於重構的程序必須具備的特徵。
簡潔為美。簡介就是易於理解並且易於實現。
選擇合適的風格，與源代碼風格保持一致。
頭文件
頭文件的設計體現了大部分的系統設計，不合理的頭文件布局是編譯時間過長的根因，實際上是不合理的設計。
頭文件中適合放置介面的聲明，不適合放置實現。
頭文件應當職責單一。
頭文件應向穩定的方向包含。
每一個.c文件應有一個同名的.h文件，用於聲明需要對外公開的介面。
禁止頭文件循環依賴。
禁止包含用不到的頭文件。
頭文件應當自包含。
編寫內部#include保護符(#define保護)。
禁止在頭文件中定義變數。
只能通過包含頭文件的方式使用其他C提供的介面，禁止在C中通過extern的方式使用外部函數介面和變數。
禁止在extern "C"中包含頭文件。
函數
函數設計的精髓：編寫整潔函數，同事把代碼有效組織起來。
一個函數僅完成一個功能。
重復代碼應該盡可能提煉成函數。
避免函數過長，新增函數不超過50行。
避免函數的代碼塊嵌套過深，新增函數的代碼塊嵌套不超過4層。
可重入函數應避免使用共享變數；若需要使用，則應該通過互斥手段對其加以保護。
對參數的合法性檢查，由調用者負責還是介面函數負責，應在項目組模塊內統一規定。預設由調用者負責。
對函數的錯誤返回碼要全面處理。
設計高扇入，合理扇出（小於7）的函數。扇出是指調用其它函數的數目。扇入是指有多少上級函數調用它。
廢棄代碼要及時清除。
函數參數不變使用const限定。
函數應避免使用全局變數、靜態局部變數和I/O操作，不可避免的地方應集中使用。
檢查函數所有非參數輸入的有效性，如數據文件、公共變數等。
函數的參數個數不超過5個。
在源文件范圍內聲明和定義的所有函數，除非外部可見，否則應該加static關鍵字。
標識符
標識符的命名要清晰、明了，有明確含義，同時使用完整的單詞或大家基本可以理解的縮寫，避免使人產生誤解。
產品、項目組內應保持同意的命名分格。
盡量避免名字中出現數字編號，除非邏輯上確實需要。
重構、修改部分代碼時，應該保持和原有代碼風格一致。
文件命令統一採用小寫字元。因為不同系統對文件名大小寫處理會有不同（windows不區分大小寫，但是linux系統則區分）。
全局變數應增加「g_」前綴。
靜態變數應增加「s_」前綴。
禁止使用單位元組命名變數，但是允許定義i,j,k作為局部循環變數。
不建議使用匈牙利命名法。
對於數值或者字元串常量的定義，建議採用全大寫字母，單詞之間加下劃線的方式命名。
變數
結構功能單一，不要設計面面俱到的數據結構。
不用或者少用全局變數
防止局部變數與全局變數同名
通訊過程中使用的機構，必須注意位元組序。
嚴禁使用未經初始化的變數作為右值。
使用面向介面編程思想，通過API訪問數據。
盡量減少沒有必要的數據類型默認轉換與強制轉換。
宏和常量
用宏定義表達式時，要使用完備的括弧。
將宏定義的多條表達式放在大括弧中。
使用宏時，不允許參數發生變化。
不允許直接使用魔鬼數字。
除非必要，應盡可能使用函數代替宏。
常量建議用const定義代替宏。
質量
時刻注意易混淆的操作符
必須了解編譯系統的內存分配方式，特別是編譯系統對不同類型的變數的內存分配規則，如局部變數在何處分配、靜態變數在何處分配等。
不僅關注介面，同樣要關注實現。
禁止內存操作越界。
禁止內存泄漏。
禁止引用已經釋放的內存空間。
編程時，要防止差1錯誤。
switch語句必須有default分支。
函數中分配的內存，在函數退出之前要釋放。
不要濫用goto語句。
時刻注意表達式是否會上溢、下溢。
程序效率
在保證軟體系統的正確性、簡潔、可維護性、可靠性及可測試性的前提下，提高代碼的效率。
通過對數據結構、程序演算法的優化來提高效率。
將不變條件的計算移到循環體外。
對於多維大數組，避免來回跳躍式訪問數組成員。
創建資源庫，以減少分配對象的開銷。
將多次被調用的「小函數」改為inline函數或者宏實現。
注釋
優秀的代碼可以自我解釋，不通過注釋即可輕易讀懂。
注釋的內容要清楚、明了，含義准確，防止注釋二義性。
修改代碼時，維護代碼周邊的所有注釋，以保證注釋與代碼的一致性。不再有用的注釋要刪除。
文件頭部應進行注釋，注釋需要列出：版權說明、版本號、生成日期、作者姓名、工號、內容、功能說明、與其他文件的關系、修改日誌等，頭文件的注釋中還應有函數功能的說明。
函數聲明處注釋描述函數功能、性能及用法，包括輸入和輸出參數、函數返回值、可重入的要求等；定義處詳細描述函數功能和實現要點，如實現的簡要步驟、實現的理由、設計約束等。
全局變數要有詳細的注釋，包括對其功能、取值范圍以及存取時注意事項等的說明。
盡量採用工具可以識別的格式注釋。
排版與格式
程序塊採用縮進風格編寫，每級縮進為4個空格。
相對獨立的程序塊之間、變數說明之後必須加空行。
一行只寫一條語句。
對等操作兩邊加空格，注釋符與內容之間加空格。
編譯
使用編譯器的最高告警級別，理解所有的告警，通過修改代碼而不是降低告警級別來消除所有告警。
在產品軟體中，要統一編譯開關、靜態檢查選項以及相應告警清除策略。
可測性
模塊劃分清晰，介面明確，耦合性小，有明確輸入和輸出，否則單元測試實施困難。
在統一項目組或產品組內，調測列印的日誌要有統一的規定。
使用斷言記錄內部假設。
不能用斷言來檢查運行時錯誤。
E. 華為編程規范
如果您的華為手機忘記鎖屏密碼，您可以參考如下方式解決：
1、EMUI 5.0及以上的系統忘記密碼，只能通過強制恢復出廠設置清除拆碧租密碼。這個方法會清除您之前的數據，慧盯請謹慎操作。
操作步驟：
1) 手機在關機狀態、不插USB線的情況下，同時長按音鍵上鍵和電源鍵，直到顯示開機logo界面時，松開電源鍵；
2) 3 秒旅兆後再松開音量上鍵，即可進入 Recovery 模式；
3) 進入後，選擇恢復出廠設置。（通過音量鍵上下移動，開關機鍵確定）
2、EMUI 5.0以下的系統忘記密碼，在確保手機開機、聯網、已登錄華為賬號、已打開「查找我的手機」（手機找回）功能時，可通過「遠程鎖定」修改密碼。
F. 華為c語言編程規范是怎樣的
鏈接:
《華為編程規范與範例》是一本計算機編程應用類書籍。
G. c語言編寫程序時的注意事項
在進行C語言編寫程序時，需要注意以下幾點：
1. 編寫規范：要遵守C語言的編程規范，如變數命名規范、縮進、注釋等。編寫規范的代碼易於維護和理解，且可以提高代碼質量。
2. 內存管理：C語言中需要手動管理內存，包括內存分配、釋放等。要注意內存泄漏和指針錯誤等問題，避免程序崩潰或數據臘運損壞等情況。
3. 安全性輪旅梁：C語言對數據的邊界檢查並不嚴格，容易受到緩沖區溢出等安全問題的攻擊。在編寫程序時需要考慮安全性，包括輸入的數據驗證、防範攻擊等。
4. 錯誤處理：C語言中需要處理各種可能出現的錯誤，包括語法錯誤、運行時錯誤、編譯錯誤等。需要使用錯誤處理機制來處理這些錯誤，保證程序運行的穩定性和安全性。
5. 代碼復用性：C語言中可以使用函數和模塊化的方式來提高代碼的復用性。需要把相關的功能封裝成函數或模塊鎮辯，以便在程序的不同部分進行重用，提高代碼效率和可維護性。
除此之外，還需要注意代碼的可讀性和可維護性。編寫清晰易懂的代碼，遵守編程規范，注重代碼注釋，是提高代碼可讀性和可維護性的有效方法。
H. c語言中的switch語句，使用時應注意哪些
c語言中的switch語句，使用時應注意哪些？
Switch語句編程規范總結：
【規則1】每個case 語句的結尾不要忘了加break，否則將導致多個分支重疊（除非有意使多個分支重疊）。
【規則2】不要忘記最後那個default 分支。即使程序真的不需要default 處理，也應該保留語句 default : break; 這樣做並非多此一舉，而是為了防止別人誤以為你忘了default 處理。
【規則3】 在使用switch語句時，不管case分支中有幾條語句，都是用」{}」將其括起來。
課本上的
華為c8812使用時應注意哪些？
東西買來就是用，別拿來摔就好，一般手機質量最好的也就用3-5年吧，等過了幾年，基本落伍到掉牙了，相信你也不會用了。大膽用。用壞了只要不是摔的，進水的，然後拿去保修，過了保修的手機壞了再換。
液氮使用時應注意哪些問題？
班德液氮罐提醒大家在實驗室中使用液氮的一些注意事項：
1.正確培訓
2.了解如攔悔正何儲存和運輸液氮
3.穿實驗室外套，面罩和絕緣手套
4.在通風良好的地方工作
5.當您獨自一人在實驗室待幾個小時時，請勿使用液氮
6.如果可能，運輸液氮時不要進入電梯或密閉空間
7.不要潛入儲存容器中以檢索掉樣品
8.切勿在密閉容器中使用液氮
9.切勿將液氮倒入水槽
10.注意爆炸的低溫筒
php 抽象類使用時應注意哪些
php抽象類使用要點與注意事項如下：
1、用 abstract 來修飾一個類，那麼這個類就是抽象類；抽象類絕對不能被實例化，即$abc = new 抽象類名();會報錯。
2、用abstract 來修飾一個方法，那麼該方法就是抽象方法；
3、如果類中有一個抽象方法，那麼該類就必須定義為抽象類；但反過來，抽象類里並不一定要有抽象方法。另外，抽象類里也可以有普通方法。
4、抽象方法不能有方法體。即abstract function abc();------後面不能加大括弧{.........}。
5、一個類繼承了某個抽象類，那麼，它必須實現抽象類中所有的抽象方法（除非簡悔，它也這些抽象方法聲明為抽象的，相當於抽象類繼承了抽象類）。
抽象類簡單實例：
<?php
abstract class Animal{
public $name;
protected $price;
abstract function cry();
}
class Dog extends Animal{
function cry(){
echo "汪汪...";
}
}
$abc = new Animal();
?>
希望本文所述對大家的php程序設計有所幫助。
潤滑脂使用時應前含注意哪些問題
1、加註潤滑脂的量要適當
加脂量過大，會使摩擦力矩增大，溫度升高，耗脂量增大；而加脂量過少，則不能獲得可靠潤滑而發生干摩擦。一般來講，適宜的加脂量為軸承內總空隙體積的1/3~1/2。但根據具體情況，有時則應在軸承邊緣塗脂而實行空腔潤滑。
2、不同種類、牌號及新舊潤滑脂不可混用
避免裝脂容器和工具的交叉使用，否則，將對脂產生滴點下降，錐入度增大和機械安定性下降等不良影響。
3、更換新脂有哪些注意事項？
由於潤滑脂品種、質量都在不斷地改進和變化，老設備改用新潤滑脂時，應先經試驗，試用後方可正式使用；在更換新脂時，應先清除廢潤滑脂，將部件清洗干凈。在補加潤滑脂時，應將廢潤滑脂擠出，在排脂口見到新潤滑脂時為止。
4、重視加註潤滑脂的操作過程
在領取和加註潤滑脂前，要嚴格注意容器和工具的清潔，設備上的供脂口應事先擦拭乾凈，嚴防機械雜質、塵埃和砂粒的混入。
5、季節用脂要及時更換
如設備所處環境的冬季和夏李的溫差變化較大，如果夏季用了冬季的脂或者相反，結果都將適得其反。
6、注意定期加換潤滑脂
潤滑脂的加換時間應根據具體使用情況而定，既要保證可靠的潤滑又不至於引起脂的浪費。
7、不要用木製或紙制容器包裝，以防潤滑脂失油變硬、混入水分或被污染變質。注意存放於陰涼乾燥的地方。
離心機使用時應注意哪些問題
- 開機進清水調差速，帶差速都了再進料
-
關機前千萬記得清水清洗干凈，以免影響下次開機。
-
按照維護說明書，及時潤滑，更滑油脂，使用專用的油脂
殺菌劑使用時應注意哪些問題
殺菌劑使用七注意
1.使用濃度
用液劑噴霧時，往往需用水將葯劑配成或稀釋成適當的濃度，濃度過高會造成葯害和浪費，濃度過低則無效。有些非可濕性的或難於濕潤的粉劑，應先加水少許，將葯粉調成糊狀，然後再加水配製，也可以在配製時添加一些濕潤劑。
2.噴葯時間
噴葯的時間過早會造成浪費或降低防效，過遲則大量病原物已經侵入寄主，即使噴內吸治療劑，也收效不大，應根據發病規律和當時情況或根據短期預測及時把在沒有發病或剛剛發病時就噴葯保護。
3.噴葯次數
噴葯次數主要根據葯劑殘效期的長短和氣象條件來確定，一般隔10天～15天噴一次，共噴2次～3次，雨後補噴，應考慮成本，節約用葯。
4.噴葯質量
噴葯量要適宜，過少就不能對植株各部都周密地加以保護，過多則浪費甚至造成葯害，噴葯要求霧點細，噴得均勻，對植物應保護的各部包括葉片的正面和反面都要噴到。
5.葯害問題
噴葯對植物造成葯害有多種原因，水溶性較強的葯劑容易發生葯害，不同作物對葯劑的敏感性也不同，例如波爾多液一般不會造成葯害，但對銅敏感的作物也可以產生葯害。豆類、馬鈴薯、棉花則對石硫合劑敏感。作物的不同發育階段對葯劑的反應也不同，一般幼苗和孕穗開花階段容易產生葯害。另外與氣象條件也有關系，一般以氣溫和日照的影響較為明顯，高溫、日照強烈或霧重、高濕都容易引起葯害。
6.如何混用
一般遇鹼性物質易分解失效的農葯，不能與鹼性物質混用，例如，鹼性殺菌劑如波爾多液、石硫合劑等不能和1605、樂果、敵敵畏等混合使用。混合後產生化學反應能引起葯害的葯劑也不能混合施用，例如，石硫合劑和1605混合，不僅會降低葯效，還會加重葯害。混合後產生乳劑破壞現象或產生大量沉澱的農葯也不能混合使用，具體哪些葯劑能或不能混合，使用說明書上可查到。
有少數農葯混合後起增效作用。例如，樂果中性和酸性殺菌性如代森鋅、可濕性硫磺、膠體硫等混用，葯效不僅不受影響，反而略可提高。
7.抗葯性問題
長期使用單一的葯劑（主要是內吸殺菌劑），就會導致病原物產生抗葯性，使所用的葯劑失效。為避免這一問題，可交替使用不同類型的葯劑，或內吸性殺菌劑和傳統性殺菌性混合使用。
制砂機使用時應注意哪些問題？
朋友，在使用制砂機等礦山設備過程中，要正確的使用設備，要注意自己的人身安全！介紹下面幾點希望對你有幫助：
1、不要隨便更換皮帶輪，以防轉速過高使粉碎室產生爆炸，或轉速太低影響制砂機的工作效率。
2、制砂機安裝完後要檢查各部緊固件的緊固情況，若有松動予以擰緊。同時要檢查皮帶松緊度是否合適。
3、制砂機起動前，先用手轉動轉子，檢查一下齒爪、錘片及轉子運轉是否靈活可靠，殼內有無碰撞現象，轉子的旋轉方向是否與機箭頭所指方向一致，動力機及制砂機潤滑是否良好。
4、制砂機起動後應先空轉2~3min，沒有異常現象後再投料工作。
5、制砂機和動力機組應安裝牢固。若制砂機長期固定作業，應將其固定在水泥基礎上；若制砂機是流動作業，機組應安裝在用角鐵製成的機座上，並且保證動力機（柴油機或電動機）和制砂機的皮帶輪槽處於同一回轉平面。
C語言switch語句使用
switch(a);不要分號
swhich後面沒有分號
安全帽的作用及使用時應注意哪些
安全帽的作用：
從安全帽的外型上看十分圓滑.當配戴者受到較小高處落物打擊時,物體可順利地沿帽殼的圓弧滑落;當受到較大高處落物打擊時.因帽殼與帽襯之間有25—50的垂直距離,當受到水平方向物體打擊時.帽殼與帽村之間有5一:20的水平距離,這兩個空間距離起到了對外力的吸收和緩沖作用,不但物體不能直接打到頭部.而且堅硬的帽殼也不會接觸頭部.避免了帽殼的間接傷害.
注意事項：
1.配戴者必須系好下頦帶.防止安全帽掉落。
2.注意安全帽的保質期，過期的安全帽起不到保護作用。
I. C語言的編程格式是怎麼樣的
C語言源程序的編程格式歸納如下:
1,強制性規則
1,一個C語言源程序必須有且只有一個MAIN函數.
2,函數名後必須緊跟圓括弧對,函數體放在右圓括弧")"後的花括弧對"{}"中.
3,每個程序體(包括函數的函數體,含有多條語句的選擇結構和循環結構中的語句序列)必須用一對花括弧括起來.
4,文件包含預處理命令,#INCLUDE<*.H>應置於源程序的開始位置.
5,語句未尾必須有分號,而預處理命令和函數首部的未尾及右花括弧之後不要分號.
6,同一字母大,小寫意義不同,關鍵字和標准庫函數名必須用小寫.
7,變數必須先定義,後使用
8,除已有明顯間隔符外,標識符,關鍵字之間必須有至少一個空格
9,註解必須包含在"/* */符號之間
J. 有誰知道C語言程序的編程規范，給我概括一下，
1引言
1.1編寫目的
在軟體開發過程中，編碼的工作量是相當大的，同一項目參與編程的人可能有各自編程的經驗和習慣，不同風格的程序代碼使維護工作變得復雜和困難。為了提高代碼的可讀性、系統的穩定性及降低維護和升級的成本，特編寫本規范以統一各開發人員的編程工作。
1.2 適用對象
本規范適用於所有開發人員，包括應用程序、網頁及資料庫開發人員，及有關的程序測試人員。
1.3 引用標准
GB/T 11457 軟體工程術語
GB 8566 計算機軟體開發規范
GB 8567 計算機軟體產品開發文件編制指南
2．編寫要求
2.1一般代碼規則
可讀性原則，這是評價程序質量的首選指標，寧可不要一些技巧也要保證程序的易讀特性，不要因過分追求技巧而犧牲程序的可讀性。
功能獨立性原則。每一程序塊只完成一個獨立的功能，反過來，每一獨立的功能只在一程序塊內完成，盡量低耦合、高內聚。
提示說明應當簡短且避免產生歧義。
提示或警告信息應當具有向導性，能准確告訴用戶錯誤原因及恢復方法。提示和警告對話框應當使用標准規范。
快捷鍵的定義必須符合用戶操作習慣。
程序需要長時間處理或等待時，應當顯示進度條並提示用戶等待。
一些敏感操作，如刪除等操作在執行前必須提示用戶確認。
2.2變數、函數、過程、控制項等命名規則
2.2.1 變數命名
變數命名採用[作用范圍][數據類型][自定義名稱]規則定義，並遵循匈牙利命名法。要求看到變數名就能直觀的看出其范圍和數據類型。
匈牙利命名規則：
a Array 數組
b BOOL (int) 布爾(整數)
by Unsigned Char (Byte) 無符號字元(位元組)
c Char 字元(位元組)
cb Count of bytes 位元組數
cr Color reference value 顏色(參考)值
cx Count of x (Short) x的集合(短整數)
dw DWORD (unsigned long) 雙字(無符號長整數)
f Flags (usually multiple bit values) 標志(一般是有多位的數值)
fn Function 函數
g_ global 全局的
h Handle 句柄
i Integer 整數
l Long 長整數
lp Long pointer 長指針
m_ Data member of a class 一個類的數據成員
n Short int 短整數
p Pointer 指針
s String 字元串
sz Zero terminated String 以0結尾的字元串
tm Text metric 文本規則
u Unsigned int 無符號整數
ul Unsigned long (ULONG) 無符號長整數
w WORD (unsigned short) 無符號短整數
x,y x, y coordinates (short) 坐標值/短整數
v void 空
作用范圍：
范圍 前綴 例子
全局作用域 g_ g_Servers
成員變數 m_ m_pDoc
局部作用域 無 strName
數據類型
VC常用前綴列表
前綴 類型 描述 例子
ch char 8位字元 chGrade
ch TCHAR 16位UNICODE類型字元 chName
b BOOL 布爾變數 bEnabled
n int 整型（其大小由操作系統決定） nLength
n UINT 無符號整型（其大小由操作系統決定） nLength
w WORD 16位無符號整型 wPos
l LONG 32位有符號整型 lOffset
dw DWORD 32位無符號整型 dwRange
p * 內存模塊指針，指針變數 pDoc
l p FAR* 長指針 lpDoc
lpsz LPSTR 32位字元串指針 lpszName
lpsz LPCSTR 32位常量字元串指針 lpszName
lpsz LPCTSTR 32位UNICODE類型常量指針 lpszName
h handle Windows對象句柄 hWnd
lpfn (*fn)() 回調函數指針 Callback Far pointer to
CALLBACK function lpfnAbort
2.2.2 函數、過程命名
函數或過程名的主體應該使用大小寫混合形式，並且應該足夠長以描述它的作用。而且，函數名應該以一個動詞起首，如 InitNameArray 或 CloseDialog。對於頻繁使用的或長的項，推薦使用標准縮略語以使名稱的長度合理化。一般來說，超過 32 個字元的變數名在 VGA 顯示器上讀起來就困難了。當使用縮略語時，要確保它們在整個應用程序中的一致性。在一個工程中，如果一會兒使用 Cnt， 一會兒使用 Count，將導致不必要的混淆。
對於自行編寫的函數，若是系統關鍵函數，則須在函數實現部分的上方標明該函數的信息，格式如下：
//======================================================
// 函 數 名：InsureHasOutputInfo
// 功能描述：確保有適當的輸出信息
// 輸入參數：nProctID:相應的產品ID
// 輸出參數：void
// 創建日期：00-2-21
// 修改日期：00-2-21
// 作 者：***
// 附加說明：
//======================================================
2.2.3 用戶定義類型
在一項有許多用戶定義類型的大工程中，常常有必要給每種類型一個它自己的三個字元的前綴。如果這些前綴是以 "u" 開始的，那麼當用一個用戶定義類型來工作時，快速識別這些類型是很容易的。例如，ucli 可以被用來作為一個用戶定義的客戶類型變數的前綴。
註：對於非通用的變數，請在定義時加以注釋說明，變數定義盡可能放在最開始處。
2.2.4 控制項命名
應該用一致的前綴來命名對象，使人們容易識別對象的類型。
VC常用宏定義命名列表
前綴 符號類型 符號例子 范圍
IDR_ 標識多個資源共享的類型 IDR_MAINFRAME 1~0x6FFF
IDD_ 對話框資源（Dialog） IDD_SPELL_CHECK 1~ 0x6FFF
HIDD_ 基於對話框的上下文幫助 HIDD_SPELL_CHECK 0x20001~0x26FF
IDB_ 點陣圖資源（Bitmap） IDB_COMPANY_LOGO 1~0x6FFF
IDC_ 游標資源（Cursor） IDC_PENCIL 1~0x6FFF
IDI_ 圖標資源（Icon） IDI_NOTEPAD 1~0x6FFF
ID_、IDM_ 工具欄或菜單欄的命令項 ID_TOOLS_SPELLING 0x8000~0xDFFF
HID_ 命令上下文幫助 HID_TOOLS_SPELLING 0x18000~0x1DFFF
IDP_ 消息框提示文字資源 IDP_INVALID_PARTNO 8~0xDFFF
HIDP_ 消息框上下文幫助 HIDP_INVALID_PARTNO 0x30008~0x3DFFF
IDS_ 字元串資源（String） IDS_COPYRIGHT 1~0x7FFF
IDC_ 對話框內的控制資源 IDC_RECALC 8~0xDFFF
2.3源代碼規則
2.3.1風格約定：採用縮進的格式保存程序的層次結構。要求能直觀的看出循環、判斷等層次結構。
每一個嵌套的函數塊，使用一個TAB縮進（可以設定為4個空格），大括弧必須放在條件語句的下一行，單獨成一行，便於匹對反大括弧應該在單獨的一行，在大多數情況下反擴號應有注釋內容。舉例如下：
if(condition1)
{
while(condition2)
{
…..
…..
}//end while(condition2)
}//end if (condition1)
或者
if(condition1){
while(condition2){
….
….
}//end while(condition2)
}//end if(conditionl)
2.3.2在操作符的前後必須使用空格。
2.3.3在分隔數組下標和函數參數的逗號後面必須添上空格。
2.3.4嚴禁使用go to 語句。
2.3.5對資料庫操作只能使用標准SQL語句，關鍵字必須使用大寫（如SELECT、WHERE等），數據元素（表、欄位、視圖等）必須按照數據字典書寫。
2.3.6程序代碼中要有足夠的容錯處理功能。
對可能發生的異常統一採用C++拋出格式：
try
{
//可能引發異常的代碼
throw t; //手工拋出異常
}
catch(type_1 e) // type_1為類型定義符、如int、CException、_com_error
{
// type_1類型異常處理
}
catch(type_2 e)
{
// type_2類型異常處理
}
2.3.7程序代碼結構必須層次清楚，適當使用空行分段。
2.3.8工程的版本控制要嚴格，版本格式為.me.ae.yy.mmdd，其中：[me]表示主版本號；[ae]表示輔版本號；[yy.mmdd]表示版本建立日期。高版本盡量兼容低版本的用法、數據或協議。
2．4文件的命名規則
2.4.1根據系統設計所規定的結構，建立相應的文件夾，根據需要建立子文件夾。
2.4.2文件夾和文件的名稱應盡量能夠表達其意義，盡量使用英文命名，絕對不能漢字。
2.4.3文件名稱一般採用「xxx_yyy.ext」格式，xxx(3-4個字母)表示分類，yyy(字母數自定)表示操作 (如 「 /example/exp_edit.htm 」)
\
我從公司文檔拷貝的！你自己看看對你有沒有用！