編碼規範個人理解

個人對編碼規範的一些理解

一些同學在寫代碼的時候一開始就不具備良好的習慣, 最後的代碼壓根沒法看, 寫一下自己對代碼的編碼規範的一些知識的整合.

1. 命名

​ 在我們的編碼過程中, 爲了可維護性, 以及可擴展性, 我們需要讓我們的代碼的可讀性增強, 尤其是在我們的團隊開發項目, 和需要長期維護的項目中, 如果命名不規範, 很容易被打, 所謂的命名規範就是先做到見名知義.

常見的命名方式有以下三種.

  • 駝峯式命名

    顧名思義, 駝峯式命名的用法是首個單詞小寫, 從第二個單詞開始就開始首字母大寫, 比如我們在定義一個質數的個數這個變量的時候, 可以採用以下這種方式.

    int numberOfPrime = 0;
    

    這種方式可以很明顯的看出要表達的意思, 這種方式應該是目前來說最爲流行的命名方式了.

  • 下劃線式命名

    下劃線命名就是單詞與單詞之間使用下劃線**_**隔開, 單詞使用小寫, 同上面的例子

    int number_of_prime = 0;
    

    這種命名方式常見於c語言的程序和數據庫的表明中

  • 帕斯卡命名

    帕斯卡命名方式與駝峯式命名方法相似, 只不過第一個首字母不大寫而已, 這種方式常見於c/c++/c#語言的函數中, 以及部分面向對象編程語言中類的命名

    C#

    static int Plus(int num1, int num2) {
        return num1 + num2;
    }
    

    Java

    class HelloWrold {
        
    }
    

2. 註釋

  • 行註釋

    • 一般修飾易讀性不強的代碼, 比如下面的嶺段代碼, 功能相同, 但如果用一句話來省略if的話, 那麼可以說很長時間之後看不明白, 就可以寫一個行註釋標記一下

      while(true) {
          if (resultIndex > arr.length) {
          	resultIndex = 0;
      	}
          resultIndex++;
      }
      
      
      
      while(true) {
      	resultIndex = resultIndex % arr.length;
          resultIndex++;
      }
      
      
    • 修飾一個塊的結束, 比如一個if 或者while 循環發生了嵌套, 而且每一個嵌套裏面有很多代碼, 在最後就會出現很多括號在一起, 分不清哪一塊是哪一塊, 這塊就會需要一個標識來說明結束, 比如下面這個例子

      for (int i = 0; i < arr.length; i++) {
          
          while (index != 0) {
              
              if (index = 23) {
              	
              } // end if
          } // end while
      } // end for
      
  • 塊註釋

    • 一般來說明一個小功能的時候來使用, 一般伴隨着比較長的一個註釋

      void heapify() {
          /*
          在這裏實現以下heapify, 在三個節點中, 找到最大的放在頭上, 另外兩個不用動
          */
      }
      
    • 另一種情況就是寫自己的介紹或者自己對這個代碼的註釋進行排版, 多見於國外的api或者外國友人寫的代碼中的註釋

  • 文檔註釋, 這個多見於java代碼中, 可以非常方便的對方法, 和全局變量附上信息, 在另外的地方也可以獲得這種信息, 變量使用@param, 返回值使用@return 聲明等等, 且支持html的大部分語法, 以下是節選了jdk中的部分源碼

        /**
         * Replaces the first substring of this string that matches the given <a
         * href="../util/regex/Pattern.html#sum">regular expression</a> with the
         * given replacement.
         *
         * <p> An invocation of this method of the form
         * <i>str</i>{@code .replaceFirst(}<i>regex</i>{@code ,} <i>repl</i>{@code )}
         * yields exactly the same result as the expression
         *
         * <blockquote>
         * <code>
         * {@link java.util.regex.Pattern}.{@link
         * java.util.regex.Pattern#compile compile}(<i>regex</i>).{@link
         * java.util.regex.Pattern#matcher(java.lang.CharSequence) matcher}(<i>str</i>).{@link
         * java.util.regex.Matcher#replaceFirst replaceFirst}(<i>repl</i>)
         * </code>
         * </blockquote>
         *
         *<p>
         * Note that backslashes ({@code \}) and dollar signs ({@code $}) in the
         * replacement string may cause the results to be different than if it were
         * being treated as a literal replacement string; see
         * {@link java.util.regex.Matcher#replaceFirst}.
         * Use {@link java.util.regex.Matcher#quoteReplacement} to suppress the special
         * meaning of these characters, if desired.
         *
         * @param   regex
         *          the regular expression to which this string is to be matched
         * @param   replacement
         *          the string to be substituted for the first match
         *
         * @return  The resulting {@code String}
         *
         * @throws  PatternSyntaxException
         *          if the regular expression's syntax is invalid
         *
         * @see java.util.regex.Pattern
         *
         * @since 1.4
         * @spec JSR-51
         */
        public String replaceFirst(String regex, String replacement) {
            return Pattern.compile(regex).matcher(this).replaceFirst(replacement);
        }
    

