: : 堂堂地表最强软件公司也是不会统一的.......
: : 至于"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个档案那你还蛮钻牛角尖的

推楼上。