: : 堂堂地表最強軟體公司也是不會統一的.......
: : 至於"coding sytle" 他們通常會用clang-format去整理 所以還算一致
: 程式碼風格在大型專案裡頭著實是一件很難搞的事情，在很難去分高下的前提下真的要
討
: 論往往會變成宗教戰爭，參與開源專案這幾年看過不少年薪幾百萬台幣的工程師吵風格
吵
: 得不可開交然後又不了了之。
: 回到主題。閱讀他人的程式碼是一件極度需要修養的工作，除了耐心以外，老實說我也
不
: 確定到底有啥訣竅，不過我個人蠻喜歡一個小技巧，就是幫別人的程式碼寫註解。尤其
當
: 此次的修改需要用到別人的程式碼而且又很難啃的時候，幫忙寫點註解除了確保自己真
的
: 有看懂以外，也可以做功德的幫助下一個可憐的工程師。
來打打屁
自認對coding style沒有很嚴格的要求
最基本的讓人看出這一包在作啥就算了
最近跟國外的同事合作
我突然發覺我對README有沒有好好寫這件事很鑽牛角尖
委託了對方開發一個功能
最後對方交差的source code結構如下
project
- pom.xml
- src
- job.java
這個在衝碼改阿
先不管內容如何
怎麼測試怎麼執行一句未提就這樣一包放到github
就這樣我第一次看也不想看的Reject別人的交付
請對方改之後對方也淡淡的回一句 "sure..."
我以為把README寫好是很基本的，是我很奇怪嗎
趁機問一下平常各位大牛都有寫README的習慣嗎

如果要交付原始碼，又沒辦法當面講的話寫個說明很應該的

一堆人不喜歡寫文件的，都認為自己的程式碼寫的漂亮就好

mvn test 啊

Read me 沒有很重要啊

有些熱門包的README都寫短短的 都寫在WIKI

readme說明 test指令跟 dev指令算頗基本的事情

細膩的 連部署常見問題都有

java挺麻煩的 一堆步驟

java請愛用@annotation功能

看到pom.xml就知道是用maven,我覺得其實還好耶...理解別人的程式碼的架構也是要看經驗的 這類的部署套件以及相關的框架 都算是Java的共通語言最怕是沒有框架 單純native java寫整個service的程式聽朋友分享 一堆公司不用框架或用自家框架來寫程式遇到這種才真的會吐血

如果裡面真的只有這2個檔案那你還蠻鑽牛角尖的

推樓上。