# 前言 雖然我們專案的程式碼時間並不長，也沒經過太多人手，但程式碼的規範性依然堪憂，目前存在較多的比較自由的「程式碼規範」，這非常不利於專案的維護，程式碼可讀性也不夠高， 此外，客戶端和後端的研發模式也完全不同，後端研發基本都是基於 SOA 思想的，通常一個子系統 3 個人一起維護就已經是很充分的人力了，更多時候就是 1 個主力 + 1 個 backup 的人力配置。 而客戶端卻完全不同，大家的程式碼都是相互交叉的，一個模組的程式碼可能要經歷數十人的蹂躪，所以形成一個一致的開發規範迫在眉睫。 # 為什麼需要一致的程式碼規範？ 核心還是減少溝通成本，提升我們的 Code Review 效率，讓我們的程式碼更加易於維護。此外，一個一致的程式碼規範可以造成更少的 bug，也就意味著更節省時間和金錢。 當然，規範是約定的，本系列文字全是筆者多年來博採眾長，積累而成，所以有任何不同意見，歡迎評論拍磚。 # 1. Android 的工具規範 工欲善其事，必先利其器。 由於 Android 基本都基於 Android Studio 進行開發，所以工具規範全部以 Android Studio 為前提。 1. 必須使用最新的穩定版本的 Android Studio 進行開發； 2. 編碼格式必須統一為 UTF-8； 3. 刪除多餘的 import，減少警告出現，可利用 AS 的 Optimize Imports（Settings -> Keymap -> Optimize Imports）快捷鍵，設定自己的喜好。  4. 編輯完 .java、.kt、.xml 等檔案後必須格式化（需要在設定好以下幾點的前提下） >Reformat Code 的必要性，一定需要保證 IDE 配置一致為前提，儘可能貼切於 Android Studio 預設。 強烈建議對於比較長的老程式碼區域性格式化，不全域性格式化 - 每行字元數不得超過 160 字元，設定 Editor -> Code Style  - 全部設定為單路徑引用，`kotlinx.android.synthetic.main` 除外。    以上幾處設定完畢，其他採用 Android Studio 預設方式，再進行 Reformat Code 快捷鍵即可。  # 2. Android 的分包規範 前面強調了工具的統一配置，再利用 Android Studio 本身的功能便可把程式碼風格變得一致。接下來就帶來第二部分：Android 的分包規範。 對於分包，我們需要達成一致，我們採用 PBF 方式，不推薦使用 PBL 方式。 > PBF（按功能分包 Package By Feature） > PBL（按層分包 Package By Layer） PBF 可能不是很好區分在哪個功能中，不過也比 PBL 要好找很多，且 PBF 與 PBL 相比較有如下優勢： - package 內高內聚，package 間低耦合 哪塊要添新功能，只改某一個 package 下的東西，而PBL 需要改多個 package，非常麻煩。 - package 有私有作用域（package-private scope） 原則上一個 package 下的不允許其他類訪問都是不應該加上 public 的。 - 很容易刪除功能 統計發現新功能沒人用，這個版本那塊功能得去掉。如果是 PBL，得從功能入口到整個業務流程把受到牽連的所有能刪的程式碼和 class 都揪出來刪掉，一不小心就完蛋。如果是 PBF，好說，先刪掉對應包，再刪掉功能入口（刪掉包後入口肯定報錯了），完事。 - 高度抽象 解決問題的一般方法是從抽象到具體，PBF 包名是對功能模組的抽象，包內的 class 是實現細節，符合從抽象到具體，而 PBL 弄反了。PBF 從確定 AppName 開始，根據功能模組劃分 package，再考慮每塊的具體實現細節，而 PBL 從一開始就要考慮要不要 dao 層，要不要 com 層等等。 - 只通過 class 來分離邏輯程式碼 PBL 既分離 class 又分離 package，而 PBF 只通過 class 來分離邏輯程式碼。 - package 的大小有意義了 PBL 中包的大小無限增長是合理的，因為功能越添越多，而 PBF 中包太大（包裡 class 太多）表示這塊需要重構（劃分子包）。 # 3. Android 的命名規範 程式碼中的命名嚴禁使用拼音與英文混合的方式，更不允許直接使用中文的方式。正確的英文拼寫和語法可以讓閱讀者易於理解，避免歧義。 > 注意：即使純拼音命名方式也要避免採用。但國際通用的名稱，可視同英文，比如 `toutiao`、`douyin` 等。 ## 3.1 包名 Android 裡面有 package 的概念，所以需要約定一下包名命名規範。 包名全部小寫，不允許出現中文、大寫字母或者下劃線，前面為子模組命名，再根據 PBF 方式進行命名。 ## 3.2 類名 類名都以 `UpperCamelCase` 風格編寫。 類名通常是名詞或名詞短語，介面名稱有時可能是形容詞或形容詞短語。現在還沒有特定的規則或行之有效的約定來命名註解型別。 名詞，採用大駝峰命名法，儘量避免縮寫，除非該縮寫是眾所周知的， 比如 HTML、URL，如果類名稱中包含單詞縮寫，則單詞縮寫的每個字母均應大寫。 | 類 | 描述 | 例如 | | :-------------------- | :------------------------ | :--------------------------------------- | | `Activity` 類 | 模組名 + `Activity` | 閃屏頁類 `SplashActivity` | | `Fragment` 類 | 模組名 + `Fragment` | 主頁類 `HomeFragment` | | `Service` 類 | 模組名 + `Service` | 時間服務 `TimeService` | | `BroadcastReceiver` 類 | 功能名 + `Receiver` | 推送接收 `JPushReceiver` | | `ContentProvider` 類 | 功能名 + `Provider` | `ShareProvider` | | 自定義 View | 功能名 + View/ViewGroup(元件名稱) | `ShapeButton` | | Dialog對話方塊 | 功能名+Dialog | `ImagePickerDialog` | | `Adapter` 類 | 模組名 + `Adapter` | 課程詳情介面卡 `LessonDetailAdapter` | | 解析類 | 功能名 + `Parser` | 首頁解析類 `HomePosterParser` | | 工具方法類 | 功能名 + `Utils` 或 `Manager` | 執行緒池管理類：`ThreadPoolManager`
日誌工具類：`LogUtils`（`Logger` 也可）
列印工具類：`PrinterUtils` | | 資料庫類 | 功能名 + `DBHelper` | 新聞資料庫：`NewsDBHelper` | | 自定義的共享基礎類 | `Base` + 基礎 | `BaseActivity`, `BaseFragment` | | 抽象類 | `Base` / `Abstract` 開頭 | `AbstractLogin` | | 異常類 | `Exception` 結尾 | `LoginException` | | 介面 | `able` / `ible` 結尾 / I 開頭 | `Runnable`, `Accessible` ，`ILoginView` | 測試類的命名以它要測試的類的名稱開始，以 Test 結束。例如：`HashTest` 或 `HashIntegrationTest`。 介面（interface）：命名規則與類一樣採用大駝峰命名法，多以 able 或 ible 結尾，如 `interface Runnable`、`interface Accessible`。 > 注意：如果專案採用 MVP，所有 Model、View、Presenter 的介面都以 I 為字首，不加字尾，其他的介面採用上述命名規則。 ## 3.3 方法名 方法名都以 `lowerCamelCase` 風格編寫。 方法名通常是動詞或動詞短語。 | 方法 | 說明 | | :-------------------------- | ---------------------------------------- | | `initXX()` | 初始化相關方法，使用 init 為字首標識，如初始化佈局 `initView()` | | `isXX()`, `checkXX()` | 方法返回值為 boolean 型的請使用 is/check 為字首標識 | | `getXX()` | 返回某個值的方法，使用 get 為字首標識 | | `setXX()` | 設定某個屬性值 | | `handleXX()`, `processXX()` | 對資料進行處理的方法 | | `displayXX()`, `showXX()` | 彈出提示框和提示資訊，使用 display/show 為字首標識 | | `updateXX()` | 更新資料 | | `saveXX()`, `insertXX()` | 儲存或插入資料 | | `resetXX()` | 重置資料 | | `clearXX()` | 清除資料 | | `removeXX()`, `deleteXX()` | 移除資料或者檢視等，如 `removeView()` | | `drawXX()` | 繪製資料或效果相關的，使用 draw 字首標識 | ## 3.4 變數命名 這裡的變數為廣義的變數，包括了常量、區域性變數、全域性變數等，它們的基礎規則是： - 型別需要是名詞 / 名詞短語； - 採用 `lowerCamelCase` 風格； 在具體的變數命名時，會根據該變數的型別不同而附加額外的命名規則： | 型別 | 說明 | 例如 | | :-------------------- | :------------------------ | :--------------------------------------- | | 常量 | 大寫 & 下劃線隔開，Kotlin 一定要 const val | `const val TYPE_NORMAL = 1`
`static final TYPE_NORMAL = 1` | | 臨時變數名 | 整型：`i`、`j`、`k`、`m`、`n` ，字元型一般用 `c`、`d`、`e` | `for(int i = 0;i < len; i++)` | | 其他變數 | `lowerCamelCase` 風格即可，私有變數也不要使用 `m` 開頭 | `private int tmp;` | | Kotlin | 只讀變數使用 `val`，可變變數使用 `var`，儘可能使用 `val` | `var tmp = 0`
`val defaultIndex = 0` | ## 3.5 資源命名 Android 的資源包括：  資原始檔命名為全部小寫，採用下劃線命名法。 ### 3.5.1 動畫資原始檔（anim/ 和 animator/） 安卓主要包含屬性動畫和檢視動畫，其檢視動畫包括補間動畫和逐幀動畫。屬性動畫檔案需要放在 `res/animator/` 目錄下，檢視動畫檔案需放在 `res/anim/` 目錄下。命名規則：`{模組名_}邏輯名稱`。 > 說明：`{}` 中的內容為可選，`邏輯名稱` 可由多個單詞加下劃線組成。例如：`refresh_progress.xml`、`market_cart_add.xml`、`market_cart_remove.xml`。 如果是普通的補間動畫或者屬性動畫，可採用：`動畫型別_方向` 的命名方式。 例如： | 名稱 | 說明 | | ------------------- | ------- | | `fade_in` | 淡入 | | `fade_out` | 淡出 | | `push_down_in` | 從下方推入 | | `push_down_out` | 從下方推出 | | `push_left` | 推向左方 | | `slide_in_from_top` | 從頭部滑動進入 | | `zoom_enter` | 變形進入 | | `slide_in` | 滑動進入 | | `shrink_to_middle` | 中間縮小 | ### 3.5.2 顏色資原始檔（color/） color/ 是專門用於存放顏色相關資源的資料夾。命名規則：`型別{_模組名}_邏輯名稱`。 > 說明：`{}` 中的內容為可選。例如：`sel_btn_font.xml`。 顏色資源也可以放於 `res/drawable/` 目錄，引用時則用 `@drawable` 來引用，但不推薦這麼做，最好還是把兩者分開。 ### 3.5.3 圖片資原始檔（drawable/ 和 mipmap/） `res/drawable/` 目錄下放的是點陣圖檔案（.png、.9.png、.jpg、.gif）或編譯為可繪製物件資源子型別的 XML 檔案，而 `res/mipmap/` 目錄下放的是不同密度的啟動圖示，所以 `res/mipmap/` 只用於存放啟動圖示，其餘圖片資原始檔都應該放到 `res/drawable/` 目錄下。 命名規則：`型別{_模組名}_邏輯名稱`、`型別{_模組名}_顏色`。 > 說明：`{}` 中的內容為可選；`型別` 可以是可繪製物件資源型別，也可以是控制元件型別最後可加字尾 `_small` 表示小圖，`_big` 表示大圖。 例如： | 名稱 | 說明 | | ------------------------- | ------------------------ | | `btn_main_about.png` | 主頁關於按鍵 `型別_模組名_邏輯名稱` | | `btn_back.png` | 返回按鍵 `型別_邏輯名稱` | | `divider_maket_white.png` | 商城白色分割線 `型別_模組名_顏色` | | `ic_edit.png` | 編輯圖示 `型別_邏輯名稱` | | `bg_main.png` | 主頁背景 `型別_邏輯名稱` | | `btn_red.png` | 紅色按鍵 `型別_顏色` | | `btn_red_big.png` | 紅色大按鍵 `型別_顏色` | | `ic_avatar_small.png` | 小頭像圖示 `型別_邏輯名稱` | | `bg_input.png` | 輸入框背景 `型別_邏輯名稱` | | `divider_white.png` | 白色分割線 `型別_顏色` | | `bg_main_head.png` | 主頁頭部背景 `型別_模組名_邏輯名稱` | | `def_search_cell.png` | 搜尋頁面預設單元圖片 `型別_模組名_邏輯名稱` | | `ic_more_help.png` | 更多幫助圖示 `型別_邏輯名稱` | | `divider_list_line.png` | 列表分割線 `型別_邏輯名稱` | | `sel_search_ok.xml` | 搜尋介面確認選擇器 `型別_模組名_邏輯名稱` | | `shape_music_ring.xml` | 音樂介面環形形狀 `型別_模組名_邏輯名稱` | 如果有多種形態，如按鈕選擇器：`sel_btn_xx.xml`，採用如下命名： | 名稱 | 說明 | | ----------------------- | ----------------------------- | | `sel_btn_xx` | 作用在 `btn_xx` 上的 `selector` | | `btn_xx_normal` | 預設狀態效果 | | `btn_xx_pressed` | `state_pressed` 點選效果 | | `btn_xx_focused` | `state_focused` 聚焦效果 | | `btn_xx_disabled` | `state_enabled` 不可用效果 | | `btn_xx_checked` | `state_checked` 選中效果 | | `btn_xx_selected` | `state_selected` 選中效果 | | `btn_xx_hovered` | `state_hovered` 懸停效果 | | `btn_xx_checkable` | `state_checkable` 可選效果 | | `btn_xx_activated` | `state_activated` 啟用效果 | | `btn_xx_window_focused` | `state_window_focused` 視窗聚焦效果 | > 注意：使用 Android Studio 的外掛 SelectorChapek 可以快速生成 selector，前提是命名要規範。 ### 3.5.4 佈局資原始檔（layout/） 命名規則：`型別_模組名`、`{模組名_}型別_邏輯名稱`。(也採用 PBF，方便檢視，尤其在大專案中) > 說明：`{}` 中的內容為可選。 例如： | 型別 | 名稱 | 說明 | | ---------------------------| --------------------------- | --------------------------- | | `Activity` | `main_activity.xml` | 主窗體 `模組名_型別` | | `Fragment` | `music_fragment.xml` | 音樂片段 `模組名_型別` | | `Dialog` | `loading_dialog.xml` | 載入對話方塊 `邏輯名稱_型別` | | `PopupWindow` | `info_ppw.xml` | 資訊彈窗（PopupWindow） `邏輯名稱_型別` | | `adapter` 的列表項 | `main_song_item.xml` | 主頁歌曲列表項 `模組名_型別_邏輯名稱` | ### 3.5.5 佈局資源 id 命名 命名規則：`{模組名_}_邏輯名_view 縮寫（功能）`，例如： `main_search_btn`、`back_btn`。此外，採用 Kotlinx 直接獲取佈局檔案的時候，id 命名採用駝峰樣式。 > 說明：`{}` 中的內容為可選。參考 GoogleSamples Demo：https://github.com/android/architecture-samples 例如： | 型別 | 規範 | 命名示例 | | ---------------------------| --------------------------- | --------------------------- | | `TextView` | `xxx_text` | `user_login_text` | | `EditText` | `xxx_edit` | `user_login_edit` | | `ImageView` | `xxx_iv` | `user_login_iv` | | `Button` | `xxx_btn` | `user_login_btn` | | `CheckBox` | `xxx_cb` | `user_login_cb` | | `GridView` | `xxx_gv` | `user_login_gv` | | `ListView` | `xxx_lv` | `user_login_lv` | | `RecyclerView` | `xxx_rv` | `user_login_rv` | | `RadioButton` | `xxx_rb` | `user_login_rb` | | `LinearLayout` | `xxx_ll` | `user_login_ll` | | `RelativeLayout` | `xxx_rl` | `user_login_rl` | | `FrameLayout` | `xxx_fl` | `user_login_fl` | | `GridLayout` | `xxx_gl` | `user_login_gl` | | `ConstraintLayout ` | `xxx_cl` | `user_login_cl` | ### 3.5.6 選單資原始檔（menu/） 選單相關的資原始檔應放在該目錄下。命名規則：`{模組名_}邏輯名稱` > 說明：`{}` 中的內容為可選。例如：`main_drawer.xml`、`navigation.xml`。 ### 3.5.7 colors.xml `` 的 `name` 命名使用下劃線命名法，在你的 `colors.xml` 檔案中應該只是對映顏色的名稱一個 ARGB 值，而沒有其它的。不要使用它為不同的按鈕來定義 ARGB 值。 例如，不要像下面這樣做： ```xml #FFFFFF

