Re: [請益] 痾 遇到這種事情 是不是需要趕快離職了?
※ 引述《saladim (殺拉頂)》之銘言:
: 小魯目前在一家還算大的公司工作 現在有兩三位頂大的junior的同事
: 寫程式的習慣讓我覺得是不是要趕快跑了 舉兩個例子好了
: 他們都喜歡if-else combo, 沒巢狀到波動拳那麼深 但就是動不動就if-else
: 三層 然後三層裡面還會再if-else
: 第二個例子就是如果有function 90%(50~100行)適合他們想要的用途,
: 他們就會copy整個function 然後修改一下後"整段"code插到他們需要的地方
: 光是上面兩個例子已經讓我的頭超大的 原本公司的codebase已經長得像科學怪人
: 了 然後又有他們持續"加持" 根本就沒辦法理解
: 更慘的是 跟他們講他們也不當一回事 又有頂大當紅碩論護體 一副你也不敢砍我的底氣
: 公司也沒人想要當壞人 code review也沒人出聲 而且大家都知道 上市公司每個都喜歡: 有學歷的人當門面 反正真正主力有人會扛 XDDDD
: 每次改到他們經手過的code都很痛苦 若是要幫忙擦屁股根本擦不完阿 因為一直拉....: 自己寶貴的時間也都被吃掉了
: 這樣是不是該走了比較好?
: 我知道爛code到處都是啦 但是至少不能一直拉吧 又是都講不聽的 更資深的也都能閃就?
: 但大家輪流中槍.............
我從上面的文章只看到原po說有很多if...else跟function用原本的copy過來,改一下自己想修改的code
但卻沒看到任何提到效率問題,而且if...else是O(1),並不會拖垮速度。
每個人寫code的習慣不一樣,
有的人喜歡這樣寫
if() {
}
有的人喜歡這樣寫
if()
{
}
有的人喜歡程式碼短就連在一起
if(...) cout << "xxx";
else cout << "bbb";
也有人喜歡短的程式碼連在一起
cout << "請輸入數字月份(1~12):"; cin >> month;
有的人喜歡命名用底線分開,如:month_arr
有些人喜歡用小寫大寫分開,如:monthArr
有些人不喜歡程式碼跟程式碼之間有空一行
while {
....
}
if() {
....
}
for(int i = 0; i < N; i++) {
....
}
但有些人喜歡有空一行
while {
....
}
if() {
....
}
for(int i = 0; i < N; i++) {
....
}
有人程式碼喜歡有空格分開
for(int i = 0; i < N; i++)
有人不喜歡太多空格
for(int i=0; i<N; i++)
以上這些都沒有錯,沒有誰的才是對的,誰才是錯的,重點流程有沒有錯,有沒有bug,執行會不會慢,巢狀迴圈幾層。
執著在那些格式很沒有意義,或誰誰誰寫code格式不符合我意的,就把別人弄走。
你不能說你就是標準,全部人都要跟你的寫法一模一樣,很多人寫程式想的是這個問題要怎麼寫才巧妙解決,而不是十分在乎格式,太執著就有強迫症或太龜毛,合作起來也很痛苦。
放過別人也放過自己,互相尊重。
--
那不是格式問題吧 他明明就是在說波動拳if-else
而且正常的公司明明就會規範coding style你自己亂寫
不要以為每個人都亂寫
我個人認為執行效率,bug rate,unit test,開發速度 比起仔細每個程式碼對有幾個空格,程式碼段落之間有沒有空行,大方向來說更有效率, 程式設計師的目標要產出沒有bug執行速度又快,程式碼又簡潔,開發速度又快。 code review是要讓其他人了解你程式的邏輯思維有沒有盲點,順便也是交接的過程,如 果以後離職別人也懂程式碼流程。
coding style要為"效率"讓步的話那規範的意義在哪
是程式碼執行的效率還是程式碼開發的效率?
二個都很重要。但如果遇到一直挑剃應該多空一格少空一格,大括號這樣括號,不要有段 落空行, 而不是著重在流程,效率計算,使用函式模板 類別模板(c++),java是泛型<T>,程式碼 是那裡會用到模板,我個人覺得理解思維比較重要
※ 編輯: purin88 (42.73.126.116 臺灣), 07/23/2024 14:54:29 ※ 編輯: purin88 (42.73.126.116 臺灣), 07/23/2024 14:55:15 ※ 編輯: purin88 (42.73.126.116 臺灣), 07/23/2024 15:05:08 ※ 編輯: purin88 (42.73.126.116 臺灣), 07/23/2024 15:06:02他問的問題不是style八?還有style也是要確定的八,像我
們用k&r 直接給format 自動排版就全部一致了
這什麼鬼回覆 巢狀if else跟效率本還就沒有關係
就很簡單的不採用clean code的問題
開發效率也很重要更應該規範吧,如果你公司的code都
不用改沒bug不需要debug的話當我沒說
還刪推文是吧 送你進水桶
沒料不用回一篇
工程師真難聊天哈哈
24
首Po小魯目前在一家還算大的公司工作 現在有兩三位頂大的junior的同事 寫程式的習慣讓我覺得是不是要趕快跑了 舉兩個例子好了 他們都喜歡if-else combo, 沒巢狀到波動拳那麼深 但就是動不動就if-else 三層 然後三層裡面還會再if-else 第二個例子就是如果有function 90%(50~100行)適合他們想要的用途,23
等等,我原本以為只是一個簡單的問題 居然歪樓了 推動coding conventions 可以從你我做起 像原原po的問題是 if7
我個人感覺程式語言也是有語感的 跟學歷關係不大 我自己碰過一種寫法 if 變數 == a print 甲.jpg if 變數 == b print 乙.jpg4
實況寫程式的 Tsoding 最新原型作品 - 多人遊戲的伺服器端與客戶端(Typescript) 一堆 if else 裡面還有 if else,最多好像是三層,應該還不至於看不懂,原型的標準 比較低,快速產出才是王道
31
Re: [心得] AmazingTalker/台灣樂天市場 面試心得AmazingTalker CTO 回覆面試心得 (此為 AmazingTalker 人資部門代為轉發) 感謝版友分享在AmazingTalker的面試心得,也感謝各位大大的關心。 在招募過程中,我們一直檢討,並作出相應調整和改善。 當天面試過程不著墨太多。18
Re: [討論] 寫三元判斷式code review被打槍三元不能用 算還好了 我還遇過 a=1; ... ...29
Re: [心得] 好的註解是解釋為何需要這段 code上週在重構某段程式碼時,其中一位同事在 code review 中建議把某個註解刪掉,另一 個同事看到這個評論時,在下面留了言說他認為不應該刪掉,於是我們就拉了一個小討論 ,聊在程式碼中寫註解這件事。 因為這個經驗,我回去重翻史丹佛電腦科學教授 John Ousterhout 寫的《A Philosophy of Software Design》一書,並整理了筆記。該教授的觀點是認為程式碼寫註解有很多好23
[請益] coding style差太多怎辦?大家好 小弟上上份工作快離職前 聽到新進的同事說 他都習慣把程式寫成一個一個小的function 後來離職我花了一點時間學習設計模式24
重構的幾個迷思覺得最近很多文章都有些不求甚解的問題,來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼,重寫舊的程式碼成自己爽的樣子,不一定是重構。 3. 重構是一種相對安全的工具型開發方法論, 但仍然有不少風險跟誘惑。10
[問卦] 要怎摸知道自己對寫程式有沒有天分啊?As title 常常聽很多人說 寫程式就像畫畫一樣 要有天分 那麼問題就是要怎麼知道8
Re: [問卦] 迴圈是不是對新手不友善啊?迴圈本身很簡單啊 把1到N印出來,每一行一個數字 只要你可以寫出: for(int i=1;i<=N;i++) cout << i << endl; 好你會迴圈了6
Re: 不想唸碩士了,想去刷題想作一下補充,維護legacy code應該算是比較吃經驗跟工程技術: 1. 判別code smell 2. 了解原code的邏輯 (願意而且能夠讀懂別人的程式碼) 3. 還要能改得對 看這位大大應該是解題能力強、做大型專案的能力也強,把code寫對跟寫好對你X
[問卦] 愛台覺青工程師會拒絕抄中國的程式碼嗎剛剛看到有人爆掛才想到 真正愛台灣的覺青除了打高端之外 如果剛好身份又是工程師 那麼寫程式時 會刻意避開中國人寫的程式碼嗎?2
Re: [討論] 工作上寫單元測試的比例原則上要寫測試的話我會用很古老的 TDD 的方式做,先寫測試之後再寫實作。 現在的話則是寫完測試之後 Copilot 就幫我寫完一半了,然後就開始 review copilot 的 code 了。 目前經驗上能不能寫測試的話我認為有三個維度會是主要影響關鍵,提供參考: 1. 文件是否齊全