Re: [討論] 寫三元判斷式code review被打槍
※ 引述《applebg (Eugenicist)》之銘言：
: 藉這個主題問各位一個問題。
: 我想知道怎麼樣的語法才是公認最簡潔最沒有歧異
沒有
沒有什麼公認
要解決coding style
最好的辦法就是CTO大頭召集全部RD開會
把這間公司的coding style全都記下來
整理在公司內部的文件裡
越詳細越好
以後大家乖乖照著規範走
沒規範到的
有爭議的
就再開會討論
看你們要投票還是要吵架都可以
最後弄出一個規範加上去
然後以後就這樣做
最糟糕的就是說要「開放讓大家自由撰寫」的政策
這除了搞人以外
就是有自以為是的天兵自搞一個莫名其妙的寫法
然後再來說
啊我習慣這樣
習你的頭
來公司上班
就是照個制度走
但沒制度
那就是公司團隊的問題
沒制度的團隊
除非人很少兩三隻小貓的新創
不然還是早點更新你的履歷
另謀高就得好
--
coding style是規定不完的
bug是修不完的不如別修了
幹麻召集所有RD你真以為RD多厲害？？
召集是給你尊重告知你公司現在要規定 你不尊重你底下的人也可以直接發公告 今天就是照這樣做 不照做就滾
連3元都說很難的，你召集幹媽
難不難你說了算你是老闆嗎你是主管嗎？ 你是的話你可以規定不準寫if以後只能寫三元也可以啊你開心就好
一、二、 三元～
我團隊就是 開放讓大家自由撰寫
其實也 運作的很好
大家都沒毛病
我待過的公司都算滿開放的 就算有code review 沒有寫太
誇張都會給過...但覺得這系列討論下來有點太過
沒事就沒事啊 那有事就要解決啊 除非你跟某人一樣啦 要改的地方太多了 還是改天吧 誰雇用到這種員工真的誰倒楣
直接在CI/CD限制一些基本的應該比較容易？
只能縮呆丸有呆丸的玩法
十個菜雞給你投票壓死你，還投票勒
我有說用開會就是只有投票嗎？ 我真懷疑你們這群到底有沒有出社會工作過
※ 編輯: strlen (118.169.18.238 臺灣), 12/17/2022 10:01:43開會討論不就廣納意見尋找共識？這到底有啥好噓的？
時間很寶貴。花大家時間開會討論這個超級浪費。
如果因為討論後而沒有爭吵，那就不算浪費了
花時間吵這個更浪費時間，沒有更重要的事情了嗎？
就機率問題而已，不定規則也沒事 vs 不定規則就出事
，就看哪個機率高決定而已
不規定就出事的話有決定權的直接規定就好。
不然這個會就改成自由參加 覺得浪費時間你可以不出席 但規定好了你就得遵守啊 方法那麼多不會自己變通？
※ 編輯: strlen (118.169.18.238 臺灣), 12/17/2022 20:11:16CTO應該把時間放在更重要的事情。需要CTO召集大家來討論c
oding style就很荒謬。更別說有上千人規模的公司了。
都有公司總經理親自做 code review 的了
討論 style 有什麼嗎
code review 比拉一（大）群人討論style 有意義多了
95
首Po小弟寫java的 以前常常寫三元判斷式 就比如說 String a; if(con) {18
三元不能用 算還好了 我還遇過 a=1; ... ...11
Code review 檢查這些會有點太花時間，應該有更重要的東西要看。 可以用一些 Gradle plugins 卡在 CI 比較省事： 1. Checkstyle 顧名思義檢查 style。 2. SpotBugs12
從 C++ 的角度來說 三元運算子有機會改變 l-value/r-value 的性質，進而破壞最佳化 舉個簡單例子 可以看到用三元運算子的時候，回傳區域變數竟然要 copy 而不是 move 雖然說 Java 沒有這些![Re: [討論] 寫三元判斷式code review被打槍](https://i.imgur.com/cyrFsY4b.jpg "Re: [討論] 寫三元判斷式code review被打槍")
藉這個主題問各位一個問題。 我想知道怎麼樣的語法才是公認最簡潔最沒有歧異 的語法？我在wikipedia 是看到一本暱稱「K&R 白 皮書」的C 語言教科書，這本書是C 語言的始祖等 級教科書，有些人認為這本書所寫的語法才是程式8
這種事情 不就和阿里巴巴一樣 一開始給大家一本手冊 哪些code 或是哪些style在本公司不要出現![Re: [討論] 寫三元判斷式code review被打槍](https://external-preview.redd.it/6TTm4tS5pMCiq2KlgviubpGKt1QzvetOi2Z6Z3lB1Nc.jpg?width=720&height=376.963350785&auto=webp&crop=720:376.963350785,smart&s=dc5cf91d8f054bb9b0588dbda44272c6eb1e7b19 "Re: [討論] 寫三元判斷式code review被打槍")
1X
隨著語法的進步 很多會寫 code 的人都很少寫判斷式了 不管是三元還是 if else 寫太多的判斷式 如果….所以…否則…如果….則又…如果..24
說到switch，想來問問你各位公司的code style是下面哪種 (1) switch Var1 { case a: xxx![Re: [討論] 寫三元判斷式code review被打槍](https://i.imgur.com/VBSwkjeb.jpg "Re: [討論] 寫三元判斷式code review被打槍")
5
好啦 假設不是反串 我覺得滿有道理的 但有一點其實你說錯了 其實並不是語法進步 之前學 Rust 覺得哇 pattern matching 真是他媽神 好潮喔 後來跑去學 OCaml 我才發現(Rust設計者是OCaml粉 一開始的compiler就是用OCaml寫)9
"特定"情況下的確是好方式 舉個例子 以前我在調校能時候有用過這種方式 這是c#的code部分節錄 void Mem_w(ushort address, byte value) { if (address < 0x2000) NES_MEM[address & 0x7ff] = value;![Re: [討論] 寫三元判斷式code review被打槍](https://dotblogsfile.blob.core.windows.net/user/yastxu/eeba10c7-eb6c-4b2e-9171-803d44efcffe/1484928772_72437.png "Re: [討論] 寫三元判斷式code review被打槍")
27
Re: [討論] 怎麼跟自以為是的同事相處提供一點不一樣的看法 ※ 引述《leo5916267 (封膜獵人)》之銘言： : 也許在軟體也蠻容易遇到類似個性的同事 : 我們是新創公司，我進去前已就有一個前端工程師，他從0建構了整個產品A 代表他能力不算差21
Re: [討論] 怎麼跟自以為是的同事相處看起來是"感受"的問題比較多 codereview 才提開頭一句 就霹靂啪拉回了十句，順帶挑我程式毛病 這句話就如果是正常討論的話 每個人的表達方式都可能不同 有人話少 有人話多 很難說他就是有惡意 況且如果是就事論事的內容而已? 曾經在新創的經驗是 沒文件真的超正常 需求不明也是超正常18
Re: [請益] 當主管要求資深RD撰寫自己經驗的文件原文恕刪, 用職場生存的角度來看,我個人建議是「寫，但場面要搞大」 如果要寫，就好好作，讓它變成一場內部訓練，記得開課發信邀請要cc高層主管 這件事下下策就是賣命寫然後只有寄給開口要求的主管,幫他抬轎 如果真的很忙只能隨便寫,那就做個樣子,寄給大家時補一句17
Re: [討論] 重構之前要寫測試 不然不要重構這就是TAD, 一般做法是假設以前人做的是對的 拿以前的output當測資 避免以後的output跟預期結果不同 技術面的錯誤→沒有防呆/沒有釋放資源/overflow/沒有check 這應該不在討論範圍內, 也有客觀標準 行為與邏輯的部分才是有爭議的, 要嘛根本沒規格只有口傳3
Re: [心得] 如果可以, 真的建議不要再去創業公司了最近公司的狀況讓我有點理解原po的想法 但這應該都是個案啦 只是剛好近期也遇過兩位這樣的人 都是在新創工作&後來新創都收了&一人開發 有時候這種新創就真的不是要做多大的東西