#2A91BD #5F5F5F #939393 #FFFFFF #FF9D2F ... #323232 ``` 使用這種格式，會非常容易重複定義 ARGB 值，而且如果應用要改變基色的話會非常困難。同時，這些定義是跟一些環境關聯起來的，如 `button` 或者 `comment`，應該放到一個按鈕風格中，而不是在 `colors.xml` 檔案中。 相反，應該這樣做： ```xml #FFFFFF #DBDBDB #939393 #5F5F5F

#323232 #27D34D #2A91BD #FF9D2F #FF432F ``` 嚮應用設計者那裡要這個調色盤，名稱不需要跟 `"green"`、`"blue"` 等等相同。`"brand_primary"`、`"brand_secondary"`、`"brand_negative"` 這樣的名字也是完全可以接受的。像這樣規範的顏色很容易修改或重構，會使應用一共使用了多少種不同的顏色變得非常清晰。通常一個具有審美價值的 UI 來說，減少使用顏色的種類是非常重要的。 > 注意：如果某些顏色和主題有關，那就單獨寫一個 `colors_theme.xml`。 ### 3.5.8 strings.xml `` 的 `name` 命名使用下劃線命名法，採用以下規則：`{模組名_}邏輯名稱`，這樣方便同一個介面的所有 `string` 都放到一起，方便查詢。 | 名稱 | 說明 | | ------------------- | ------- | | `main_menu_about` | 主選單按鍵文字 | | `friend_title` | 好友模組標題欄 | | `friend_dialog_del` | 好友刪除提示 | | `login_check_email` | 登入驗證 | | `dialog_title` | 彈出框標題 | | `button_ok` | 確認鍵 | | `loading` | 載入文字 | ### 3.5.9 styles.xml ` ``` 應用到 `TextView` 中： ```

