[讨论] 对于同事的coding style感到很感冒

楼主: lovejomi (JOMI)   2020-05-11 01:38:41
文有点长
由于跟外国同事共同开发程式互相有code review.
某位同事写的code已经有点超过了, 并且会干预其他人如果不是他那种style写法 会要求
改正
以下是 每一种写法 我标数字 目的是希望大家可以给我一些建议是不是他太超过还是我
还无法体会他的好
1.
auto v = Foo<int>{};
auto v = vector<int>{};
// 永远使用{}, {} 在container上很好读, 但他不管怎样一定是{}, ()已近乎消失
// 永远auto =
// vector<int> v; 臭了吗....
我个人觉得不该滥用 "等号"
我有用一些观点例如
copy cstor被delete情况, 只是因为你现在用c++17才给过, 建议他可以考虑相容c++14
但也是被驳回 说 不需考虑.
int a = 1; 写成 int a{1}就很怪
Foo f{1,2,3}; 会让我以为他提供initializer_list 的建构子
殊不知其实只是想呼叫 Foo(int,int,int)版本的, 这样写真的是被鼓励的吗?
我觉得要变通而不是完全弃用 () 建构
2. 承上
auto ptr = static_cast<Foo*>(nullptr);
就是不肯 Foo*ptr = nullptr;
甚至他写
struct Data
{
auto A = std::string{};
auto B = ENUM::X;
auto C = int{};
auto id = static_cast<add_pointer<GUID>::type>(nullptr);
}
这很夸张
我对于struct肯定是不用auto
甚至我想问各位 struct 每个element都给初始直 这是好的吗?
对我来讲这是使用这struct的人的义务
Data d{....给初始直}
or
d.A =
d.B = 一个一个给
不知道各位喜欢哪种 针对struct
3. 承上
auto p = std::add_pointer<void>::type{XXX};
auto p = std::add_pointer<int>::type{...};
之前他因为不知道std有提供add_pointer, 还刻意写一个traits 为了写出这行
int* p = ....; 竟然不是他脑中的首选....我实在无法理解
4. 承上
auto Foo(..............................................................) ->
void
auto Bar(..............................................................) ->
std::vector<...>
永远都是auto -> type 的写法
甚至
auto main(..) -> void
这trailing return type我一直无法体会好处,除非要deduction不然到底优点是什么?
5.
auto const* p = ....;
基本上这没问题 但是多数人都是const auto* p; 但她却坚持不follow多数
6.
大量使用3rd MACRO,让程式码呈现类似
XXX_RETURN_YY_IF(Method());
LOG_ERROR_IF(!rc);
auto XXX -> noexcept
TRY();
CATCH_RETURN();
THROW_IF(.....);
只要他写的code都是这种长相的....说真的对我来讲好难读...
甚至写一段程式没用到macro 还会担心是不是有macro可套
7. 坚持C++ exception 一定比error code来的好
所以要求团队有error都要用exception, 如果实作上用exception会不好设计的话请提出

