頁:
[1]
2
怎麼樣可以判斷程式寫得好不好?
尤其對本程式菜雞來說，寫腳本會能用就是幸運了不如繪圖那般可以看出大師或老手的差別
譬如說我一個程式只會用if或for來寫很多重複簡單的計算
是不是就很low ，還是有甚麼用了比較潮的招式之類的哈哈
大大可以解惑一下嗎? 感謝{:31:}<div></div> 程式的優劣大致上會從正確性、效率、可讀性、可維護性去判斷品質。
正確性不用說，會出錯的程式就沒用了。我們無法確保總是 bug free，至少在某一個 function 之中，已知的測試條件都要能正確執行。
接著還會希望這段程式碼的效率不要太差，有些寫法一看就知道效率不好。既然程式碼需要被閱讀，那麼可讀性就很重要：是否能夠清楚地知道這段程式碼在做些什麼事情。通常可讀性好的程式碼，維護的難度也會稍微低一點。為了更容易維護，經常也會給程式碼加上一些抽象層。但是，抽象層也常常帶來效率的流失，所以在效率跟維護之間要抓一個平衡。
只會用 if / for 來寫程式，代表的是你對語言、工具或是框架、架構的掌握程度不夠，很難寫出優秀的程式碼。如果以寫作來比喻寫程式，並不是堆砌華麗的詞彙就能寫出好文章，但是字彙量如果只有國小的程度，要把文章寫好的難度是高了一些。...<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div> 本帖最後由 kwj 於 2019-6-19 12:22 AM 編輯
先糾正一個觀念，程式碼沒有什麼「寫法潮不潮」的問題，只有「容不容易看懂」、「執行效率快不快」或者「容不容易擴充」的問題。而在還沒有很熟練以前，比起執行效率或靈活性，建議應該優先考慮可讀性。
如果很多 if 和 for 指的是用了很多層巢狀的 if 和 for 的程式碼，那毫無疑問是不好的程式碼，但問題不在於寫法本身潮不潮，而是在於這種寫法絕對很難看懂。
而要「看」出好的程式碼，其實只要先嘗試去看看別人寫的程式碼，然後很快就會知道什麼是「不好的程式碼」了。如果覺得自己太弱看不懂別人的程式碼，那麼另一種選擇是～自己把程式碼寫好以後，過一個月再回來看它，看看自己看得懂多少、要花多少時間看懂。雖然說並沒有確切的指標，不過基本上一段好的一兩百行的程式碼，兩三分鐘內應該要能大致看懂。...<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div> 一切都是講究經驗，程式語言通常都是以可讀性為優先，自己寫的程式，自己要看得懂之外，別人也要可以輕鬆駕馭，至於會不會出錯，程式裡面的bug通常都是在規劃時沒規劃好，或設計時，自己看錯，或誤會行為才會些bug....這些通常發生在比較複雜的專案上
我以前也跟你差不多，會if else、switch case、for、while.....用基本的判斷方式、迴圈、陣列..寫出一個專案
然後在公司用這些東西用了快半年...之後經過一個前輩的教導後才開始去翻一些手冊精進自己...
雖然說用基本的判斷方式也不是不好，但往往會讓程式碼變得很長一大串，導致去看的時候還要花上許多時間.....<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div> 我記得資料結構這個學習是可以判斷程式效率的，像用 if或單純使用變數，都有一個指標可以告訴我們效率好不好，找找看吧！<br><br><br><br><br><div></div> 如果要學習讓程式寫得好一些… 是可以往 設計模式 與 程式重構 的方面去找資料來看。
不過呢，初期還是以程式能「作對事情」最為要緊，
若程式作的事和預期的不一樣，再漂亮的程式碼也只是垃圾。
以從事程式相關工作的經驗來說，有些時候無關乎「要不要寫漂亮的程式」，
而是不得不對現實低頭，面對那些欠了許多技術債，或背了許多歷史包衭的程式碼…
能看懂它們是在作些什麼… 就要花上不少力氣了，再來還要把它們改成需要的功能…
如果最後還有留下一絲力氣的話，再去思考所謂漂亮的程式吧！
改的時候就用"漂亮"的方式來寫？
別鬧了！那只會讓你在幾個星期後，在兩種(或更多)天差地遠的寫法中，更看不懂它們是在作什麼的。
大多數的人，是會忘記幾星期前就沒有接觸(維護)的程式。(通常是更短)
所以… 所謂漂亮的程式，其實就是「在幾星期後，能輕易看懂是在作啥的程式碼」…...<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div> 本帖最後由 kentcat3030 於 2019-7-17 01:14 PM 編輯
判斷程式寫得好不好，很難定義．
現階段，我覺得，沒有任何人敢說自己寫出來的程式是完美的．
商用程式，就必須符合客戶需求，一切也如上面各位先進所言．
先符合需求，在慢慢改善其他，如效率、相容性....等等．
高手，尚無法寫出客戶需求，因為考慮仔細，還會考慮到將來的擴充性等等．．．
新手，用簡單的思考，繁瑣多餘的語法，目前，立即可達到客戶需求．
這時，誰寫的好？(客戶來評估的話)．
只要自己寫出來的，讓自己滿意，就是好！
自然而然，自己就會想要精進，改進，深入.....
上面各位先進有提到可讀性、維護性等問題．
我會建議，各個運作區塊前，Rem一段區塊解說．
至於條件，迴路等混和在一起的．
在每個條件後面，迴路後面，加上Rem甚麼語法的終點
例如：
// 判斷ＸＸＸＸ
if A>...<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div> 以個人觀點來說, 我昨天玩傳說, 有人罵我笨, 但是我覺得不差啊
以產品觀點來說, 我被人罵笨, 如果不爽擺爛, 那大家一起輸, 一起配合,取得默契, 那贏得機會較高
以個人觀點來說, 不用在乎好壞, 通常這個時候, 很多人會說, 多看別人的code
以產品觀點來說, 看一下資深寫的模組或者class ,你可以一邊引用,一邊看別人是怎麼寫的
個人覺得先模仿,然後再創新,剛開始學先複製別人的程式,學著修改,然後整合,最後熟練後才學著簡化,畢竟程式也是一種語言,用來溝通用的.{:36:} 不用太在意這個吧! 程式只要功能性達到就好 其次才是效能 最後才是寫法 用了一些少用的funcation 去呈現code 反而讓後面的人維護困難<br><br><br><br><br><div></div> 每一個人對好的定義都不同,我對好的定義是其他人能不能看明白你的代碼, 然後在去tune效能 我覺得要看你著重什麼吧!
軟體我覺得就 穩定性/可讀性/佔用記憶體多寡
個人認為只要用的技巧很高，都不會具有什麼可讀性，穩定性有待商確...
就好像我主管寫程式很強，但是程式內Bug一堆，後面的人要解Bug看不懂也很難解...
簡單像是if /while/for/try .... 簡單的應用，但強在穩定性很高...
像是車用一些，是有限定語法，還有強制的規範，所以好不好，重點是在於你要寫的是什麼東西/用在那! 如果你寫了一個只有你自己看的懂自己能編，最後也只有自己能用，算的上好嗎?
我覺得現在已經是Team work的時代，寫只有自己能編的，唯一的好處就是留任度會高些...
但也要看是做什麼，如果工作沒有舉足輕重，那也是白搭......<div class='locked'><em>瀏覽完整內容，請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div> 先追求明確的邏輯吧
用自己的邏輯思維去寫就行了
程式邏輯寫的清楚
bug就少
不用追求可讀性
寫給同事看的介面才需要可讀性
內部實作你自己看的懂就夠了 問題是就算
// 判斷ＸＸＸＸ
if A>B then
.....
while
也會有人寫成
// check if A > B
重點是邏輯的判斷跟為什麼要做這個判斷
程式寫得好 有很多標準觀點
但是code comment 寫得好或是不好倒是一目了然 寫程式都是循序漸進的。
你要先知道怎麼寫，例如有哪些可以用的function
再來就是使用這些函數寫出符合功能可以運作的程式
最後才是進行程式的優化。
沒有人一開始就很會寫程式，一定是累積經驗後知道該怎麼寫才會有效率的。<br><br><br><br><br><div></div>
頁:
[1]
2