组员写代码喜欢复制代码，复制完不格式化代码, 代码的写的歪七八扭的。今天说他，他改了重新提交，但是他的态度就是完全不在乎,一点都不是上心，经常犯。这是我的问题还是组员的问题，我要不要严格要求组员格式化代码，还是不管他们，只要代码能运行就行。

上班，能跑起来程序员，下班，代码不优美逼死强迫症程序员

建议提交自动格式化，测试跑不过不能 push

这态度不行，安排去做测试吧

你是组长该你决定啊

准备长待就严格要求

你有权就强制执行

lint 之类的规则建立一下
代码是给人看的，可读性是首要标准

直接在 git 上接 规范检查，比如 Python 就用 pylint，各个语言都有，通不过不允许提交。

此外所有提交都有 Code Review

啥语言，前端相关可以强制 build 之前做格式检查，检查不通过中断 build 过程。

#2 差不多吧，建议全组统一自动格式化，达不到一定标准严格不准合并

不就 alt shift +f 吗。。。不格式化自己看的不费劲吗

sonar

大事做不好是能力问题 小事做不好是态度问题

安排去非洲吧

sonar 有坏味道，重复代码块 不能提交合并请求 被发现了就扣钱

口头督促 就算听得进去也有可能遗漏的

建议先格式化一下你本帖的内容。
没有分行和合理的断句，看着和不格式化代码效果一样。

我们公司也有一些人，对代码格式很不在意，觉得只要能运行就行，说了也不管用。很无语。

这是我在 V2EX 上见到最长的标题

提交审查工具？

我看着标题，我以为你就是那个组员

你可以要求做 code review 呀，格式不对打回去，不给合并。

如果没有人手就拉倒吧。做好单元测试，谁写的代码谁负责咯，出问题了扣钱

code scan，代码不格式化，要以后维护的怎么看。安排去非洲吧

提交的时候自动格式化，静态检查

搞个 mr，格式不行不给过就好了

lint 整上 编辑器再 auto fix

我就是这类组员，只不过没不缩进那么夸张，VS 里自动缩进也就是一个快捷键的事。
至于是否上心，主要取决于是否对规范有兴趣。每个人其实不是不遵守规范，而是都形成了“自己的规范”，所以当在团队里做事的时候会不知不觉的只执行“自己的规范”，这种情况下，很多时候都宁可扣点分也懒得修正。
当然这不是不改正的理由，只是很多人的对一些“不重要”事情的观点，并不是追求 100 分，所以遇到这类问题，永远都是屡禁不止，真想解决，要么强制考核（员工容易抵触），要么培训员工的规范意识（抵触会稍低点）。

在 CI 上挂个 lint (偷笑)

可以使用 clang-format，规定使用统一格式文件(.clang-format 文件)

格式化啊 一个快捷键的问题。。。

@usslss 我所见过的程序员，倒是有大半就是楼主说的这种。为啥他们对格式没有一点点的要求，因为他们写过代码就再也不看了呀。其实他们知道自己代码烂，所以就更不愿意去看了。。。

因为代码烂所以不想改，因为不想改所以代码烂。整一个蜜汁恶性循环

先把规范写进文档，然后 Lint 加入 CI，强制 1 推行

明显是你的问题不会管理，这大概也是公司的问题不会或者不愿寻找合适的中层管理。

这种人根本不适合做程序员，和类似逻辑严密类型的工作。

@xuanbg ..为啥会不再看 我自己格式化备注 是为了方便自己，不然过一阵回头看好多东西根本记不住

随手格式化是职业操守啊

团队 review 的时候就可以进行代码风格和统一。

持续集成之前自动格式化一下不就好了

组长有权利要求格式化，不格式化接手人或合作人不是一脸懵逼？ 不要求格式化反而感觉你组长做的不到位

搞个 linter，格式不对就报错那种

你们开发流程有问题，指望着什么都靠自觉本身就是不靠谱，这个问题更多责任是组长，组长不就是搞这个的么？

@usslss 大概是只为了混口饭吃做的程序员吧。。。这类人最大的特点就是过不去 30 岁的这道坎，勉强过去了也还有 35 岁在前面等着。但你让他提高一下自己的水平的话，只把你的话当耳边风，然后照例每天焦虑。

好好写代码就能累死吗？代码写漂亮点自己看着不会舒服点吗？我也真是理解不能

还是 python 好, 至少大家缩进没毛病(狗头)

看这标题，楼主不会就是那个组员吧？

话说，写代码没有自己公司的代码规范么？
如果没有，建议现在就出台一份，大家都参考规范来写。

build 的时候加 format 测试，然后弄个自动格式化就行

说服人要讲好处而不是讲道理，人都有很强利我偏好的，你说这样做(对他)有什么好处，不这样做(对他)有什么坏处，这种方式更容易说服人

别在项目弄自动化格式，直接格式检查不通过就编译失败，不然不长记性啊

