PTT數位生活區 / C_and_CPP (C/C++)

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

看板C_and_CPP (C/C++)作者 (JOMI)時間4年前 (2020/05/11 01:38), 4年前編輯推噓13(14推 1噓 84→)
留言99則, 19人參與, 4年前最新討論串1/5 (看更多)
文有點長 由於跟外國同事共同開發程式互相有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
→
05/11 04:57, 4年前 , 1F
放大絕 說他那樣寫unreadable
05/11 04:57, 1F
推
05/11 06:43, 4年前 , 2F
同事： this is my art
05/11 06:43, 2F
→
05/11 06:49, 4年前 , 3F
可能要轉發到 soft job 版做諮詢
05/11 06:49, 3F
推
05/11 08:35, 4年前 , 4F
他是只從c++11開始學的嗎 蠻多觀念是The C++ Programmin
05/11 08:35, 4F
→
05/11 08:35, 4年前 , 5F
g Language第四版上寫到的
05/11 08:35, 5F
→
05/11 08:37, 4年前 , 6F
但全盤接受不思考情境就用感覺很差
05/11 08:37, 6F
推
05/11 08:47, 4年前 , 7F
10不就是應該用forward嗎？用move的話要是lvalue ref傳
05/11 08:47, 7F
→
05/11 08:47, 4年前 , 8F
進來會不小心被move？
05/11 08:47, 8F
→
05/11 09:23, 4年前 , 9F
@mintece: 不對 這邊的話不是forwarding reference
05/11 09:23, 9F
→
05/11 09:24, 4年前 , 10F
這邊確實是rvalue ref 但是剛好用forward效果一樣
05/11 09:24, 10F
→
05/11 09:24, 4年前 , 11F
@wawi2: 就是因為我說不好讀 他說他覺得好讀, 他大絕就
05/11 09:24, 11F
→
05/11 09:26, 4年前 , 12F
是貼他認同的文章 例如 https://bit.ly/2YNuonr
05/11 09:26, 12F
→
05/11 09:26, 4年前 , 13F
這篇主要不是要找我的同好, 而是想看多數人觀點
05/11 09:26, 13F
→
05/11 09:26, 4年前 , 14F
他有這種堅持我想也許是某些國外有名的人有推, 但我沒有
05/11 09:26, 14F
→
05/11 09:27, 4年前 , 15F
得到他核心的好處 甚至覺得搞得很複雜 難讀
05/11 09:27, 15F
推
05/11 09:45, 4年前 , 16F
從維護和重構上的潛在問題扳倒
05/11 09:45, 16F
推
05/11 09:57, 4年前 , 17F
不影響架構的東西都隨便啦
05/11 09:57, 17F
→
05/11 09:57, 4年前 , 18F
沒定 convention 你管他那麼多
05/11 09:57, 18F
推
05/11 10:12, 4年前 , 19F
但人家都開始強迫別人也這麼寫啦，你不管他那麼多，他倒是
05/11 10:12, 19F
→
05/11 10:12, 4年前 , 20F
管過來了啊XD
05/11 10:12, 20F
→
05/11 11:40, 4年前 , 21F
他那樣好讀嗎? 我怕其實是好讀的 我太墨守陳規了
05/11 11:40, 21F
→
05/11 11:42, 4年前 , 22F
@lovejomi 你是對的，我眼花了。 話說其他同事也有跟你
05/11 11:42, 22F
→
05/11 11:42, 4年前 , 23F
一樣想法的話不能民主決定嗎？
05/11 11:42, 23F
→
05/11 11:52, 4年前 , 24F
我可能有點誇飾了，對方沒有直接強迫要你改，整個團隊
05/11 11:52, 24F
→
05/11 11:52, 4年前 , 25F
很熟C++的人不多, 我熟 那位同事也熟，其他人不熟或是
05/11 11:52, 25F
→
05/11 11:52, 4年前 , 26F
只寫過c++11之前的程式，但另一位外國同事不熟新語法(
05/11 11:52, 26F
→
05/11 11:52, 4年前 , 27F
還在C++11之前) 會覺得他寫的似乎都有其道理
05/11 11:52, 27F
→
05/11 11:52, 4年前 , 28F
例如他說了什麼comment 另一個就會說 I agree with XXX
05/11 11:52, 28F
→
05/11 11:52, 4年前 , 29F
, you should use XXXXXXXXXXXXXX
05/11 11:52, 29F
→
05/11 11:52, 4年前 , 30F
然後風向就是他們的了, 對方口氣不是強制要你改 但口氣
05/11 11:52, 30F
→
05/11 11:52, 4年前 , 31F
會是讓你感覺不改好像我冥頑不靈..
05/11 11:52, 31F
→
05/11 11:52, 4年前 , 32F
並且他這樣把他的style帶進來 會讓整份code四不像....真
05/11 11:52, 32F
→
05/11 11:52, 4年前 , 33F
心覺得難讀，但還是必須提出來討論，畢竟對方有堅持有
05/11 11:52, 33F
→
05/11 11:52, 4年前 , 34F
讀書應該是有一些值得學習的好處只是我目前看不到
05/11 11:52, 34F
推
05/11 13:06, 4年前 , 35F
可以找些core guideline 或知名的style guide 參考
05/11 13:06, 35F
→
05/11 13:06, 4年前 , 36F
硬要用auto 是有點怪了啦
05/11 13:06, 36F
→
05/11 13:07, 4年前 , 37F
return std::move 只有很少狀況好用 而且會block copy
05/11 13:07, 37F
→
05/11 13:07, 4年前 , 38F
elision. 這應該可以貼出standard 反制了
05/11 13:07, 38F
推
05/11 13:14, 4年前 , 39F
我記得return std::move根本多餘,編譯器自己就很清楚
05/11 13:14, 39F
噓
05/11 13:15, 4年前 , 40F
returen std::move根本多餘 他根本沒唸書吧
05/11 13:15, 40F
→
05/11 13:15, 4年前 , 41F
effective modern c++就有提到不需要return move
05/11 13:15, 41F
→
05/11 13:18, 4年前 , 42F
該怎麼做；第6點踩到我的地雷了,除錯時會很棘手
05/11 13:18, 42F
推
05/11 13:21, 4年前 , 43F
同意 想要c++17化就不要macro 用template
05/11 13:21, 43F
→
05/11 13:21, 4年前 , 44F
我對auto的理解是"不用重複寫type",等號右邊有寫就不
05/11 13:21, 44F
→
05/11 13:25, 4年前 , 45F
用左邊也寫一遍,或者你不關心型態是什麼的時候才用
05/11 13:25, 45F
→
05/11 14:08, 4年前 , 46F
裡面我唯一會幫他說話的是9，但不是因為寫std::不好
05/11 14:08, 46F
→
05/11 14:09, 4年前 , 47F
而是因為這種東西整個團隊一致的話比較不會有強迫症問
05/11 14:09, 47F
→
05/11 14:09, 4年前 , 48F
題xd 不過要和他一致或和你一致這我也沒意見xd
05/11 14:09, 48F
推
05/11 17:01, 4年前 , 49F
6是真的很噁心，而且macro這東西也要自己看過內容才知道怎
05/11 17:01, 49F
→
05/11 17:01, 4年前 , 50F
麼用不會冒出莫名其妙的問題啊XD
05/11 17:01, 50F
→
05/11 17:02, 4年前 , 51F
6只有ioccc之類比賽好用吧XDDD
05/11 17:02, 51F
→
05/11 19:42, 4年前 , 52F
學半套笑死 xD
05/11 19:42, 52F
→
05/11 20:06, 4年前 , 53F
大部分是anti pattern就不多說了，要是他在code review意
05/11 20:06, 53F
→
05/11 20:06, 4年前 , 54F
見很多，可以請他寫一份coding guideline，大家再來review
05/11 20:06, 54F
→
05/11 20:06, 4年前 , 55F
。客觀來說就算他說的是對的，整天code review要改這些很
05/11 20:06, 55F
→
05/11 20:06, 4年前 , 56F
沒效率。記得規則訂好再找個自動檢查的tool。
05/11 20:06, 56F
推
05/11 20:09, 4年前 , 57F
第八點是為了透過 ADL 讓所謂的 extension code 可以
05/11 20:09, 57F
→
05/11 20:09, 4年前 , 58F
動, 這個尤其在引入第三方函式庫的時候需要做更新或
05/11 20:09, 58F
→
05/11 20:09, 4年前 , 59F
是改變行為時可用, 但 C++17 以前不會用 qualified n
05/11 20:09, 59F
→
05/11 20:09, 4年前 , 60F
ame 來呼叫, 在 C++20 以後因為有 CPO 所以反而要用
05/11 20:09, 60F
→
05/11 20:09, 4年前 , 61F
qualified name, 未來的函式庫像也都是朝著 non-mem
05/11 20:09, 61F
→
05/11 20:09, 4年前 , 62F
ber/rangify 的方向走, 你自己倒是用直接寫扣把擴充
05/11 20:09, 62F
→
05/11 20:09, 4年前 , 63F
性給殺掉了. 一部分是你的問題, 但雙方對 feature 一
05/11 20:09, 63F
→
05/11 20:09, 4年前 , 64F
知半解, 我覺得就算發文解釋也不會有效果就是, 就像
05/11 20:09, 64F
→
05/11 20:09, 4年前 , 65F
你即使無法接受同事的寫法也不會去了解原因一樣
05/11 20:09, 65F
→
05/11 20:14, 4年前 , 66F
第 9 點也是一樣的, 如果 std:: 的東西沒那麼 powerf
05/11 20:14, 66F
→
05/11 20:14, 4年前 , 67F
ul, 需要擴充的時候, 你會發現所有寫 std:: 的地方全
05/11 20:14, 67F
→
05/11 20:14, 4年前 , 68F
都要砍掉重寫, 如果你的 interface type 也都用 full
05/11 20:14, 68F
→
05/11 20:14, 4年前 , 69F
y qualified name 來寫那真的就是災難. 看敘述你的同
05/11 20:14, 69F
→
05/11 20:14, 4年前 , 70F
事的開發經驗應該比你豐富很多
05/11 20:14, 70F
→
05/11 20:17, 4年前 , 71F
沒有 code 是不需要修改的, 所以 code 要儘量寫得很
05/11 20:17, 71F
→
05/11 20:17, 4年前 , 72F
generic (不限於模板), 這個在 C++ 的演進可以看出這
05/11 20:17, 72F
→
05/11 20:17, 4年前 , 73F
個核心思想: type constraint, meta class. 寫得像 j
05/11 20:17, 73F
→
05/11 20:17, 4年前 , 74F
ava 的東西直接丟掉就好了
05/11 20:17, 74F
→
05/11 20:31, 4年前 , 75F
他的某些用法在開發跨平台/語言標準的函式庫時很常見
05/11 20:31, 75F
→
05/11 20:31, 4年前 , 76F
, 嘗試去思考: 如何把 code 寫成讓不同編譯器吃都能
05/11 20:31, 76F
→
05/11 20:31, 4年前 , 77F
過, 就能理解這個觀念. 如果只是寫 app 可以不用知道
05/11 20:31, 77F
→
05/11 20:31, 4年前 , 78F
那麼多
05/11 20:31, 78F
推
05/12 13:50, 4年前 , 79F
這跟拿佛經遇到拿聖經講話的很像
05/12 13:50, 79F
→
05/12 13:50, 4年前 , 80F
互相傷害個幾次才知道尊重
05/12 13:50, 80F
→
05/12 13:50, 4年前 , 81F
光是google coding style和llvm style就有衝突的地方了
05/12 13:50, 81F
→
05/12 13:50, 4年前 , 82F
對方愛貼文章你也貼文章和影片反擊
05/12 13:50, 82F
→
05/12 16:01, 4年前 , 83F
對方有母語優勢，吸收新知的速度比你快，但基礎觀念有缺
05/12 16:01, 83F
→
05/12 16:01, 4年前 , 84F
陷，你基礎觀念有些地方比他好，但是吸收新知速度沒他快
05/12 16:01, 84F
→
05/12 16:02, 4年前 , 85F
，所以你很容易被大量主流社群文章扳倒。
05/12 16:02, 85F
→
05/12 16:02, 4年前 , 86F
所以除非你自身能更進步，否則只能尋求政治解。
05/12 16:02, 86F
→
05/12 16:03, 4年前 , 87F
拿 google 和 llvm coding style 講不贏這種人，因為那些
05/12 16:03, 87F
→
05/12 16:04, 4年前 , 88F
style 確實是由一知半解和顧慮一知半解的多數族群制訂的
05/12 16:04, 88F
→
05/12 16:04, 4年前 , 89F
，專注在 C++ 領域的人有不少人對這些 style 很輕蔑。
05/12 16:04, 89F
→
05/12 16:05, 4年前 , 90F
不要說國外，光 llvm 那份丟到板上來可能也有不少人不屑
05/12 16:05, 90F
→
05/12 20:00, 4年前 , 91F
五五波 他有些堅持是對的 有些應該是suggestions不應
05/12 20:00, 91F
→
05/12 20:00, 4年前 , 92F
該強制
05/12 20:00, 92F
推
05/12 20:04, 4年前 , 93F
不論是coding style 還是 commit 的衝突
05/12 20:04, 93F
→
05/12 20:04, 4年前 , 94F
一律推薦出去外面打
05/12 20:04, 94F
→
05/13 04:34, 4年前 , 95F
7很好用,特別是讓自家的程式適應各種的規格變動,14是延
05/13 04:34, 95F
→
05/13 04:34, 4年前 , 96F
伸7的設計
05/13 04:34, 96F
→
05/13 15:38, 4年前 , 97F
@tinlans 說出我的心裡話 母語優勢讓我覺得速度沒他快
05/13 15:38, 97F
推
05/14 01:19, 4年前 , 98F
太呱張了吧
05/14 01:19, 98F
→
05/19 19:51, 4年前 , 99F
1.看公司規定 2.看職位高低 3.看主管挺誰...
05/19 19:51, 99F
‣ 更多 lovejomi 的文章
文章代碼(AID): #1Uk3mZ54 (C_and_CPP)
C_and_CPP 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 lovejomi 的文章
文章代碼(AID): #1Uk3mZ54 (C_and_CPP)