 | Buy your movie tickets online. Find reviews, trailers, and more at Fandango. From our sponsors |
| ?????? Soft_Job ? |
| // via fulltextrssfeed.com |
Re: [討論] 因為空格~我離開了一間公司
9/14/2014 7:49:45 AM
※ 引述《guest2008 (guest)》之銘言： : ※ 引述《changyuheng (張昱珩)》之銘言： : : 我所知的語言，function 的 return 值可以滿足 condition 就不會再做多餘的比較。 : : 例如 : : if (funcA()) : : 不會寫成 : : if (funcA() == true) : : 請問這樣寫有什麼特殊原因嗎？ : : return 應該是 statement，所以後面接的括弧是給 expression 用的。 : : 但是 (true) 不就是 true 嗎？ : 上面兩種寫法對編譯器來說它都可以吃，沒問題。 : 為什麼這樣寫？ 沒什麼： : 一開始大家寫程式都一定是模仿書上的範例，全部的範例都這樣寫， : 寫習慣也沒特別去注意(所以真的就是純習慣性問題而已，這才是真正的真相)， : 直到....。 : 程式寫多了，被很多莫名其妙你覺得不會錯的 bug 搞死， : 除非你就是太單純真的只會寫一種程式語言，不會又要你寫 : C/C++、PHP、JAVA、jquery......哩哩拉拉一大堆語言。 : 把敘述寫完整一點對你寫程式來說，真的花不了你幾豪秒鐘的， : 但可以避免很多不必要的困擾。 : 例如 if( A || B ) ..... 跟寫 if( (A) || (B) )... : 根本意思完全相同，但要是 A 是 複合詞，例如他是 2014 && 0xFF : 你沒加括弧就會出現恐怖的錯誤，而且這個錯誤你的編譯器永遠也檢查不出來。 : 習慣性加 ()，不管他多簡單都習慣加括弧，就可以減免你未來 debug 時間， : 就這麼簡單而已，你要用你的寫法沒人說不行。 : 還有 if( funA() ) 寫 if( funA()==true) 通通都可以，但你的程式碼 : 交給後面維護的人，用後面的寫法，他可以只看這一行就夠了， : 不需要回去看你的 funA() 到底是什麼碗糕，是返回 float 還是 bool 還是參照。 : 反正寫習慣了，也沒特別去注意，但真的避開了很多麻煩， : 你要用你的寫法沒人說不可以，只要小心未來不要採到很深的隱藏地雷就好。 : 因為這些都會認為絕對不會錯，編譯器也絕對檢查不出來你真的要表達的意思， : 他一定會 pass，但最後你會被搞死，尤其你要寫很多種程式語言，各種程式語言 : 又有一點點小小小小差異時，寫完整一點根本就不會錯。 : 我舉兩個案例，你自己去思考 : 案例一： : 1.1 return(1); : return(99); ==> if( funA() == true) : if( funA() == 1 ) : 1.2 return(true); ==> if( funA() == true ) : if( funA() == 1 ) : 案例二： : #define A (32+64) : #define B (32+64); : return A+1000; : return B+1000; : return (A+1000); : retrun (B+1000); : 以上四個結果你自己去跑一下，當然案例二我真的是純搞笑， : 但不要你周遭的人還真的發生過這樣的事件..那我就無言了。 : 你就知道括弧的差異了。 這就看你的語言了，C 語言的 if statement 後面是接 boolean condition， function 的 return value 若不是 boolean 本就不該放在這邊， 就算有很多人這樣放，也都是在確信能夠正確 branch 的情況下做的偷懶。 還有，什麼才是 true? 雖然 C99 用 macro 定義了 TRUE = 1， 但是 boolean condition 判斷的仍是 0 或非 0。 funcA() == TRUE 這樣的寫法變成是判斷 funcA() 回傳的是 1 或非 1， 是會讓人困惑的，因為你用了 TRUE，這和一般的 true/false boolean condition 不同。 比較好的寫法是 funcA() == 1。 -- http://changyuheng.github.io/ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.141.116.107 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1410696990.A.AE9.html
→ guest2008: 其實你不要去當認真狂人..純拿來舉例的東西讓人能理解 09/14 20:38
→ guest2008: 要表達的事而已..結果在雞毛堆裡求真理. 09/14 20:42
→ guest2008: 兩個案例都是故意找有爭執的案例..這是蓄意的 09/14 20:45
→ guest2008: 只是要表達多打幾個字元會避免不必要的麻煩而已 09/14 20:46
Re: [討論] 因為空格~我離開了一間公司
9/14/2014 7:49:45 AM
※ 引述《guest2008 (guest)》之銘言： : ※ 引述《changyuheng (張昱珩)》之銘言： : : 我所知的語言，function 的 return 值可以滿足 condition 就不會再做多餘的比較。 : : 例如 : : if (funcA()) : : 不會寫成 : : if (funcA() == true) : : 請問這樣寫有什麼特殊原因嗎？ : : return 應該是 statement，所以後面接的括弧是給 expression 用的。 : : 但是 (true) 不就是 true 嗎？ : 上面兩種寫法對編譯器來說它都可以吃，沒問題。 : 為什麼這樣寫？ 沒什麼： : 一開始大家寫程式都一定是模仿書上的範例，全部的範例都這樣寫， : 寫習慣也沒特別去注意(所以真的就是純習慣性問題而已，這才是真正的真相)， : 直到....。 小小的補充一下, 可能也有錯誤看看就好. 推測是因為利用Boolean代數特性, 如C語言有提供: 1. Logical AND (&& operator) 2. Bitwise AND (& operator) 利用的功能就是 Logical AND 所以在compiler處理後能視為: if(funcA()&&0x01) => 回傳值透過Logical AND設定旗標讓if進行判斷 if((funcA()==true)&&0x01) => 同上功能, 多卡一條必定要等於true內容 實際處理方式需要檢查Compiler組譯出來的結果, 因Compiler品牌也會不同. 感覺像照Intel處理方式回傳值或處理資訊的值都會放在rax暫存器, 就加一段Logical AND判斷使這種縮寫語法也能通用. 更新入的話能從語言規格官方公開文件尋找如何處理此行為, 或是檢查系統指令集處理條件時行為是否能容忍此種操作. 建議能看以下課程來取得更詳細的解釋: https://www.coursera.org/course/hwswinterface Section 1: Boolean Algebra Section 4: Conditionals and Control Flow Many Thanks, watz0n -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.227.117.10 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1410696718.A.E1D.html
Re: [討論] 因為空格~我離開了一間公司
9/14/2014 7:49:45 AM
※ 引述《changyuheng (張昱珩)》之銘言： : 我所知的語言，function 的 return 值可以滿足 condition 就不會再做多餘的比較。 : 例如 : if (funcA()) : 不會寫成 : if (funcA() == true) : 請問這樣寫有什麼特殊原因嗎？ : : return 應該是 statement，所以後面接的括弧是給 expression 用的。 : 但是 (true) 不就是 true 嗎？ 上面兩種寫法對編譯器來說它都可以吃，沒問題。 為什麼這樣寫？ 沒什麼： 一開始大家寫程式都一定是模仿書上的範例，全部的範例都這樣寫， 寫習慣也沒特別去注意(所以真的就是純習慣性問題而已，這才是真正的真相)， 直到....。 程式寫多了，被很多莫名其妙你覺得不會錯的 bug 搞死， 除非你就是太單純真的只會寫一種程式語言，不會又要你寫 C/C++、PHP、JAVA、jquery......哩哩拉拉一大堆語言。 把敘述寫完整一點對你寫程式來說，真的花不了你幾豪秒鐘的， 但可以避免很多不必要的困擾。 例如 if( A || B ) ..... 跟寫 if( (A) || (B) )... 根本意思完全相同，但要是 A 是 複合詞，例如他是 2014 && 0xFF 你沒加括弧就會出現恐怖的錯誤，而且這個錯誤你的編譯器永遠也檢查不出來。 習慣性加 ()，不管他多簡單都習慣加括弧，就可以減免你未來 debug 時間， 就這麼簡單而已，你要用你的寫法沒人說不行。 還有 if( funA() ) 寫 if( funA()==true) 通通都可以，但你的程式碼 交給後面維護的人，用後面的寫法，他可以只看這一行就夠了， 不需要回去看你的 funA() 到底是什麼碗糕，是返回 float 還是 bool 還是參照。 反正寫習慣了，也沒特別去注意，但真的避開了很多麻煩， 你要用你的寫法沒人說不可以，只要小心未來不要採到很深的隱藏地雷就好。 因為這些都會認為絕對不會錯，編譯器也絕對檢查不出來你真的要表達的意思， 他一定會 pass，但最後你會被搞死，尤其你要寫很多種程式語言，各種程式語言 又有一點點小小小小差異時，寫完整一點根本就不會錯。 我舉兩個案例，你自己去思考 案例一： 1.1 return(1); return(99); ==> if( funA() == true) if( funA() == 1 ) 1.2 return(true); ==> if( funA() == true ) if( funA() == 1 ) 案例二： #define A (32+64) #define B (32+64); return A+1000; return B+1000; return (A+1000); retrun (B+1000); 以上四個結果你自己去跑一下，當然案例二我真的是純搞笑， 但不要你周遭的人還真的發生過這樣的事件..那我就無言了。 你就知道括弧的差異了。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.46.33.32 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1410694240.A.C06.html
Re: [請益] 資工出路困惑
9/14/2014 7:49:45 AM
每個世代對於程式需求都不一樣， 最近一二年各大金融傳產開始導入新web based的系統， 所以專案需求比較多。 對於參考N系列文的： 如果工作年資超過10年且年齡超過30歲的分享， 其實你都不用考慮太多， 因為那已經是上一個世代， 而且已經把位子都卡好了。 你所需注意的是程式工作是你的最終，還是過渡。 如果就你文中需要高薪，那絕對不會是最終。 你一定要為管理"人"這個部分做準備。 一天24hrs寫程式隨時都可以寫， 但工作是那精神最好的8hrs所做的事。 會拿高薪做主管位子的往往不會是程式寫最好的人， 而是講話具說服力，懂得整合各方資源完成目標的人。 目前你才大四，還有研究所兩年生活要過。 現階段你應該要決定自己的研究領域， 找合適的教授當指導老師。 此刻就在板上問卦我覺得還太早， 而且逢甲或東海水準也不差啊， 應該不至於無法獨立思考的程度。 加油。 ※ 引述《coilion9670 (runrunder)》之銘言： : 各位前輩大家好 : 小弟我現在還是大四資工的學生 : 就讀台中一間前陣子社會版很常出現 : 現在食安問題也莫名很常出現的私立學校 Q.Q : 文章有點長,滿多是心情的宣洩請見諒 : -------------------------前情提要結束--------------------------- : 前幾篇N系列文看到高薪的前輩好像都不是在這領域的... : 以我現在學生的姿態來說 : 如果學習其他領域未來可以高薪,我會放棄我現在拿手的 : 去學習新的東西挖掘新的點讓自己沉迷 : 畢竟還是學生,顧名思義有本錢一直學習再學習 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.135.203.156 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1410690962.A.1B4.html
Re: [討論] 因為空格~我離開了一間公司
9/14/2014 7:49:45 AM
借討論串請教： ※ 引述《guest2008 (guest)》之銘言： : 這個我看起來 A 跟 B 根本沒什麼不同，但 B 確實比較糟糕。 : 因為都是 X條件觸發，處理 X條件，再繼續往下做。 : 但你是 X不成立，就返回。這個 !X 不是好方法，實際上對系統架構沒幫助。 : 你要讓系統結構很維護，避免那麼多{}層出現， : 框到到底那個 } 是對應那個 { 都不知道了，應該這樣寫: : if( : fun_A() == true : && fun_B == true : && fun_C == true : && ....... : ) : { : 做某件事 : } 我所知的語言，function 的 return 值可以滿足 condition 就不會再做多餘的比較。 例如 if (funcA()) 不會寫成 if (funcA() == true) 請問這樣寫有什麼特殊原因嗎？ : function fun_A() : { : if(....) return(false); : return(true); : } return 應該是 statement，所以後面接的括弧是給 expression 用的。 但是 (true) 不就是 true 嗎？ : 下略，自己補上 fun_B()..fun_C()。 : 這樣寫有啥好處？？ : (1) 最大好處就是太多層後，真的不知道那個 } 是對應那個 { : 也就是你一直在數空格數到底空對了嗎？ : (2) 除錯超快，注意我是直接每個判別直接寫一行， : 你寫的落落長後，除非你是天下奇杷，腦袋超清楚， : 要不然肯定會錯啦~~這個地方我除錯的速度絕對比你快。 : 我直接一行一行 // && fun_C() == true : 就找出問題了。 : 甚至未來你某個條件不想再用就像上面一樣 mark 掉就好了。 : 以上給參考，你自己去評估三種寫法哪種最好。 : 另外如果有人又要出來跟我戰他要用 class 寫法最好， : 還是說這個寫法糟透了，那是他家的事，我不出來應戰。 : 我只是恰好路過，出來建議一下而已。 -- http://changyuheng.github.io/ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.141.116.107 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1410687579.A.012.html ※ 編輯: changyuheng (220.141.116.107), 09/14/2014 17:47:01
Re: [請益] 資工出路困惑
9/14/2014 7:49:45 AM
※ 引述《DrTech (竹科管理處網軍研發人員)》之銘言： : 這些都是國外幫你寫好好的 "開發工具"，不太需要很難的知識， : 依照規定做事，看文件與範例程式，熟能生巧就會，只是快與慢的差別而已。 : 到最後，台灣所有在寫軟體的人，有九成九的工作都是在學 API怎麼用而已。 : 老鳥與新手的差別，就是多做幾年，可能做系統比較順與快一點而已。 : 你覺得這種工作的薪資會高到哪? : 少學這些"開發工具"，多去學數學、演算法、統計等基礎科目， : 再來就是各種演算法與數學的應用，如機器學習、 : 影像處理、數值預測、使用者需求預測等等，你才有機會喊薪水阿。 這些是所謂的領域知識，當選擇好某領域後就是下去鑽 但我覺得更重要其實是軟體工程的知識 懂不懂各種軟體架構優缺點還有何時該使用 大型專案中各種code寫下去，三年五年後可能的影響是什麼 Agile跟DevOps熟不熟悉，TDD有沒有用過 一堆寫很多年的工程師，但以上全都不行，那就是用同樣方法做很多年的事而已 基本上大概就是工作兩三年，把某一兩個程式語言熟練以後就沒再進步了 程式語言要熟練不需要太久，特別是已經熟練過某一兩種的人 但只有熟練程式語言，那就真的沒有什麼特別可以要求高薪的地方 我的話選擇人基本上不太在乎是否熟練我們要用的程式語言或是領域知識 這些都能學，而且花不了太久 主要還是要看他是否是一個好的programmer，以上各種軟工的東西是否至少有認識 因為這些真的不容易學，大都需要實務經驗 光看書只能說一堆理論，遇到情境題當場就掛了 而且這些東西如果不是有努力不懈學習的人，通常不太會去學 反正只要程式語言熟，這些不會照樣可以混，而且可能也混得不差 所以能熟這些的，通常也代表主動學習能力強 這通常是最重要的工作績效指標 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.229.164.132 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1410681877.A.AC9.html
→ saladim: Agile/DevOps..等等方法論太多了 也太多數年後又有神人 09/14 16:52
→ saladim: 寫篇文章說XX已死..還是把握精神跟基礎比較好... 09/14 16:53
→ saladim: 同樣會很多方法論的 裡面好手跟濫code都有分佈 其實也就 09/14 16:54
→ saladim: 看人有沒有下去磨 而不是套方法就出來戰..變成宗教信仰了 09/14 16:55
推 GoalBased: 會有敏捷 版控 測試都懂得人 不熟悉程式與言的嗎= =? 09/14 17:04
→ GoalBased: 你說你不在乎語言 因為你要求的根本就在語言之上的 09/14 17:05
→ GoalBased: 東西阿.. 09/14 17:05
You are receiving this email because you subscribed to this feed at feedmyinbox.com
If you no longer wish to receive these emails, you can unsubscribe from this feed, or manage all your subscriptions
訂閱：
張貼留言 (Atom)
沒有留言:
張貼留言