``` 或許你需要為按鈕控制元件做同樣的事情，不要停止在那裡，將一組相關的和重複 `android:xxxx` 的屬性放到一個通用的 `

Android 程式碼規範大全

# 前言 雖然我們專案的程式碼時間並不長，也沒經過太多人手，但程式碼的規範性依然堪憂，目前存在較多的比較自由的「程式碼規範」，這非常不利於專案的維護，程式碼可讀性也不夠高， 此外，客戶端和後端的研發模式也完全不同，後端研發基本都是基於 SOA 思想的，通常一個子系統 3 個人一起維護就已經是很充分的人力了，

前端程式碼規範大全

初衷 不管參與專案的人數有多少，確保每一行程式碼都像是同一個人編寫的; 根據實際情況制定良好的程式碼規範； 遵守編碼風格使程式碼更容易維護，對長期專案大有裨益； 實施程式碼規範增加程式碼可讀性，提高協作開發效率； 實施程式碼規範減少低

Android程式碼規範_持續更新

   很慶幸，在我初入社會，就和一群大牛工作，並且我這張白紙，在大牛的工作中得到了比較好的薰陶和渲染。並且長此以往，根據學校老師，部落格大神，工作中大牛的程式碼風格，總結出來了自己當前的程式碼習慣和風格。   博主程式碼命名有些比較偏的命名 很可能是中國式英文，一

