2013-07-10 27 views
0

當編寫一個程序,我理解作爲一個業餘愛好者程序員,有三種方式來完成大部分的事情:循環對戰功能與對象/類的正確選擇

  • 創建循環
  • 創建和使用功能
  • 創建和使用對象

我使用javascript這裏問我的問題,因爲我學習了它大約2-3周前。與我以前在Python中使用Python或MatLab相比,這有點奇怪,但這不是重點。我經常想在三個特定的應用程序中應該是什麼好的選擇,所以我想知道你的建議。

我想創建一個數組列表以供後續繪圖使用。該程序應該採取公式的係數,增量步長和x值的邊界。下面是代碼(很抱歉,如果我錯過了改變,以適應所以,當下面的東西,但它工作之前某些時刻!):

function array_creator(input_coeff,inc, boundary){ 
var bound=boundary||[0,1]; 
var eqn_deg=input_coeff.length-1; 
var increment=inc; 
var x_init=bound[0]; 
var y_val=0; 
var graph_array=[]; 
while (x_init<=bound[1]){ 
    for(var i=0;i<input_coeff.length;i++){ 
     y_val=y_val+input_coeff[i]*Math.pow(x_init,eqn_deg); 
     eqn_deg--; 
      } 

    new_arr=[x_init,y_val]; 
    eqn_deg=input_coeff.length-1; 
    y_val=0; 
    graph_array.push(new_arr); 
    x_init=x_init+increment; 
    } 
return graph_array; 
} 

在上面的代碼中,我有一個嵌套循環肚裏了一段時間,但我裏面我習慣於編寫嵌套的代碼超過3-4層,一週後我無法挖掘自己的程序。所以我的問題是,我何時應該知道是時候實施單獨的功能而不是嵌套或知道創建對象的時間了。在清晰度和效率方面將一個大的循環函數分成幾個函數有哪些收益和損失?在什麼時候創建對象變得至關重要,或者只是當我不得不再次使用相同的代碼時。

當你擁有的唯一工具是錘子時,一切看起來都像釘子。當我在MatLab之後開始學習python時,OO方法給我留下了深刻印象,我曾經在任何情況下創建類,無論是否需要。我想很多新手都會很高興在這個編程基礎上找到一些系統的方法。

+0

因此,這個問題即將結束,它是基於意見的論點..從...好的編程實踐的知識何時開始基於意見? –

+1

版主可能會認爲你的問題對於StackOverflow太廣泛。預計人們會問一些已經包含解決問題的實際問題。也許你可以考慮修改你的問題? – Nobilis

+1

@Jack_of_All_Trades「良好的編程習慣」是觀點,有些人對它們持不同意見。 StackOverflow通常用於答案不是意見的問題;它可以工作並滿足提問者的要求,或者不符合提問者的要求。像「這個代碼的哪個版本看起來更好?」或者「我應該做** x **以使其更具可讀性嗎?」正在徵求意見。然而,這並不是說你的問題不是很好的問題,只是StackOverflow可能不適合它。 –

回答

1

就個人而言,就循環而言,我有三個硬切斷。如果我打過三個嵌套循環(不包括if/else條件或try/catch條件),那麼我知道是時候把它分解成單獨的函數。

就權衡而言,只要您正在運行的函數連續運行多次(如循環的較低層),應該不會有任何性能損失。進行函數調用總是有一點點開銷,但幸運的是,計算機真的很聰明,他們有這些東西調用temporal caches,其中緩存區域爲極其快速內存(讀取:SRAM)。這將識別並將您的函數調用加載到緩存中。由於訪問緩存中已有的東西實際上是免費的(讀取時間爲幾ns),因此您不會爲這些額外的函數調用支付任何性能損失。

類的用法是非常依賴語言。在JavaScript中,一切都已經是一個對象,所以你真的不應該擔心在類中包裝函數,儘管也會有一點點的開銷。然而,對於像Java這樣的語言,你應該努力做大量的小班。 JVM針對多個類之間的通信進行了極其優化,JIT編譯器不應該加載類中涉及的任何額外「goo」,除非您真的需要它。

總的來說,表現並不是你應該根據自己的決定做出的大部分決定(表現是80/20,而你通常需要的是不做任何公開愚蠢行爲的80。)你應該真的嘗試遵循一種模式,使你的代碼對其他開發者來說盡可能的可讀。由於這個問題上有許多難民營,因此很難界定一條硬性規定。一般來說,對於一個開始的程序員來說,我的建議是查看大量的代碼並試着瞭解發生了什麼。如果可以的話,嘗試用更易讀的格式重寫部分代碼。 Github上有足夠的開源代碼,它應該很容易做到。

好的編程實踐一直都是意見,這只是人們有時非常同意。