调试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＃代码和功能的风格

回答

相关问题