想吐槽一下经理的code review

别的不说，int vs size_t那个，你认错吧。如果用int，越界了你怎么办？production code直接crash吗？

建议写个格式脚本，每次编译的时候强制运行，格式不正确直接编译报错。

mandmwantapig 发表于 2021-04-27 18:32:23
你们大厂难道code review都这么严格么？

这和狗家的c++ code review比，真得不算什么。不过狗家好在有文档以及一套规范的流程来获得readability。

我也来吐槽 之前追究我variable naming heading 改成header

很多时候他让我改的地方 就不会让另一个senior 改， 也不知道是不是看不见

还有时候 根本就可以实现的solution，非要我改，也不说为什么不好，就是看不惯，可也不给个solution，因为就没有第二个合适的solution，然后核心是改的地方是一个不用了的功能label 和image 中间加空格… 而且根本和我的ticket 无关

还有时候 我做a，他说b也在附近 一起改了吧
然后有时候 我做a，顺便改了b，他说 不行 要独立branch

真的有时候就是看他心情 而且两年下来我一直觉得他是对我个人有意见而不是对我要求严格

还好马上跑路了希望transfer快点

还有一点我不理解， 如果code review 加了你的名字 然后你还没review前就merge了 （另一个人approve了） 这是业界操作吗？ 还是说只是形式上加我个名字🙄习惯了我现在也是看心情review 反正merge 不merge 也和我approve无关

哇, 终于遇到一个跟我遭遇相同的人了, 最近刚加进一个组, 也遇到了类似的同事还不是经理.. 一直抠naming convention, 他的还不对, 指出来有错了还死要我改成他那样... 每次找他review 代码都有督促我刷题的功效..不说了, 刷题去了...

大厂这个是lint提醒的，size_t， 多空行，多空格

其实size_t比int更危险。。。size_t可以荣登cpp最差的几个设计之一了。

说实话，作为管理者，我也觉得code_review组内统一格式最好，你的交付就是你的code，虽然很多时候以功能出发，但是，他作为管理者这么做，为的就是提高组内的工作效率，吹毛求疵不必，但是规范统一很重要

这个没啥说的， 搞个Coding Standard或者用工具实现就好了。 大厂都这样。