調試F＃代碼和功能的風格

我是新來funcctional編程和有關於編碼風格和調試的一些問題。調試F＃代碼和功能的風格

我的印象是一個應該避免存儲在一個臨時變量從funcction調用的結果，然後返回該變量

例如

let someFunc foo = 
    let result = match foo with 
       | x -> ... 
       | y -> ... 
    result

，而是做這樣的（我可能是遙遠？）：

let someFunc foo = 
    match foo with 
    | x -> ... 
    | y -> ...

從一個角度functionallity工作正常，但它使得它的方式難以調試。我也沒有辦法檢查的結果，如果右手側 - >做一些時髦的東西。

所以我應該怎麼處理這樣的情景？

來源

2010-04-23 Roger Johansson

無論哪種方式是可以接受的，因爲你只是結合當地不可改變變量。

雖然有一個問題。如果將它用作使用尾調用的遞歸循環的一部分，則使用temp變量的變量將消除尾調用，因此將會增加堆棧空間。

來源

2010-04-23 07:50:45 leppie

謝謝，不知道它打破了尾遞歸。我想我需要擺脫那些結果變量然後。我現在在用c語法LISP來玩耍; http://rogeralsing.com/2010/04/17/more-on-plastic/ 它會毆打IronScheme ;-) – 2010-04-23 07:56:46

我不會拍你，如果你使用的臨時的，但我也不會抽筋的，我需要看在調試一些關閉的機會，我的風格。

此外，調試這樣的事情是與Visual Studio 2010的可視化調試器更容易，因爲你可以使用每個可能的匹配表達式中斷點。還有快速手錶和其他強大的功能。

對於在Visual Studio調試器的最新功能列表： http://msdn.microsoft.com/en-us/library/01xdt7cs.aspx

來源

2010-04-23 07:46:31

能夠看到在VS的函數的返回值是一個長期的請求。其他中間表達式值也是;在F＃中，例如，你經常想要檢查管道的中間部分，這很難做到。從功能性編程意味着「更少的命名變量和本地化」和「更大的表達式」的意義上講，這對當前的調試器產生了負面影響。（在另一方面，之類的東西少的可變性和更高的抽象，希望你少花時間在調試器。）

還有很多方面對未來的調試器可以改善...

見也

Do some Functional programming constructs reduce Debuggability?

來源

2010-04-23 16:14:33 Brian

要檢查管道的中間，我建議採取以下解決辦法：

將這個代碼在一些地方：

[<AutoOpen>] 
module AutoOpenModule 

#if DEBUG 
let (|>) value func = 
    let result = func value 
    result 
#endif

啓用「託管代碼中單步執行屬性和操作符」：

https://msdn.microsoft.com/en-us/library/cc667388(v=vs.100).aspx

現在，你應該能夠步入管道運營商。

來源

2011-02-11 08:18:44

完全輝煌。現在這是我們的代碼庫的一個珍貴的補充。 – Kit 2012-09-13 12:31:15

調試F＃代碼和功能的風格

回答

相關問題