Figure 18-5. Configuring an F# project for debugging NUnit test fixtures in Visual Basic .NET

Printing Data Matrix ECC200 in Visual Basic .NET Figure 18-5. Configuring an F# project for debugging NUnit test fixtures

Note This section shows how you can use NUnit to define test cases using F#. However, NUnit isn t the only

tool for unit testing that s available for .NET. For example, Visual Studio includes powerful unit-testing tools.

Summary

This chapter introduced techniques and tools you can use to debug F# programs and automate the execution of unit tests. Because testing and debugging activities relate to the execution of programs, these tools tend to work on the compiled version of a program, relying on additional information such as metadata exposed through the reflection API or program debug database information files generated by compilers. Programming languages such as F# that feature programming abstractions don t map directly to the CLR intermediate language and type system; as a result, compilation details may surface when you use tools that operate on compiled assemblies. Nevertheless, these are valuable tools for developing large systems. The next chapter covers another set of software engineering issues for F# code: library design in the context of F# and .NET.

This book deals with F#, a language situated in the context of .NET-based software construction and engineering. As an expert F# programmer, you need more than knowledge of the F# language; you also need to use a range of software-engineering tools and methodologies wisely to build software that is truly valuable for the situation where it s deployed. The previous chapter touched on some important tools. This final chapter looks at some of the methodological issues related to F# library design: Designing vanilla .NET libraries that minimize the use of F#-specific constructs, according to existing .NET design conventions Elements of functional programming design methodology, which offers important and deep insights into programming but doesn t address several important aspects of the library or component design problems Specific suggestions for designing .NET and F# libraries, including naming conventions, how to design types and modules, and guidelines for using exceptions

F# is often seen as a functional language; but as this book emphasizes, it s really a multiparadigm language. The OO, functional, imperative, and language-manipulation paradigms are all well supported. That is, F# is a function-oriented language many of the defaults are set up to encourage functional programming, but programming in the other paradigms is effective and efficient, and a combination is often best of all. Nonetheless, a multiparadigm language brings challenges for library designs and coding conventions. It s a common misconception that the functional and OO programming methodologies compete; in fact, they re largely orthogonal. However, it s important to note that functional programming doesn t directly solve many of the practical and prosaic issues associated with library design for solutions to these problems, you must look elsewhere. In the context of .NET programming, this means turning first to the .NET Library Design Guidelines, published online by Microsoft and as a book by Addison-Wesley. In the official documents, the .NET library design is described in terms of conventions and guidelines for the use of the following constructs in public framework libraries: Assemblies, namespaces, and types (see s 6 and 7 in this book) Classes and objects, containing properties, methods, and events (see 6) Interfaces (in other words, object interface types; see 6) .NET delegate types (mentioned briefly in s 5 and 6) Enumerations (that is, enums from languages such as C#; mentioned briefly in 6)

Constants (that is, constant literals from languages such as C#) Type parameters (that is, generic parameters; see 5)

From the perspective of F# programming, you must also consider the following constructs: Discriminated union types and their tags (s 3 and 9) Record types and their fields ( 3) Type abbreviations ( 3) Values and functions declared using let and let rec ( 3) Modules ( 6) Named arguments ( 6) Optional arguments ( 6)

Framework library design is always nontrivial and often underestimated. F# framework and library design methodology is inevitably strongly rooted in the context of .NET OO programming. This chapter gives our opinions about how you can approach library design in the context of F# programming. These opinions are neither proscriptive nor official. More official guidelines may be developed by the F# team and community at some future point, although ultimately the final choices lie with F# programmers and software architects.

Note Some F# programmers choose to use library and coding conventions much more closely associated with

OCaml, Python, or a particular application domain such as hardware verification. For example, OCaml coding uses underscores in names extensively, a practice avoided by the .NET Framework guidelines but used in places by the F# library. Some also choose to adjust coding conventions to their personal or team tastes.