当成特例来讨论
对于noexcept有没有加非常计较跟坚持
如果设计dll
errorcode dllexport... API()
{
try
{
auto rc = XXX();
if(rc == FAILED) { throw yyyy; 让下面接}
return success;
}
catch(...)
{
return yyy;
}
}
为了用exception....但又不能往dll外丢 竟然自丢自接...无法理解
8.
std::size() std::data() std::begin() std::end()
只要用了
type.size() type.data() type.begin type.end都会被逼着改...
我想说的是 如果写template code当然用std::xxx会更generic....但不是, 都是在非te
mplate情形,用自己member 合情合理(是不是可以减少compile 时间,因为不用产生tem
plate程式码?)
9.
写出
std::chrono::....
会被要求改成namespace chrono = std::chrono
这我有点傻眼 写std::不是明确又更好理解吗?
10.
template<class T>
class Foo
{
void Bar(T&& t){
Baz(std::forward<T>(t));
}
};
坚持说是用forward, 给他很多例子跟gcc vector实作也无法接受...
但因为结果论 是一样的效果,所以我说服失败,反倒是被质疑只写std::move是想少打字
吧?
11.
class Foo
{
std::string s{};
vector<int> v{};
int a{};
Type x{};
};
这边要说的是....{}固然没问题, 但 不加不是更简洁好读?
int a{} 为什么就是不肯 = 0? 甚至 有时候会写 int a{0};
12. 几乎写一般函数都写在header然后冠上inline(一看也觉得不可能inline成功的)
理由说 有文章说让compiler自己决定能不能inline, 程式效能更好(成功算赚到).
class的话也是尽可能实作写header (反正内部的code, 不是要变成shared library)
其实wiki也写了缺点,header only难道在非template library上有也是被鼓励的吗?(
假设code size变大 不重要)
13. 承上
class Foo{ static int a; 坚持不写 一定要写 inline int a;}
他认为的好处是 不用特别找cpp写定义, 更能贯彻header only 的写法
14. 因为会写windows平台的程式
他会把用到的win32 api都wrap一层
例如
raii_handle
CreateThread(...)
{
auto h = ::Creathread(...)
THROW_IF(!h)
return h;
}
之类的 方向是把win32 error code base的api变成exception based....
C++真的exception是被鼓励的吗? 对我来看 B>Z阿...
其实还有很多而且越读他的code会越多奇怪的坚持产生
例如
return std::move(local var)...
刚好vc似乎不会跳warning变成好像很难说服他改掉(我说这多余的,且限制最佳化了,
但被无视)
对方大方向是
大量使用auto , 增加"可读性", 读者or呼叫者不care型态 用auto完全的对他来讲好读
(我完全相反 让我理解力大减 我还要多跳过去定义看型别 去思考是否有问题,
auto XXX(....很长)-> type , 我为了要看type我还要拖曳到右边看.)
对方认定
vector<int> v;是 c style 初始方法 要大家用C++ style
auto v = vector<int>{};写
对方非常爱贴文章
只要你提出相反意见他都可以拿文章来回 要我去看文章(还有所谓的AAA style....)
对方是真的花心思会去follow youtube cppconf的talk....
但共识久了 会觉得对方 真的是教课书说什么就什么 而且似乎查资料只查他认同的
关键字很可能都是下
"exception better than error code c++" 之类的找文章....
我不喜欢这种照本宣科的, 但只要他一贴文章大概就句点了 (又臭又长, 我也不想细看
反正用英文讲不赢)
请各位提供一些意见
当然这些都是被网络上广泛讨论的topic...但这版似乎没特别针对这些来讨论
希望得到大家的回馈,有些也许真的是被鼓励的但我还没学到真谛
谢谢
作者: wawi2 (@@)   2020-05-11 04:57:00
放大绝 说他那样写unreadable
作者: Morris1028 (某 M)   2020-05-11 06:43:00
同事: this is my art可能要转发到 soft job 版做咨询
作者: ko27tye (好滋好滋)   2020-05-11 08:35:00
他是只从c++11开始学的吗 蛮多观念是The C++ Programming Language第四版上写到的但全盘接受不思考情境就用感觉很差
作者: mintece (XD)   2020-05-11 08:47:00
10不就是应该用forward吗?用move的话要是lvalue ref传进来会不小心被move?
楼主: lovejomi (JOMI)   2020-05-11 09:23:00
@mintece: 不对 这边的话不是forwarding reference这边确实是rvalue ref 但是刚好用forward效果一样@wawi2: 就是因为我说不好读 他说他觉得好读, 他大绝就是贴他认同的文章 例如 https://bit.ly/2YNuonr这篇主要不是要找我的同好, 而是想看多数人观点他有这种坚持我想也许是某些国外有名的人有推, 但我没有得到他核心的好处 甚至觉得搞得很复杂 难读
作者: Morris1028 (某 M)   2020-05-11 09:45:00
从维护和重构上的潜在问题扳倒
作者: CoNsTaR ((const *))   2020-05-11 09:57:00
不影响架构的东西都随便啦没定 convention 你管他那么多
作者: ddavid (谎言接线生)   2020-05-11 10:12:00
但人家都开始强迫别人也这么写啦,你不管他那么多,他倒是管过来了啊XD
楼主: lovejomi (JOMI)   2020-05-11 11:40:00
他那样好读吗? 我怕其实是好读的 我太墨守陈规了
作者: mintece (XD)   2020-05-11 11:42:00
@lovejomi 你是对的,我眼花了。 话说其他同事也有跟你一样想法的话不能民主决定吗?
楼主: lovejomi (JOMI)   2020-05-11 11:52:00
我可能有点夸饰了,对方没有直接强迫要你改,整个团队很熟C++的人不多, 我熟 那位同事也熟,其他人不熟或是只写过c++11之前的程式,但另一位外国同事不熟新语法(还在C++11之前) 会觉得他写的似乎都有其道理例如他说了什么comment 另一个就会说 I agree with XXX, you should use XXXXXXXXXXXXXX然后风向就是他们的了, 对方口气不是强制要你改 但口气会是让你感觉不改好像我冥顽不灵..并且他这样把他的style带进来 会让整份code四不像....真心觉得难读,但还是必须提出来讨论,毕竟对方有坚持有读书应该是有一些值得学习的好处只是我目前看不到
作者: steve1012 (steve)   2020-05-11 13:06:00
可以找些core guideline 或知名的style guide 参考硬要用auto 是有点怪了啦return std::move 只有很少状况好用 而且会block copyelision. 这应该可以贴出standard 反制了
作者: eye5002003 (下一夜)   2020-05-11 13:14:00
我记得return std::move根本多余,编译器自己就很清楚
作者: MartinJ40 (Martin J-40)   2020-05-11 13:15:00
returen std::move根本多余 他根本没唸书吧effective modern c++就有提到不需要return move
作者: eye5002003 (下一夜)   2020-05-11 13:18:00
该怎么做;第6点踩到我的地雷了,除错时会很棘手
作者: MartinJ40 (Martin J-40)   2020-05-11 13:21:00
同意 想要c++17化就不要macro 用template
作者: eye5002003 (下一夜)   2020-05-11 13:21:00
我对auto的理解是"不用重复写type",等号右边有写就不用左边也写一遍,或者你不关心型态是什么的时候才用
作者: shadow0326 (非议)   2020-05-11 14:08:00
里面我唯一会帮他说话的是9,但不是因为写std::不好而是因为这种东西整个团队一致的话比较不会有强迫症问题xd 不过要和他一致或和你一致这我也没意见xd
作者: ddavid (谎言接线生)   2020-05-11 17:01:00
6是真的很恶心,而且macro这东西也要自己看过内容才知道怎么用不会冒出莫名其妙的问题啊XD6只有ioccc之类比赛好用吧XDDD
作者: loveme00835 (发箍)   2020-05-11 19:42:00
学半套笑死 xD
作者: nevak (^o^)   2020-05-11 20:06:00
大部分是anti pattern就不多说了,要是他在code review意见很多,可以请他写一份coding guideline,大家再来review。客观来说就算他说的是对的,整天code review要改这些很没效率。记得规则订好再找个自动检查的tool。
作者: loveme00835 (发箍)   2020-05-11 20:09:00
第八点是为了透过 ADL 让所谓的 extension code 可以动, 这个尤其在引入第三方函式库的时候需要做更新或是改变行为时可用, 但 C++17 以前不会用 qualified name 来呼叫, 在 C++20 以后因为有 CPO 所以反而要用qualified name, 未来的函式库像也都是朝着 non-member/rangify 的方向走, 你自己倒是用直接写扣把扩充性给杀掉了. 一部分是你的问题, 但双方对 feature 一知半解, 我觉得就算发文解释也不会有效果就是, 就像你即使无法接受同事的写法也不会去了解原因一样第 9 点也是一样的, 如果 std:: 的东西没那么 powerful, 需要扩充的时候, 你会发现所有写 std:: 的地方全都要砍掉重写, 如果你的 interface type 也都用 fully qualified name 来写那真的就是灾难. 看叙述你的同事的开发经验应该比你丰富很多没有 code 是不需要修改的, 所以 code 要尽量写得很generic (不限于模板), 这个在 C++ 的演进可以看出这个核心思想: type constraint, meta class. 写得像 java 的东西直接丢掉就好了他的某些用法在开发跨平台/语言标准的函式库时很常见, 尝试去思考: 如何把 code 写成让不同编译器吃都能过, 就能理解这个观念. 如果只是写 app 可以不用知道那么多
作者: MartinJ40 (Martin J-40)   2020-05-12 13:50:00
这跟拿佛经遇到拿圣经讲话的很像互相伤害个几次才知道尊重光是google coding style和llvm style就有冲突的地方了对方爱贴文章你也贴文章和影片反击
作者: tinlans ( )   2020-05-12 16:01:00
对方有母语优势,吸收新知的速度比你快,但基础观念有缺陷,你基础观念有些地方比他好,但是吸收新知速度没他快,所以你很容易被大量主流社群文章扳倒。所以除非你自身能更进步,否则只能寻求政治解。拿 google 和 llvm coding style 讲不赢这种人,因为那些style 确实是由一知半解和顾虑一知半解的多数族群制订的,专注在 C++ 领域的人有不少人对这些 style 很轻蔑。不要说国外,光 llvm 那份丢到板上来可能也有不少人不屑
作者: johnidfet   2020-05-12 20:00:00
五五波 他有些坚持是对的 有些应该是suggestions不应该强制
作者: TakiDog (多奇狗)   2020-05-12 20:04:00
不论是coding style 还是 commit 的冲突一律推荐出去外面打
作者: ketrobo (猫萝卜)   2020-05-13 04:34:00
7很好用,特别是让自家的程式适应各种的规格变动,14是延伸7的设计
楼主: lovejomi (JOMI)   2020-05-13 15:38:00
@tinlans 说出我的心里话 母语优势让我觉得速度没他快
作者: TobyH4cker (Toby (我要当好人))   2020-05-14 01:19:00
太呱张了吧
作者: Linvail (...)   2020-05-19 19:51:00
1.看公司规定 2.看职位高低 3.看主管挺谁...

Links booklink

Contact Us: admin [ a t ] ucptt.com