創建過於簡單的功能是不好的風格嗎？

我只是想知道 - 創建函數（分解）爲相對簡單的任務是不好的編程風格？創建過於簡單的功能是不好的風格嗎？

例如，在PHP中，我覺得有'$ _'，然後是會話，發佈，獲取和cookie的大寫字母很煩人。所以如果我做了一個名爲setSesVar（'key'，'value'）的函數來爲我創建一個會話變量，那是不是很糟糕？每次爲它調用一個函數的開銷是多少？或者它是不相關/自己的偏好？

一些其他示例：在C

的println功能++（和Java）
getElementBydId在Javascript中的簡寫形式（假設我不使用jQuery或另一庫）
重定向代替PHP中的標題（'Location：'。url）

而且有點偏離主題的問題 - 我用的語言有更多的'strict'數組;在PHP中，你可以添加一個元素到最後購買只是說myArray [] ='newElement'。我覺得我應該做myArray [sizeof（myArray）]，但是我敢打賭，添加令人難以置信的代碼可能是不好的風格。

來源

2012-04-07 Raekye

很主觀。這應該可能是一個社區wiki。 – 2012-04-07 03:34:42

取決於功能的作用，以及你做了多少事情。如果你把所有東西都拿出來並且做出一個單行功能，那麼你還沒有真正擺脫任何複雜性。事實上，你已經添加的複雜性，有兩種方式：

首先，任何不是內置到PHP是什麼人新的代碼必須弄清楚。如果我看到$_SESSION['stuff'] = "some value";，我知道它在做什麼 - 就像任何人花了超過一個小時的PHP。另一方面，如果我看到setSessionVar('stuff', 'some value');，我必須去確定setSessionVar的功能。我的意思是，它必須做不僅僅是設置$_SESSION;否則，爲什麼不只是做那？
其次，如果這些函數最終會相互調用，最終會出現一個函數調用的老鼠巢。遵循10-（甚至30-）線函數比跟蹤2線函數更容易，該函數調用另一個2線函數，該函數調用另外2線函數，可能會或可能不會調用另一個2線函數線功能。您必須通過文件（或更糟的是，在一堆不同文件之間的選項卡）通過yoyo來追蹤您的代碼。

在我看來，PHP內置的任何東西都可以用一行簡單的代碼表達出來 - 並不具備它自己的功能。我建議限制函數至少3行，但有一個例外：需要訪問對象內部的方法，例如getters或setter，可以更小。但是大多數函數都應該做一些PHP並不平凡的事情;如果他們不這樣做，那麼你就無法正確理解函數的目的，增加複雜性。

來源

2012-04-07 05:03:33 cHao

只有當你的名字不夠詳細時 - 如果它們太短，你會無意中混淆你的代碼以供將來的維護者使用。另一方面，如果它們足夠冗長，一半的時間會更快地使用原始代碼。如果你使用過短的函數名稱來避免「額外」輸入，我認爲分解只是一個壞主意。

來源

2012-04-07 03:35:56

我想這取決於。你會把這些功能放在哪裏？最主要的是，如果你要在每個班級複製這些內容，那麼這可能是一個壞主意。如果你把他們在某些utils的類，然後目的很可能被擊敗反正：

System.out.println(" ... "); VS MyUtils.println(" ... ");

真的沒有多大意義。（與其他人一樣）

來源

2012-04-07 03:37:24 user12345613

好點。我不經常使用C++，所以我經常在實際文件中包含一個函數（調試我在衝動中做的別緻事情）。如果我有一個'核心'的源文件，我可以有一個函數'getById（id）{return document.getElementById（id）;};}}}}}}}}}} }' 或PHP：'function sessionCookie（$ key，$ value）{if（$ value！= null）{return $ _SESSION [$ key]; } else {$ _SESSION ['key'] ='value'; }}'（我知道這可能不完美） – Raekye 2012-04-07 03:44:52

我覺得它只是一個更清潔的同事打開一個文件，並看到$ value = $ _SESSION ['key']'而不是$ value = sessionCookie（ $ key）'並且必須找到你的核心文件，看看sessionCookie在做什麼 – user12345613 2012-04-07 03:49:12

函數重定向（$ url）{header（'Location：'。$ url）; }？只是問，因爲我覺得有很多小水平...對不起，如果它似乎如此微不足道哈哈 – Raekye 2012-04-07 03:55:00

創建過於簡單的功能是不好的風格嗎？

回答

相關問題