Android開發規範：程式碼規範(CheckStyle)

文章目錄 checkstyle: plugin checkstyle: gradle checkstyle: 155條規範 開發APP的過程中，每個團隊都會約定自己的程式碼規範。但是往往在實踐過程中，要麼由於開發週

程式碼規範和Android專案中的一些可用工具

這裡主要講一下關於程式碼規範的相關問題，和在Android專案中如何利用一些工具進行規範和檢查。程式碼規範不是一個Android專案特有的問題，所以前部分內容是不單針對Android的。 什麼是程式碼規範? 程式碼規範一般是指在程式設計過程中的一系列規則規範。 一般來說程式碼規

Android Studio自動檢查程式碼規範並提示如何優化的一些外掛

推薦幾個專案可能用到的外掛 1.CheckStyle 首先進入設定頁面進入Plugin頁面，如圖所示 點選Browse repositories進入選擇頁面，輸入checkstyle即可選擇安裝，如圖所示 安裝完成後點選Other Settings中的checkstyle進

Android 命名規範 （提高程式碼可以讀性）

    剛接觸android的時候，命名都是按照拼音來，所以有的時候想看懂命名的那個控制元件什麼是什麼用的，就要讀一遍甚至好幾遍才知道，這樣的話，在程式碼的審查和修改過程中就會浪費不少不必要的時間。如果就是我一個人開發，一個人維護的話還好，可是如果一個專案是團隊分工

