在javascript中使函數變小會更好嗎？

最近，我讀了一本書（CleanCode）在javascript中使函數變小會更好嗎？

本書

，

函數應該做的一件事。他們應該做得很好。他們應該只做它。

功能應該很小。

但我認爲在JavaScript中的功能。

如果我將大的函數分割成小的東西，代碼會變得更長，並且需要更多的時間來渲染。

即使在javascript中使函數變得更小也更好嗎？

您有什麼看法

來源

2010-03-16 Sungguk Lim

對不起我可憐的英語 – 2010-03-16 01:47:46

需要多少時間才能渲染？ – Ken 2010-03-16 02:03:07

微觀優化不值得。可維護性更重要。要將代碼實際提供給瀏覽器，您可以使用JavaScript minifier。

來源

2010-03-16 01:49:21

謝謝！馬修！ – 2010-03-16 02:05:53

一般來說，你應該總是讓你的小功能，簡潔。性能方面的原因不會太多，這可以忽略不計，但是要保證代碼的清潔性，可讀性和可維護性。

來源

2010-03-16 01:48:44

也許你不應該跑來繞過對其他人的表現要求做出無知的假設......如果是3歲的黑莓呢？ – 2010-03-16 01:51:14

是的，但「一般」這不是性能瓶頸。我只是想幫助，男人... – 2010-03-16 01:59:50

除非你正在編寫一個非常重要的部分，通常「容易維護」（這意味着在你的情況下的小函數）是更重要的代碼大小。

你應該總是先寫小函數，然後優化（通過合併或重寫）那些你認爲太慢的東西。

來源

2010-03-16 01:52:41 Francis

最好是優化你知道**的功能太慢分析。 – 2010-03-16 04:27:15

這本書是完全正確的。

功能應儘可能簡單。這應該是一種習慣。也許對於一個非常簡單的網頁，您不會注意到任何區別，但是隨着您開發越來越複雜的系統，您會發現通過簡化功能可以避免一堆不必要的錯誤。

使用單獨的函數來查找問題要容易得多，每個函數都執行一個簡單易測的任務。作爲獎勵，您會發現重複使用部分代碼並防止重複會更容易。每一項功能只應編碼一次，否則當你需要改變某些東西的計算方式時，例如，你必須通過你的代碼來尋找所有需要改變的地方。

與您的代碼的附加可維護性相比，渲染時間（或更確切地說，下載時間）的差異是微不足道的。

來源

2010-03-16 01:54:37

謝謝你的具體回答很好 – 2010-03-16 02:07:39

該行在Javascript中模糊了一下，因爲functions兼作類，對象，構造函數和閉包。你的最外層函數可能是巨大的，但僅僅是因爲它命名空間的其他大功能作爲對象/構造函數，其中包含更多的包含閉包的回調。

儘管如此，在任何情況下和任何語言中，函數（包含函數自身包含的代碼塊）應該儘可能地精益的規則也是如此。

來源

2010-03-16 02:08:31 deceze

如果我大功能拆分小東西，...

這並不是說「做小事」，它說：「只做一件事」和「小功能」。

這並不意味着單行者，要做好'一件好事'，它很容易成爲10-50行，仍然是簡潔和'一件事'。

來源

2010-03-16 02:12:43 Javier

+1「小」！==「短」 – deceze 2010-03-16 02:14:32

我不相信口頭禪「功能應該很小，只做一件事和一件事」。在程序語言編程的時代，我認爲這是真實的，而這正是很多被誇大的OO轉型者陷入困境的原因。爲什麼？因爲在這些語言中，您不能使用內嵌函數或匿名函數。這些早期過程語言的可讀性途徑簡而言之是功能完善的功能，因爲這樣您可以使代碼更具語義。在那些日子裏，代碼通常更短，支持的庫和組件也更少。構建 - 調試周期的迭代時間爲幾分鐘 - 今天，我認爲很多人會發現這是不可接受的。

如今，可維護性的主要敵人是無法破譯程序的流程。如果你不知道什麼或者代碼在哪裏，或者它來自哪裏，或者你應該打電話給那個東西的名字是 - 你在短時間內在你的手上有一個噩夢。有（1）一個簡單的，無污染的名稱空間易於想想和（2）有一段代碼非常接近其他代碼它影響將會讓你在可維護性方面比「lot小型單一功能「的東西。

來源

2010-03-16 02:15:00 Plynx

在javascript中使函數變小會更好嗎？

回答

相關問題