都是被大括号惯的，全员转 python 吧，让他们不格式化，连跑都跑不通

@roscoecheung1993 我在项目加了 git hook 用 hook 来检查 lint，结果他们同事为了提交直接在 idea 研究出了去掉 git hook 的提交，然后 lint 就没用了。。。

麻烦标题格式化一下，看着累。

看你们标准了，所有人都要求格式的话，就一个都不能少。

@zhenjiachen 在 CI 层做 lint，自动化检测不过不让 merge

CI 上放个 lint，多大的事儿

@IanPeverell 箭头式代码了解一下

公司的钱要么花在领导身上，要么话在中层身上，要么花在基层身上，谁拿钱谁干活，谁不干活谁滚蛋？你把这个弄清楚了再动手不迟，不然你就是没事找事。

公司的要求是什么，公司主要把钱花在领导身上，还在中层身上，或花在基层身上，谁是实际上的负责人，谁能获取好处？你把这个弄清楚了再动手不迟，不然你就是没事找事，要么是向上层贴冷屁股，要么是酷吏失去人心。

代码质量是生命线，这个规范必须是全组统一的
代码 ci 必须过静态检测，merge 之前必须过 cr，先制定规范，久而久之大家就会习惯

一起做项目谁愿意替别人出力？这个代码可读性只对项目负责人有好处，对于组员来说，有些时候甚至是让他留在岗位的障碍。
可以让每个人负责的模块更独立一些，或者强化每个人的不可替代性，或者你制定出来一套标准，不按标准执行就会被处罚。

标题写成这样，还好意思说别人？

在我厂，如果代码格式化不标准，build 都没法 build。
我们写了一大堆 Code Rules 放在预编译阶段去检查代码规范。

应该规范流程，不通过指定 format 过程不能通过自动测试，也就不能提交代码。

直接上 lint.git 提交效验.gitlab 校验

前端的话,prettier 了解一下.

配置好后,管他们本地是什么鬼样,提交到仓库就一个样

@wangkun025 被你一语点中, 一直觉得哪里不对, 就是说不上来.

标题一定要这么长么。。。
Lint

你们没有 code review 吗

一个 alt shift f 的事....

加个 lint 的 git hook 解决...

我觉得需要格式化，我们连编码规范都要严格要求。对齐格式真的太重要了，美观整齐。

组员的问题

比如看到你的标题（雾）格式化不就是一个组合键就能搞定的事情嘛，建议强制格式化

我觉得你也是这号人啊……

ci 加门禁

劝你业余时间 花点心思 传一份自己自主设计的软件的源码到 GitHub，建立你在世界范围内的话语权，然后未来去找和你志同道合的人一起工作。不要花时间去教育从不思考的人。

git 支持 hook 来 format

ci 中检测，不过 lint 的不予合并

把代码规范作为检验代码质量的考核标准之一；
lz 去下本 Google-C++编码规范中文版看看，
开会的时候大家达成一致，统一一下标准，然后实施。

看回复觉得这类组员还不少啊，估计根本不上心，只有能通过就行，难怪现在的 App 越来越卡…

能跑就行，是很多人的工作态度
有权就干他，同级就算了，别找不痛快

18 和 22 楼就是我想说的

@opengps #28 额。。。我觉得这不是理由 只有代码规范给出来大家都没有异议就应该严格遵守 你自己写自己的项目想怎么写就怎么写 公司代码还是要按照组里的要求搞得

@mamahaha #57 代码格式化 为啥会对下面的人没有益处 只要规范是现行的 肯定对个人是有好处的

代码丑陋看着真的糟心，尤其是别人的

快捷键格式化可能导致一大堆代码都显示是你最后改动的

mark 一下自己各位大佬的方法，回去规范下自己代码

把他炒了

树立代码规范，违规发现一次罚款 50 元作为团建经费
除了被罚的人，大家都开心
欢迎不上心的组员购买包月服务

CI+SonarQube，不合规直接报错，要不用你去操心了

你先学会如何写合适字数的标题，再说别人。

@tourist2018 #83 还是强硬点直接凝定一份好吧，不然开会讨论，一伙要 tab 缩进，一伙要空格缩进，还不打起来

出了问题罚钱，敢作敢当

楼上没几个能真抓住核心问题的。什么钱招什么人，给多少钱干多少活，就这么个道理，不爽你就喊老板赔 N+1 辞了他换个对代码有追求的啊

git commit
√ Reformat code
√ Optimize imports

ci 加 lint，不过合不了代码

既然有这么简单的问题代码怎么上去？

你们不用 Git 吗？不用 Branch 去开发新特性吗？合并之前不需要跑 CI 测试吗？没有 Code Review 吗？

@SimonOne #90 注意我说的是大家都通过。。。

一般不管 能跑就行

你是他领导，干他
你是他平级，忍着