公司统计代码行数的逆天逻辑

这就是外行管内行， 结果一团糟。

哈哈哈，忍不住笑了。

一摸一样的情况在我们公司也有。

git 打开历史就是无数道彩虹

我靠,我以为没有统计代码行数的公司,没想到在 op 这里见到了

应该管理需求和 commit 质量，而不是代码函数。一将无能,累死千军。

哈哈我们公司是比加班时长

@iOCZS 现在每个月做的最多的事情就是，扯皮，甩锅，算自己的数据，数据不好直接通报批评

什你停止使用 Git rebase 命令. (Link)

逆天，下次你把依赖库也提交了吧

@qinjiang 已经在计划重新实现 jdk 了

这种班上着不累吗

在这里给大家讲个笑话吧
我们 CTO 的新政策：统计每千行的 bug 数

@Yuanlaoer 我怀疑你和我一个公司，坐标杭州吗

你这领导不会是新来的领导吧。我们之前有个领导就让我写了个代码统计的工具。但是会把 merge 的行数去掉。

后来他走了（真好

@brom111 确实是今年的新领导，新官上任三把火

flutter 程序员内心独白：

居然有这等好事？

@sqfphoenix 不是，我们公司也没有杭州办公室。
眼下这种大环境下，这种事儿不会少的。在特殊时期，亩产万斤的不光你们村，也不光我们村，是几乎每个村。

@joyhub2140 哈哈哈哈，这就把 gitingore 清空

why-you-should-stop-using-git-rebase[]

哈哈哈哈哈哈哈哈哈，谢谢你，笑出声了

还没体验过统计代码行数的公司。
先在你这里学点统计逻辑 0 0 ！

公司发个预告函，想个办法去印象空间偷他心吧

@mayday1997 我希望我是明智吾郎

@Yuanlaoer 我们也是

你把 node_modules 提交了吧

node_modules 提交下随随便便几十万行（前司有人就这么干

话说部门领导不懂技术么。

我觉得管理层一个就好了，千万不能多。

我司就是 代码行数 处理 bug 数

不用 rabase 看得脑壳痛，都不知道会不会在里面藏 bug

@Yuanlaoer 我怀疑和你一个公司，坐标深圳吗，新来的领导

美团

rebase 尤其是 rebase quash 经常动不动引发冲突，甚至还经常导致 github 在 PR 里无法显示正确的 file changed 。所以我管的项目直接在 github 的 repo 设置里禁止 rebase 和 rebase squash
分支你看得乱就乱吧，反正只要保证几个重要不然分支不乱就行，剩下随便你们来。总比动不动 PR 合并出问题舒心

上周我们老大也让我们统计代码行数了，想问下一般是在什么背景下才会做这种操作？ 我们老大是产品出身本身不会写代码，然后公司好几个月没发工资，先入为主一下，是不是公司要凉了呀。

@Dogtler 各种情况都有，有些是外行装最懂的指挥内行，有些是公司不行了，但是你这个我建议你赶紧找工作止损。。。

好奇挪动目录的改动也会统计进去吗

我依稀记得我上一家国企，自从我离职之后，开始统计每人每天代码行数，要求不低于 3000 行每天。我想一个系统 4-5 人维护，一个月怕不是 os 都搞出来了。
实际：new 一个对象需要 new 七八次，最后赋值，用 set 全走一遍，以此达成目标。
笑死。
据内部人员表示，目前上海和合肥两地的开发基本裁完，笑死

两个空格转成四个空格提交一次，单引号转双引号提交一次。适用于 js 等语言。

所有空格转换成换行，Tab 转换成 4 个换行，适合非 Python 等语言

智障领导精英就是这样的局面

你应该做个工具，方便代码风格转换，有偿。

然后在同事间消然推广。

统计代码行数呀，哪个把 maven 去掉吧，这东西用不上了

merge 提交行数，只是修改过的行数吗？感觉很合理啊。难道是整个文件的行数？

完全不敢现象（可以想象）一年后你们领导看到统计出来的总行数 几十亿 时的表情。

@hazardous #43 他越努力增加代码行数，他的同事 merge 起来越爽。

@Dogtler 好几个月没发工资还需要先入为主一下吗。。。已经快凉透了吧，赶紧找下家止损吧

你在主分支 rebase ？

break-width 改成 10

我有个很好的经验 这次统计代码，我把 csv 10 万行的测试文件误提交到了 git ，结果我是代码量最高的人（没人审核） lol

@Yuanlaoer 虽然 OP 讲的事儿很扯淡，但是统计千行缺陷密度这个其实是业界通行的质量管理手段。。。。

把一个几千行的文件，全部索引改为两个空格，隔天又改回 4 个空格
那每天的修改行数不就上天了吗