3. 編碼習慣

  • 書寫對人類友好的代碼

    簡而言之, 就是讓我們的代碼可讀性增強

    • 按照命名規範編碼

      • 所謂命名規範, 就是我上面提到的一些命名規範和註釋的規範, 寫代碼的時候要遵守這些規範
    • 對變量名和方法/函數進行描述

      • 變量名描述: 一般對全局變量名進行描述
      • 方法/函數描述: 對每一個方法進行描述, 即添加註釋, 避免方法名有歧義的地方
    • 做好代碼的縮進和換行

      在編碼過程中, 調整好代碼的縮進和換行也是增強代碼美觀的方式, 體現程序員的專業素養

      • 縮進: 縮進可以採用tab鍵的方式進行縮進, 也可以採用多個空格造成的縮進的方式, 但一定要注意不要兩者混用. 並且在一個代碼塊中縮進要一致
      • 換行: 適當的換行也可以增強代碼的可讀性.
  • 在一定高度上思考

說白了就是把握好全局

  • 不要在一個文件中寫太多代碼: 多見於編程的初學者

  • 高內聚, 低耦合: 內聚, 就是一個功能在一個代碼塊/文件中實現, 一個代碼塊只實現這一個功能, 儘量不要牽連到其他內容, 低耦合就是各個功能之間儘量做到關係降到最低

  • 編碼之前做好計劃

    • 先寫需求文檔: 當我們做一個項目之前, 先寫一下需求文檔, 將所有的突發情況都想到之後我們再寫代碼.
    • 做功能之前先寫demo: 當我們學習一個東西, 或者要添加一個功能時候, 先寫一個小demo, 測試通過了再加入到正式代碼中.
    • 寫bug文檔: 在有可能出現bug的地方寫出來
  • 編寫可擴展性的代碼

    當我們寫完一個代碼之後, 想要爲這個代碼增加新功能的時候不需要重新寫代碼就性

  • 不要亂加功能

    • 只需要滿足自己的需求就行
    • 記住, 爲什麼要寫一個你幾乎不會用的功能呢? 只能說明你會, 而不是你應該做這個事
  • 學會快速查找錯誤並解決

    • 會debug, 會設置斷點, 會看錯誤信息/日誌
    • 會過濾錯誤, 找出根源錯誤: 對於發生的多個錯誤, 要找出核心錯誤, 很有可能你的這一個核心錯誤, 造成了其餘的所有錯誤.
  • 會版本控制工具:

  • 會學習

    • 多看一些開源項目: 爲開源框架找找bug, 學習GitHub上星星多的代碼, 不會上Github的去Gitee上看看也行
    • 一旦你入了程序員這一行, 就永遠不要停止學習, 必須與時俱進, 永遠站在時代的前列, 不然的話就會在裁員的浪潮中渣都沒有剩下.

一旦你入了程序員這一行, 就永遠不要停止學習, 必須與時俱進, 永遠站在時代的前列, 不然的話就會在裁員的浪潮中渣都沒有剩下.

作者聯繫方式

作者聯繫方式: [email protected]

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章