代碼規範體會篇

前言：這是好幾天前的一個流水帳的日誌類型，今天發佈我也懶得修改其中的許多錯誤了，有進來看的不要見怪啊

筆記（2月6號）：
與趙暢大佬合做的剛開始，分配了一些工做，首先來了一次完成此次做業的工做大體安排。因爲大佬的經理比個人多多了，所以，主要由大哥帶領我完成這次做業。
就先說此次的第一個任務分配吧，不作不知道，一作嚇一跳，個人任務是將咱們這次做業的代碼規範整理好，說實在話，由於以前對於這種代碼規範沒有絲毫的接觸，在一開始大哥和我說的時候，特地還給了我一份他找來的代碼規範模板（雖然我本身要找的話也會找，可是我沒有去找），而僅僅是這份代碼模板規範，才只是剛開始讓我心驚。大哥要求我在規定的時間完成，真的在一開始的時候真的不知道要怎麼制定好一份屬於咱們此次的做業的代碼規範，我把個人第一份大媽規範給大哥看了以後，（結果是什麼樣的相信你們應該也猜的出來的），而後大哥稍微詳細的給我解釋了一下這個代碼規範應該怎麼去制定，稍微更懂了一些的我就開始返工作第二次，我半懂的再一次修改了咱們的代碼規範，而後交給大哥去審查下，（估計是大哥實在看不下去個人效率了），結果雖然是比第一次好一點，確定是還有一些沒有作好的，終於，大哥本身動手給我示範的修改了一段，讓我模仿着完成接下來的代碼規範，哎，有了這樣的一個提示，最後咱們也算是終於把咱們的代碼規範給定了下來。
而這些前面說的一點點還只是此次的作代碼規範的任務的大體過程。。。
接下來再好好說一下具體作這幾回代碼規範的艱辛過程：
1.代碼規範之第一閱：首先大哥給了我一份他找來的某個公司的代碼規範的模板，咱們的代碼規範就是根據這個定出來的。一開始不知道具體要怎樣作這份代碼規範的時候，我是一段一段的把這份長達幾十頁的代碼規範認真的看完了，雖而後面會發現這個過程效率比較低，沒有把其中的主要的咱們用的上的總結出來，可是！此次的認真閱讀了一份代碼規範以後，收穫那可不是一兩句話能夠解釋的。舉幾個例子吧：程序縮進，對齊用空格鍵而不用tab鍵等等（這只是第一節的排版中的小收穫）還有第二節的註釋，第三節的標識符命名，第四節的可讀性中的不少內容。
2.代碼規範之第二改：通過，第一次大哥稍微詳細的說了一下怎麼作代碼規範以後，雖然還不是很是理解的我仍是繼續加以修改，這個過程，我又把這一整篇代碼規範看了一遍，就和前面同樣的了，那些平時不怎麼注意的細節記住了，還有一些壓根就不知道的也學到了，同時還解決了幾個之前就有疑問的點呢，好比說不能用tab 由於不一樣的編譯器或是其餘的可能會致使亂碼這個點之前就一直有一些納悶。
3.第二篇雖然相對更好了一些，可是仍是不夠簡潔，不適合咱們此次的做業所須要知足的代碼規範，通過大哥直接的給我演示了一小段制定過程以後，我終於仍是把這份代碼規範作的像樣了，以後再給大哥作了一些校對和補充。（好比函數名，變量名的命名要用駝峯法編名）
第一個任務之總結：收穫分兩塊，一個是作任務自己的收穫，另外一個就是和大佬合做的收穫了（我以爲是十分重要）。
簡要概述：
任務：作每一件任務的那些前期工做都是本身能夠事前準備的。懂得了不少之前沒有注意到的代碼規範細節，讓我在平時編寫代碼的時候會多注意這些。另一個就是在完成一個任務的過程當中，常常會遇到一些不如意的事情，甚至會有不少次須要從新返工開始，不能每一次都是半懂的就開始下一次，在開始每一次的時候都必定要比上一次好不少，有更大的把握以後再去從新開始，才能以最好的方法，最有效的方式作好。（就好比說這些的代碼規範的任務，我寫了三次，第一次的修改就差很少是白廢，什麼都沒有理解就開始作，花了很很長時間但效果卻很是低，第二次的修改雖然比第一次好一點，可是也是沒有理解好本次代碼規範的本質，作出來只是比第一次多刪除了一些而已，而第三次才真正的明白該怎麼作，最後才作好此次個人任務，估計大佬對個人工做效率也是很無奈啊）

合做：完成本次大佬安排的任務以後，很明顯的就發現個人辦事效率是很低的，一份代碼規範的任務我作了三次，每次仍是須要大佬的提示該怎麼作。因此通過這次的合做以後，對於與人合做的那種說不清的關係我仍是收穫了很是多的

2月11號：
通過一個晚上的查閱以後，這幾天大佬幾乎已經把此次的做業所須要的點都打完了，我也知道他用的應該大部分就是C++，在我對於C++的並無很熟的狀況下，我以爲狀況是很危急的，我必須本身再用C語言去把大體的思路寫出來，必須有我本身的的編碼思路，過程。
顯然一夜的查閱沒有結果是很讓人心煩的，也便是這樣，剛好大佬過來詢問了，毫無疑問就給了我一波心靈雞湯，本來不舒服的內心也舒坦多了，很感謝大佬的不斷支持，此次合做真的很是棒，接下來還有幾天，必定要好好的用心去編寫！
大佬帶領完成做業過程所教
1.代碼規範中的要求記憶的知識點：
A.程序塊要採用縮進風格編寫。對齊之能用空格鍵，不用Tab，縮進的空格數爲4個。（說明：對於開發工具自動生成的代碼能夠有不一致，使用Tab有可能會致使縮進格式編排混亂）

B.相對獨立的程序塊之間，變量說明以後必須加空行。（便於讓人理解這是分開的模塊）

C.註釋格式儘可能統一，建議使用/......../，語言儘可能統一（全英文或中文），爲了更準確的表達意思以及後續閱讀方便，建議統一使用中文。

D.標識符命名儘可能要準確，清晰，明瞭，儘可能使用英文全名或是易懂的縮寫，或者一些特殊約定或縮寫。有須要時，應加以註釋。

E.對於變量，函數，數組等命名，採用如下規則：

變量：採起小駝峯法，除第一個單詞以外，其餘單詞首字母大寫。
例如 int myStudentNum;

函數名、類名：採起大駝峯法，全部單詞首字母大寫。
例如 class DatabaseUser;

數組名：採起小駝峯法，而且用下劃線分隔單詞。
例如 char rand_Operator[4];

graph LR
A-->B