Geeks With Blogs
Mark Pearl


Daniel Mohl put up a great slide presentation on the 5 best practices for F#. Since I am new to the language I thought I would go through each practice and explore it a bit as separate posts.

Best Practice 1 – Prefer Short Functions with only one primary responsibility

As Daniel points out, functions that follow this practice enable

  • single responsibility pattern (SRP).
  • function composition

I must admit that up to this point, I have never really looked formally at what the SRP or Function Composition is. So today I am!


The Single Responsibility Pattern is a design pattern.

In my mind to know if function followed the SRP try and explain what a particular function does and if you had the “and” word somewhere in the explanation, you probably went against the pattern somewhere.

The example given on Wikipedia is of a module the compiles and prints a report. Such a module could be changed for two reasons, cosmetic & substantive. Thus it would not follow SRP.

Personally I have violated this pattern in past projects and lived to regret it because it introduced week points in my code. In one project the client came back a few weeks later to ask me to change a cosmetic aspect of the project, and because the modules were not correctly designed, I broke another aspect of the program inadvertently – so in retrospect I am a strong believer in the SRP pattern.

Function Composition

Before I go any further I recommend that you read Chris Smith’s blog on Function Composition.

Like Chris, I I have really grown fond of the |> operator to chain functions which I expressed in a previous post about the forward pipe operator. I have however not really understood the difference between the |> operator and the >> operator (function composition operator) – it all at first glance seemed pretty much the same thing, however in Chris’s post he then goes on to indicate with the |> operator one needs an initial value to start the chain.

With the function composition operator the initial state/value is not needed… it is purely looking at composing a new function based on a collection of other functions combined – this changes the ball game a bit – up to now I have always tried to solve problems in one long chain, with the function composition approach I can segment the code a bit more – with base functions, and then intermediate functions etc till one comes up with the end function.

See the other best practices…

Posted on Saturday, July 10, 2010 4:31 PM F# | Back to top

Comments on this post: F# – 5 Best practices for F# (Practice 1)

# re: F# – 5 Best practices for F# (Practice 1)
Requesting Gravatar...
Good points. One thing I've started doing is this: whenever I design a function, I look at its signature and think: 1) is it Curry-able in a way that makes sense? 2) Does it work with |> in a way that makes sense? 3) Does it work with >> in a way that makes sense? Even if -- because of some other aspect of the design -- the answers must sometimes be "no," it still helps to ask these questions.
Left by TechNeilogy on Jul 10, 2010 5:04 PM

# re: F# – 5 Best practices for F# (Practice 1)
Requesting Gravatar...
Neil - I agree totally, having a look at SRP and especially functional composition has made me rethink my functions in F# totally.

I guess another comparison to the mentality is when one applies TDD principles to a project, if one knows you will be making unit tests and testing, you code in a way that allows for easier testing.

Likewise, because I am such a fan of currying etc, I am now code with that in mind so that I can get the full benefit...

Left by MarkPearl on Jul 10, 2010 6:30 PM

# re: F# – 5 Best practices for F# (Practice 1)
Requesting Gravatar...
Are you still doing f#?

I am just starting off. The problem i am facing is the first mental block, inheritance and polymorphism. How to write functions that are easily composable. Could you help me there a bit.
Left by Jyoti Ranjan on Jul 22, 2014 1:14 PM

Your comment:
 (will show your gravatar)

Copyright © MarkPearl | Powered by: