首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  程序员

你们在公司写代码有没有什么编程风格规范?一般都是怎么实施?

  •  
  •   jdhao · 146 天前 via Android · 4363 次点击
    这是一个创建于 146 天前的主题,其中的信息可能已经有所发展或是发生改变。

    如题,譬如 Python 有 PEP8,谷歌的规范等。你们在公司写代码会不会遵循编程规范,还是大体上确保代码没问题就行,不是严格遵守这些规范?

    如果遵守这些规范的话是怎么保证大家都遵守统一规范的,一般都采用什么办法

    57 回复  |  直到 2019-06-23 10:20:51 +08:00
        1
    zyqzyq08   146 天前 via Android
    pycharm 直接 refomat code
        2
    moyupoi   146 天前 via iPhone   ♥ 1
    前端可以加 eslint,然后增加 git 提交检查,如果有不规范直接自动禁止提交,非常管用
        3
    jdhao   146 天前 via Android
    @zyqzyq08 pycharm format 出来的虽然看上去遵守规范了,但是有时候比较丑,不美观
        4
    jdhao   146 天前 via Android
    @moyupoi 是 commit hook 之类的嘛,是不是有 warning 就提交不了
        5
    moyupoi   146 天前 via iPhone
    恩,但可以强制提交,加个-n 绕过 eslint 检查,但下一个人如果普通提交会被上一个人强制提交的代码卡住,然后这个人就被打死的
        6
    moyupoi   146 天前 via iPhone
    这种方式不适合那种水平很菜,代码已经写了好几万行没人维护的项目,适用于水平差不多的人,提高代码质量,相互约束,还有一种场景就是制那些水平很烂却牛逼哼哼的代码“大神”
        7
    russian   146 天前
    没有 code review 吗? code review 的时候可以给他提意见
        8
    jdhao   146 天前 via Android
    @russian 没有,都是自己写自己的,能跑就行
        9
    russian   146 天前
    @jdhao 那至少开会把?有的人代码写得很烂,比如一个函数 200 行,肯定所有人都能知道。这种容易出 bug 或者不好测试的,肯定会说起来。说起来的时候让他自己改
        10
    jdhao   146 天前 via Android
    @russian 我们做算法的,目前对代码要求不高,能跑就行,没有任何 review 过程
        11
    russian   146 天前
    @jdhao 我发现你没看明白我上边那句话。我觉得你们的团队要么很业余,要么你不是学 cs 的
        12
    jdhao   146 天前 via Android
    @russian 我知道你的意思,我们目前没有 code review 之类的,算法主要是输出训练好的模型,保证模型能得到需要的结果
        13
    hyrepo   146 天前
    Java 有静态检查插件,比如 checkstyle,风格不对会挂 build
        14
    russian   146 天前
    @jdhao 不。。。你不知道。。。
        15
    qiaobeier   146 天前
    eslint config
        16
    luozic   145 天前 via iPhone
    没有 code review 并且有基本规范和定期分享。也么有门槛监督,所有的规范都会变成空中的飞机。
        17
    Jonz   145 天前
    我们 Java 团队最近的新项目就是按阿里的编码规范来要求,IDEA 装 P3C 插件扫描。。
        18
    kerassss   145 天前 via Android
    @moyupoi 这东西真的有用嘛,每次感觉检查跑半天,影响前端同学开发效率的说。
        19
    xsiong   145 天前
    阿里的 java 手册
        20
    jowan   145 天前
    PSR
        21
    avenger   145 天前 via iPhone
    @moyupoi #2 git hook 不是在本地吗?自己禁止了怎么办?
        22
    l00t   145 天前
    代码风格在编程规范里是最不重要的东西,没必要花太多心思。
        23
    axbx   145 天前
    提交之前会跑一遍 sonar。
        24
    kaedea   145 天前 via Android
    .editor onfig
        25
    hexingb   145 天前
    @russian 200 行代码还差劲吗?看我这里几千行的。自从接手这个烂坑,我心里骂了多少 fuck,绝对比代码字母数多。

    很多人、很多公司不考虑这个,总是拿追进度做借口。实际上,规定一套很简单的规范就能够很好的统一代码风格。比如空格 tab,比如 dos/unix 换行。
        26
    yvescheung   145 天前
    c++遵循谷歌规范,不规范编译无法通过
        27
    zhuweiyou   145 天前
    搬砖而已,只要能完成功能就行了
        28
    GoLand   145 天前   ♥ 1
    加 pre-commit,把代码风格检查放进去。过不了就 commit 不了,ci 里也会过一下 diff,代码风格不对 ci 都过不了,别说 Merge 了。
        29
    no1xsyzy   145 天前
    @russian 算法是 cs 不是 se 啊……
    做算法的不算程序员的,算科学家或者技术工,中间其实没有工程师的位置。
        30
    jdhao   145 天前 via Android
    @no1xsyzy 做算法感觉有点尴尬,和做前端后端,做 APP 不一样,一般都是在训练模型,代码质量好像没太多人 care …
        31
    no1xsyzy   145 天前
    @jdhao (其实 APP 也算前端,只是现在前端常特指网页前端)
    是的,甚至理论上不需要写代码,只需要写伪代码。不过写个代码能够很明显地看到:它能跑,能出需要的结果,所以逻辑没错。
    至于代码质量?算法写完的代码是需要后端重新写一遍的。算法写的代码可能是 Python, Matlab, R 甚至是 Fortran 的,但是后端的是 Java 或者 Golang。让算法维护代码?经济效益就低了,老板是不干的(如果老板能懂这点的话)。但后端可能只是看得来 Python 等,稍微写一点写不了很复杂的,那不如重新写一遍。
    所以说为什么 Python 的一些地方非常垃圾但算法常用,因为其实就是当个能跑的伪代码用。
        32
    neverfelly   145 天前
    @no1xsyzy 做算法也算程序员啊...只要是 cs 的,代码就应该以规范化来写,传统 linux 科学家哪个不是写得一手好代码,就说最近火热的机器学习这一块,xgboost,lightgdm 也是按照规范在运作...纯粹训练模型算是偏数学科研工作者了
        33
    no1xsyzy   145 天前
    @neverfelly 以前的程序员还搞硬件呢,不也是逐渐分开了?随着社会发展,让职位分开是大势所趋啊。
    而且 Linux 科学家是指哪些啊…… Unix 就是工程师的事了吧。
        34
    dilu   145 天前 via Android
    有,git 钩子检查,不符合规范直接扣绩效
        35
    neverfelly   145 天前
    @no1xsyzy 可能表达有点错误,linux 科学家指:是 linux 教徒科研工作者...虽然目前来说确实就训练模型来说,对代码的抽象性和理论推导要求比实际代码能力来要强一点,所以并不会要求代码写得很漂亮,但这也确实正在成为所诟病的一点,诸如脚本调参侠之类的戏称。个人感觉 cs 最重要的还是对代码如同艺术以及对数学如同神明一样古典美感结合最好
        36
    no1xsyzy   145 天前
    @neverfelly 我倾向于算法这块构造属于算法的新的美感,就好像数学的美感在程序员里就可能是丑陋的(单字母公有自由变量)。
        37
    jdhao   145 天前
    @no1xsyzy 这个就是代码之美,写的代码能够被其他人容易读懂,所以变量命令要有意义,不能像搞数学的弄一些单变量的名字,也是软件工程的要求吧,清楚的代码更加容易维护。
        38
    ayasakinagi   145 天前   ♥ 1
    python 是 pep8, js 是 esline, 代码通过 git review 提交到 gerrit 上面, 通过 jenkins 检查格式.
        39
    loading   145 天前 via Android
    结对编程,只要另外一个能看懂,注释够,编译能过就行,←_←
        40
    intsilence   145 天前
    CI 里检查
        41
    janxin   145 天前
    工具检查
        42
    russian   145 天前
    @hexingb 200 行的我感觉恶心,懒得说。如果有人写函数超过一千行我真的要和他好好谈谈,真的。绝对不能这么妥协。
        43
    brust   145 天前
    java 没有规范 但是我按阿里的 java 手册
        44
    Ritr   145 天前
    我们公司没什么规范,能跑就行!
    我个人的代码风格是增强约束性,变量名起全名,function 行数在 50 行以内,减少公共变量等等
        45
    WispZhan   145 天前
    xxx-lint
    checkstyle
    sonarqube

    最重要的 code review,不符合风格的,打回去
        46
    no1xsyzy   145 天前
    @jdhao 类似地,我认为算法工作最后得出的美感也会和程序员(软件工程)的不一样。
    这不是在说个体差异,而是工作内容、工作需求、工作环境决定的。
    至于最后会变成什么样我也不知道,就算这时候有谁预言中了也不过是瞎猫(略
        47
    gxm44   145 天前
    @jdhao 配合 black 吧
        48
    kljsandjb   145 天前 via iPhone
    大括号换行?
        49
    jdhao   145 天前 via Android
    @gxm44 目前用的是 pylint 和 flake8
        50
    ben1024   145 天前
    PSR
    PHPCS
        51
    xiangliudev   145 天前
    我司 java 是用 checkstyle
        52
    FireCat   145 天前   ♥ 1
    问题一:在网上搜下使用语言的比较有名的一个或几个规范。综合生成适合自己现在公司项目的。
    问题二:拿着规范进行培训、使用代码检查工具等多管齐下
        53
    w292614191   144 天前
    @Jonz
    @brust
    @xsiong
    我也装了 P3C,我感觉代码写不动了,时时刻刻都有问题,需要纠正写法,有时候特殊原因没办法按照完全规范,很尴尬。
        54
    Jonz   144 天前
    @w292614191 只能看具体是什么问题了,如果一直是没办法按规范来的就把那个类型的错误先关掉提示呗。刚刚加班想偷懒拷了一堆重复代码,也是一堆波浪线,后面想了想就还是抽出来公用方法了。感觉就是可以时刻提醒自己去按规范来
        55
    brust   144 天前
    @w292614191 #53
    尽量遵循吧
    阿里的 java 手册和 google java 手册 有点冲突
    也不是一定要完全遵循
        56
    Earl   144 天前
    规范肯定有,而且我们是要求强制执行的。
    合入前必须通过静态检查,不然不能合入。
        57
    l4ever   143 天前 via iPhone
    @l00t 反对,团队协作里面,代码规范很重要。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1151 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 26ms · UTC 18:17 · PVG 02:17 · LAX 10:17 · JFK 13:17
    ♥ Do have faith in what you're doing.