Java&Android程式碼註釋規範

一、註釋及簡介     1、鄙人寫的一些程式碼中，雖說有註釋，但都是一些不符合規則的註釋，即便拿出來查閱，也要花很一些時間才能搞懂程式的流程。為了良好的程式設計風格，我特意學習了java的文件註釋，也分享給大家，良好的程式設計風格確實很重要，不可忽略···     2、說一

Android程式碼命名規範

前言 Android程式碼規範內容非常多，但對我們最有用& 最有影響的莫過於 Android程式碼的命名規範 可是，有很多人容易忽略Android程式碼的命名規範，從而導致程式碼的可讀性 & 維護性非常差，最終導致開發效率 & 維護效率降低 目

Android 編碼規範

完整 成員變量 整型 equals 簡潔 數據結構 替代 ive 中間 一、命名規範 1.1包命名 命名規則：一個唯一包名的前綴總是所有小寫ASCII字母而且是一個頂級域名，一般是com,edu,gov,mil,net,org等。 規約：以公司為準。通常是co

Android layout屬性大全

android ont roi http 布局 csdn -name str tail 第一類：屬性值 true或者 false 1：android:layout_alignParentStart緊貼父元素結束位置開始 2：android:layout_alignPar

aNDROID權限大全(很經典)

baidu android list lis com androi hao123 andro 經典 %E5%8F%91%E4%B8%AA%E6%96%B0%E6%89%8B%E6%84%9F%E6%83%B3%E8%AF%B8%E5%90%9B%E5%85%B1%E5%8B

