[討論] 對於同事的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