@BeautifulSoap #33 第一，Github PR 合并选项就没有 rebase 。第二，rebase 的方向是从其他分支变更到个人分支，控制权完全在个人手上，你最多只能禁止 rebase 之后的 force push ，但禁止不了 rebase 。所以你说得是那个 rebase 。

所有代码格式化一下，直接排名第一

哈哈哈哈 可以选一个最多提交了 然后 merge 它

@nothingistrue #52

换行改一下啊，linux 换行和 windows 换行

@Yuanlaoer 千行 Bug 率，是很常见的指标。我了解国内头部互联网企业都统计

还有很多别的指标，统计是统计，要看指标怎么用，辅助观察还是以此为准

@xianyv 我这也有，代码量，bug 率

明年也许就不用了

贵司领导可能觉得这样装逼吧，毕竟领导就爱 PUA 式管理。总得显得自己有能力驾驭尔等高级农民工的。

能够把代码行数来统计工作效率，说明公司想裁人，恶心人罢了。

根据之前类似贴子的回复，把那些包的代码 cv 复制一份。其次，循环全改手写。

@nevin47 您想表达的重点是？

@iyaozhen 那您觉得这个指标怎么样？

@chihiro2014 太二逼了哈哈哈

哈哈哈哈
好奇今天改一个目录明天再改回来是不是也算

我一直习惯 git pull --rebase origin

原来 git merge 还有这 “优点”，涨姿势了

@nothingistrue 我十分怀疑你有没有用过 Github

@shalk 然后有 bug 永远看最后一个提交是谁，不管改动的是啥，阁下如何应对

@horizon #56 哦，原来是这个首先源分支上 「 rebase --no-ff 」，然后目标分支上 「 merge --ff-only 」，如果不能 rebase --no-ff 还不让做的 Github 专有的脑残方式。这个脑残方式是一定要禁止的，但请注意它并不是通常所说的 rebase merge 。

通常所说的 rebase merge ，是首先源分支上 「 rebase 」，然后目标分支上「 merge --no-ff 」，如果有冲突则可通过界面处理，这样的过程。Gitlab 、微软 Devops 、Gitea 等都支持这种方式，就 Github 出于提交签名的考虑，不支持这种方式。

@jasonyang9 手下的人未必都是精英，但是领导是真的智障

我们公司用 commit id 去重后算 commit 里的代码行数，你这种 rebase 的会算重，代码量大增，来我们公司吧 [狗头]

你们是用的 Gitlab 吗？我司前段时间统计项目是从 Gitlab 拉取的 Merge 日志来统计影响行，然后有项目组是直接 Push 到 master 分支的，导致月均代码行数小于 1 行，笑死了。

奇数次提交 unix2dos
偶数次提交 dos2unix

@IamLostInCoding 干着不累么

@Dogtler 一个月不发工资就应该慌了，你怎么忍得住的

@Yuanlaoer 我是 QA ，我不反对这个指标。怎么说呢，质量可视，总得需要一些指标

@ryan4290 技术总监是日本回来的废物，跟国内起码脱节 10 年，笑死

@iyaozhen 您这 2 条回复总结在一起，我帮你翻译成简单的普通话吧：“不认同但不想明说”

@Yuanlaoer #63 千行缺陷密度在项目实操中很好用，用来评估项目质量是一个很合理的指标。类似你说的清空 ignore 这种操作，在 PR 的时候有 Maintainer 来拦截的，不会影响缺陷密度统计

@nevin47 我说 gitignore 那个是开玩笑讲的。
像你讲的，“千行缺陷密度”，如果能把这三个名词定义清楚并在公司内达成共识，那这肯定是一个非常高质量的指标。

来吐槽的人，显然所处的团队的统计方式有很多不合理的地方，都不用说 `.git` 和 `.gitignore` 了，像是`node_module` 或是其他包管理可能都没做特殊处理，还可以用各种 lint 来操作。而行数统计就是直接粗暴叠加每个 commit 中的行数。

一句话总结：某人把一个连名字都没搞明白的理论直接搬到团队里，实际应用时一塌糊涂

哈哈经典套路

@Yuanlaoer #81 我觉得你说的是正确的，但是如果千行缺陷密度都应用不好的公司，那流程上可以称为是“小作坊”，应用任何质量管理工具都会出现各种乱象……

@nevin47 嗯，听起来你在这方面很厉害，或比较幸运，接触到的人都是专业性很强的。很羡慕。

我体验过牛逼老板领导，即使对每一个 commit message 都有极其苛刻的要求。这种工作氛围下，即使被批评，我也觉得是良性的，会让我更想多工作。但，如果你体验过外行来领导的话，那这种“千行 BUG”的统计就变成噩梦了。