值得你學習的 Android 開發規範(上)

web 數字 文件規範 () base lan 都是 3.5 tsp 前言 AS規範 命名規範 資源文件規範 版本統一規範 第三方庫規範 註釋規範 其他的一些規範 1 前言 為了利於項目維護以及規範開發，促進成員之間Code Revi

淺談Android編碼規範及命名規範

event err class wrap spa for循環 who 全局變量 經典 原文:淺談Android編碼規範及命名規範前言： 　　目前工作負責兩個醫療APP項目的開發，同時使用LeanCloud進行雲端配合開發，完全單挑。 　　現大框架已經完成，正在進行細節模

Android開發規範最新詳盡版下載

1、開發規範的必要性          軟體開發需要規範，規範利於前期開發、團隊開發、後期迭代開發，最大限度的提高開發效率，降低開發成本，防範開發風險。Android開發規範一般包括Android 資原始檔命名與使用

Android Studio 外掛大全（轉）

轉自：http://blog.csdn.net/alpha58/article/details/62881144   現在Android的開發者基本上都使用android Studio進行開發(如果你還在使用eclipse那也行，畢竟你樂意怎麼樣都行)。使用好Android

C++程式碼規範和CodeReview

C++程式碼規範和CodeReview 背景 最近手頭上的開發工作基本已經完成主要功能，其後續進行的工作主要在細小功能的調整和完善上，週末在家看書，想到了CodeReview，想把這件事在組內推廣下(其實CodeReview應該是在開發過程中進行的，現在提出，也是希望以後不要步此後

[轉載] Python程式碼規範和命名規範

http://www.imooc.com/article/19184?block_id=tuijian_wz#child_5_1 Python程式碼規範和命名規範 前言 Python 學習之旅，先來看看 Python 的程式碼規範，讓自己先有個意識，而且在往後的學習中慢慢養成習慣

值得細讀！如何系統有效地提升Android程式碼的安全性？

眾所周知，程式碼安全是Android開發工作中的一大核心要素。 11月3日，安卓巴士全球開發者論壇線下系列沙龍第七站在成都順利舉辦。作為中國領先的安卓開發者社群，安卓巴士近年來一直致力於在全國各大城市舉辦線下技術大會，為Android開發者提供最為全面深入的安全技術解讀。網易雲易盾移動安全專家尹彬彬指出，安

程式碼規範工具大比拼---Alibaba Java Coding Guidelines

                  程式碼規範工具大比拼---Alibaba Java Coding Guidelines &n