1.是否需要有代碼規范
從個人理解的角度出發，我認為代碼規范還可以細分為代碼的風格還有代碼的結構設計（就好比排版一類的）
以前在上C語言課程的時候就看到過，老師會在打“{”的時候進行一個換行，但是有些老師或者同學在展示自己的代碼的時候“{”是不換行的，或許從基本上來理解，這就是我們所認為的代碼的風格吧，而我對于這種代碼風格的判定應當是從代碼風格的原則來看，第一要簡單明了，第二易讀易懂，第三沒有二義性。代碼的結構設計也就是像是程序設計中的模塊之中的關系吧。
(1)這些規范都是官僚制度下產生的浪費大家的編程時間、影響人們開發效率, 浪費時間的東西。
表示不贊同。其實最簡單的一個原因就是我們的代碼不可能只有我們一個人會去看，而當別人看到你的代碼時，首先映入眼簾的就是代碼風格和代碼的結構設計，倘若這兩者不夠標準或者是說不夠符合一個大眾觀賞的標準，就算你的代碼再優質，那也不過是你個人的作品，在團隊的開發中你可能是會導致隊友合作不順暢的一個結，而不是助長團隊合作默契的那一種風格。而且我們現在寫的代碼不過最多將近1000行（這是我目前的經歷來說，不代表全體水平TuT），倘若以后進入項目的工作中，寫代碼的量達到了幾萬行呢？甚至更多呢？如果沒有一個良好的代碼規范，恐怕浪費的時間是要比規范代碼的時間更多的吧，而且規范過后的代碼將會使一個隊伍的人進行學習和移植完善。從基本的理解上來說，大大的提升了個人的代碼美觀性和可讀性，也提升了團隊的合作默契和合作更多的突破自身代碼不足的機會。
(2)是個藝術家，手藝人，我有自己的規范和原則。
持中肯態度。首先我要解釋為什么我會保持中肯態度，因為規范和樣例都是人為擬定的，沒有什么是一出來就是天注定的，所以我們在規定規范的時候就注定了我們會去選擇一個比較大眾化一點的代碼規范，然而我認為這個東西并不是一成不變的，所以任何的代碼規范和原則都是可接受并且可理解的，就跟別人要看我們的代碼一樣，我們有自己的風格，我們首行是怎么縮進的，括號什么時候換行等等，我認為都是可以通過我們的意見達成一致去改變的。然而我持中肯的另一個原因就是很多人把代碼規范看起來是一種藝術，我不同意這是藝術，也不同意是什么手藝人，我覺得我在寫代碼的時候只顧著代碼的正確性，符不符合程序要求，并沒有把很多的注意放在了代碼的規范創造上，所以作為一個藝術家手藝人是萬萬不可的，然而我認為自己的規范和原則是沒有錯而且不值得被束縛的。
(3)規范不能強求一律，應該允許很多例外。
不贊同。其實規范在一定情況下來說就是一個東西的標準，然而例外是一種打破標準的存在，所以這個會這個標準對于事物的約束大大的降低。其實每個人在團隊中都是一個例外，因為我們都有自己的一個標準，然而真正的智者不就是求同而不是求異呀，所以往往規范是要進行統一的，那才是智者最后的結晶。
(4)我擅長制定編碼規范，你們聽我的就好了。
就像之前提到的，每個人在團隊中都可以被稱為一個例外，因為我們每個人都有自己的標準，如果讓一個人自己來限制代碼的規范和標準的話，那豈不是就變成了第三條一樣的例子了嘛，然而還是那樣，我們應當在團隊的合作的過程中求同去異，這才會使我們的合作順利并且默契，所以我認為讓一個人去規定代碼規范不重要，重要的是他要咨詢大家意見，或者是大家一起出謀劃策整理出合適的編碼規范，要達到求同的目的。
2.代碼復審
這次我結對作業的小伙伴就是我美若天仙帥過良辰的室友徐丞，由于他是一個不折不扣的給滿分的大學霸，所以我也很榮幸我可以抱到一條大腿腿，感覺人生還是有希望有救的呢!!!
下面是我對他的項目的代碼復審表：
|
General |
|||||||||||
|
Does the code work? Does it perform its intended function, the logic is correct etc. |
代碼可以正常運行，并且有了題目所要求的功能。 |
||||||||||
|
Is all the code easily understood? |
代碼結構非常好，變量的命名極其規范易懂，值得我去學習！ |
||||||||||
|
Does it conform to your agreed coding conventions? These will usually cover location of braces, variable and function names, line length, indentations, formatting, and comments. |
看了他的代碼。。感覺自己的代碼規范真的是需要加強。。因為我的小伙伴真的是完成的非常棒。。我也非常喜歡他的代碼規范。 |
||||||||||
|
Is there any redundant or duplicate code? |
在看過小伙伴給我寫過的評語之后。。我也是頓然醒悟了自己的程序的問題。。我覺得我能夠發現他的問題的地方應該是沒有的，在我現有能力下，我覺得我還是應該多向他學習！ |
||||||||||
|
Is the code as modular as possible? |
這次的作業中，小伙伴使用的是面向過程的一個思想。并且也是跟我一樣只提交了一個cpp文件。 |
||||||||||
|
Can any global variables be replaced? |
有全局變量 |
||||||||||
|
Is there any commented out code? |
在代碼中也有進行注釋過的。（（不過很規整 看起來很清晰~ |
||||||||||
|
Do loops have a set length and correct termination conditions? |
循環設置了長度，在規定范圍內之后可正常結束循環。 |
||||||||||
|
Can any of the code be replaced with library functions? |
沒有 |
||||||||||
|
Can any logging or debugging code be removed? |
無日志記錄和調試代碼 |
||||||||||
|
Security |
|||||||||||
|
Are all data inputs checked (for the correct type, length, format, and range) and encoded? |
檢查了輸入格式 |
||||||||||
|
Where third-party utilities are used, are returning errors being caught? |
未使用第三方程序 |
||||||||||
|
Are output values checked and encoded? |
輸出結果的格式正確 |
||||||||||
|
Are invalid parameter values handled? |
不合法的輸入視為錯誤輸入 |
||||||||||
|
Documentation |
|||||||||||
|
Do comments exist and describe the intent of the code? |
沒有寫文檔 |
||||||||||
|
Are all functions commented? |
沒有寫文檔 |
||||||||||
|
Is any unusual behavior or edge-case handling described? |
沒有寫文檔 |
||||||||||
|
Is the use and function of third-party libraries documented? |
沒有寫文檔 |
||||||||||
|
Are data structures and units of measurement explained? |
沒有寫文檔 |
||||||||||
|
Is there any incomplete code? If so, should it be removed or flagged with a suitable marker like ‘TODO’? |
沒有寫文檔 |
||||||||||
|
Testing
|
|||||||||||
|
|
|||||||||||
文章列表
留言列表
