[討論] 對於同事的coding style感到很感冒

[lovejomi (JOMI)]

文有點長

由於跟外國同事共同開發程式互相有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...但這版似乎沒特別針對這些來討論

希望得到大家的回饋，有些也許真的是被鼓勵的但我還沒學到真諦

謝謝

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 27.247.130.34 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1589132323.A.144.html
※ 編輯: lovejomi (27.247.130.34 臺灣), 05/11/2020 01:44:42
※ 編輯: lovejomi (27.247.130.34 臺灣), 05/11/2020 01:49:03
※ 編輯: lovejomi (27.247.130.34 臺灣), 05/11/2020 01:52:03
※ 編輯: lovejomi (27.247.130.34 臺灣), 05/11/2020 01:59:26
※ 編輯: lovejomi (27.247.130.34 臺灣), 05/11/2020 02:04:12
※ 編輯: lovejomi (27.247.130.34 臺灣), 05/11/2020 02:25:15
※ 編輯: lovejomi (27.247.130.34 臺灣), 05/11/2020 02:35:04
→ wawi2: 放大絕  說他那樣寫unreadable
推 Morris1028: 同事： this is my art
→ Morris1028: 可能要轉發到 soft job 版做諮詢
推 ko27tye: 他是只從c++11開始學的嗎 蠻多觀念是The C++ Programmin
→ ko27tye: g Language第四版上寫到的
→ ko27tye: 但全盤接受不思考情境就用感覺很差
推 mintece: 10不就是應該用forward嗎？用move的話要是lvalue ref傳
→ mintece: 進來會不小心被move？
→ lovejomi: @mintece: 不對 這邊的話不是forwarding reference
→ lovejomi: 這邊確實是rvalue ref 但是剛好用forward效果一樣
→ lovejomi: @wawi2: 就是因為我說不好讀 他說他覺得好讀, 他大絕就
→ lovejomi: 是貼他認同的文章 例如 https://bit.ly/2YNuonr
→ lovejomi: 這篇主要不是要找我的同好, 而是想看多數人觀點
→ lovejomi: 他有這種堅持我想也許是某些國外有名的人有推, 但我沒有
→ lovejomi: 得到他核心的好處 甚至覺得搞得很複雜 難讀
推 Morris1028: 從維護和重構上的潛在問題扳倒
推 CoNsTaR: 不影響架構的東西都隨便啦
→ CoNsTaR: 沒定 convention 你管他那麼多
推 ddavid: 但人家都開始強迫別人也這麼寫啦，你不管他那麼多，他倒是
→ ddavid: 管過來了啊XD
→ lovejomi: 他那樣好讀嗎? 我怕其實是好讀的 我太墨守陳規了
→ mintece: @lovejomi 你是對的，我眼花了。 話說其他同事也有跟你
→ mintece: 一樣想法的話不能民主決定嗎？
→ lovejomi: 我可能有點誇飾了，對方沒有直接強迫要你改，整個團隊
→ lovejomi:  很熟C++的人不多, 我熟 那位同事也熟，其他人不熟或是
→ lovejomi: 只寫過c++11之前的程式，但另一位外國同事不熟新語法(
→ lovejomi: 還在C++11之前) 會覺得他寫的似乎都有其道理
→ lovejomi: 例如他說了什麼comment 另一個就會說  I agree with XXX
→ lovejomi: , you should use XXXXXXXXXXXXXX
→ lovejomi: 然後風向就是他們的了, 對方口氣不是強制要你改 但口氣
→ lovejomi: 會是讓你感覺不改好像我冥頑不靈..
→ lovejomi: 並且他這樣把他的style帶進來 會讓整份code四不像....真
→ lovejomi: 心覺得難讀，但還是必須提出來討論，畢竟對方有堅持有
→ lovejomi: 讀書應該是有一些值得學習的好處只是我目前看不到
推 steve1012: 可以找些core guideline 或知名的style guide 參考
→ steve1012: 硬要用auto 是有點怪了啦
→ steve1012: return std::move 只有很少狀況好用 而且會block copy
→ steve1012:  elision. 這應該可以貼出standard 反制了
推 eye5002003: 我記得return std::move根本多餘,編譯器自己就很清楚
噓 MartinJ40: returen std::move根本多餘 他根本沒唸書吧
→ MartinJ40: effective modern c++就有提到不需要return move
→ eye5002003: 該怎麼做；第6點踩到我的地雷了,除錯時會很棘手
推 MartinJ40: 同意  想要c++17化就不要macro  用template
→ eye5002003: 我對auto的理解是"不用重複寫type",等號右邊有寫就不
→ eye5002003: 用左邊也寫一遍,或者你不關心型態是什麼的時候才用
→ shadow0326: 裡面我唯一會幫他說話的是9，但不是因為寫std::不好
→ shadow0326: 而是因為這種東西整個團隊一致的話比較不會有強迫症問
→ shadow0326: 題xd 不過要和他一致或和你一致這我也沒意見xd
推 ddavid: 6是真的很噁心，而且macro這東西也要自己看過內容才知道怎
→ ddavid: 麼用不會冒出莫名其妙的問題啊XD
→ ddavid: 6只有ioccc之類比賽好用吧XDDD
→ loveme00835: 學半套笑死 xD
→ nevak: 大部分是anti pattern就不多說了，要是他在code review意
→ nevak: 見很多，可以請他寫一份coding guideline，大家再來review
→ nevak: 。客觀來說就算他說的是對的，整天code review要改這些很
→ nevak: 沒效率。記得規則訂好再找個自動檢查的tool。
推 loveme00835: 第八點是為了透過 ADL 讓所謂的 extension code 可以
→ loveme00835: 動, 這個尤其在引入第三方函式庫的時候需要做更新或
→ loveme00835: 是改變行為時可用, 但 C++17 以前不會用 qualified n
→ loveme00835: ame  來呼叫, 在 C++20 以後因為有 CPO 所以反而要用
→ loveme00835:  qualified name, 未來的函式庫像也都是朝著 non-mem
→ loveme00835: ber/rangify 的方向走, 你自己倒是用直接寫扣把擴充
→ loveme00835: 性給殺掉了. 一部分是你的問題, 但雙方對 feature 一
→ loveme00835: 知半解, 我覺得就算發文解釋也不會有效果就是, 就像
→ loveme00835: 你即使無法接受同事的寫法也不會去了解原因一樣
→ loveme00835: 第 9 點也是一樣的, 如果 std:: 的東西沒那麼 powerf
→ loveme00835: ul, 需要擴充的時候, 你會發現所有寫 std:: 的地方全
→ loveme00835: 都要砍掉重寫, 如果你的 interface type 也都用 full
→ loveme00835: y qualified name 來寫那真的就是災難. 看敘述你的同
→ loveme00835: 事的開發經驗應該比你豐富很多
→ loveme00835: 沒有 code 是不需要修改的, 所以 code 要儘量寫得很
→ loveme00835: generic (不限於模板), 這個在 C++ 的演進可以看出這
→ loveme00835: 個核心思想: type constraint, meta class. 寫得像 j
→ loveme00835: ava 的東西直接丟掉就好了
→ loveme00835: 他的某些用法在開發跨平台/語言標準的函式庫時很常見
→ loveme00835: , 嘗試去思考: 如何把 code 寫成讓不同編譯器吃都能
→ loveme00835: 過, 就能理解這個觀念. 如果只是寫 app 可以不用知道
→ loveme00835: 那麼多
推 MartinJ40: 這跟拿佛經遇到拿聖經講話的很像
→ MartinJ40: 互相傷害個幾次才知道尊重
→ MartinJ40: 光是google coding style和llvm style就有衝突的地方了
→ MartinJ40: 對方愛貼文章你也貼文章和影片反擊
→ tinlans: 對方有母語優勢，吸收新知的速度比你快，但基礎觀念有缺
→ tinlans: 陷，你基礎觀念有些地方比他好，但是吸收新知速度沒他快
→ tinlans: ，所以你很容易被大量主流社群文章扳倒。
→ tinlans: 所以除非你自身能更進步，否則只能尋求政治解。
→ tinlans: 拿 google 和 llvm coding style 講不贏這種人，因為那些
→ tinlans: style 確實是由一知半解和顧慮一知半解的多數族群制訂的
→ tinlans: ，專注在 C++ 領域的人有不少人對這些 style 很輕蔑。
→ tinlans: 不要說國外，光 llvm 那份丟到板上來可能也有不少人不屑
→ johnidfet: 五五波 他有些堅持是對的 有些應該是suggestions不應
→ johnidfet: 該強制
推 TakiDog: 不論是coding style 還是 commit 的衝突
→ TakiDog: 一律推薦出去外面打
→ ketrobo: 7很好用,特別是讓自家的程式適應各種的規格變動,14是延
→ ketrobo: 伸7的設計
→ lovejomi: @tinlans 說出我的心裡話 母語優勢讓我覺得速度沒他快
推 TobyH4cker: 太呱張了吧
→ Linvail: 1.看公司規定 2.看職位高低 3.看主管挺誰...
推 cia1099: 其實我覺得他寫的code挺屌又酷的