Is there any document that could be useful as a guideline for coding style, along the lines of the C# standards at [link:www.tiobe.com] ?

Don Syme wrote a paper on F# Formatting Conventions some time back. Does this work for you?

By on 4/15/2009 10:50 PM ()

Excellent answers, all of them. That's exactly what I was looking for. Thanks, guys!

By on 4/16/2009 12:41 AM ()

Expert F# also has some guidelines in chapter 19.

In terms of design (rather than just formatting style etc.), I'd like to emphasize what Michael says. We recommend that all F# programmers who write OO code to interoperate with .NET or use F# OO programming regularly be familiar with the .NET design guidelines and be able to apply these guidelines to their code where appropriate.

That said, there are some F# programmers who use only the functional programming subset, or who do no OO programming, or who do not deliver components to other people to use in DLL form. In these case the guidelines may be less applicable, though familiarity will still be useful.

In addition, if you are designing components that are explicitly F#-to-F# or are internal implementation components then additional design techniques become common. For example, one of these is the "functional programming design patterns" which you see in the F# core library (List.map, Array.filter etc.). These are carefully designed to make best use of functional programming features such as type inference, pipelining and curried functions. Note that the F# core library is explicitly designed for F#-to-F# use and to support F# implementation components.

Kind regards

don

By on 4/16/2009 8:15 AM ()

There's now a document about library/component API design online. It also has a short section about style advice for implementation code. Find the document here:

[link:research.microsoft.com]

By on 8/5/2010 6:09 AM ()

Thanks, Brian! This is a very interesting document.

One remark. Now it's rather difficult to find these documents released on MSDN or on MS Research site.

For example if you search for F# specification, then MS Research redirects you to MSDN F# developers center wich have no link to F# specification. I had to search the Internet and I found direct link to the spec document in the blogpost of Don Syme.

Generally, what is the status of F# project now? Is it still MS Research project? Or these issues are just leftovers of productization?

By on 8/5/2010 8:02 AM ()

Regarding search, a Bing search for any of

- F# specification

- F# spec

- F# language spec

- F# language specification

returns the correct doc as the first hit. Since the Design Guidelines document is new, I expect it will be a little bit of time before people link it and it gets page rank on search engines. (Personally I never use any individual site searches for public docs, as I find Bing is nearly always superior.)

Regarding links, we have some planned updates to the F# developer center in flight, we know we're currently missing links to these documents.

F# continues to be joint work with both MS Developer Division (that produces Visual Studio) and MSR. We've moved most of the documentation to the F# developer center on MSDN, but a few docs that we like to continually update frequently/out-of-band remain on the MSR site, simply because it is easier for us to update the MSR web site (without having to involve all the process/people that is often required to make updates to the more 'prime' web properties).

By on 8/5/2010 8:25 AM ()

Thanks, Brian. This is helpful.

I think what I really meant it's that F#page at Microsoft Research [link:research.microsoft.com] redirects to F# developers page site. And there are no links to MS Research part of F# project (like Design Guidlines). Of course one can use Bing or Google to find the document, but in this case you have to know exactly what document you need. I believe it would be very handy if MS research F# page contained such helpful links (like one to F# specs).

By on 8/5/2010 1:17 PM ()

C# is a little more loose with syntax. So, I think you need a few more guidelines.

I am by no means an expert. But, the only ``rules'' that I actively keep in my head when coding are these:

-consistent indenting

-use camel case (getAnObj () ).

-prefer recursion to mutable loops

-be mindful to make recursive loops tailcall.

-operate on the most general type possible

-keep functions as general as possible, sometimes adding ``default'' arguments. So:

1
let myFun f x f_zero = f_zero + (f x)

instead of:

1
let myFun f x = 0 + (f x)

Anyway, I guess you want a comprehensive list. Probably most of the OCaml guidelines should apply to F#: [link:caml.inria.fr]

By on 4/15/2009 4:21 PM ()

Also I'd point out that when using class types and members, standard .NET guidelines are still fine. In fact, I like having the difference in my code. Code that uses camel case or underscores indicates it probably means to be functional, code that looks like C# names is probably less so. The main win here is that usually we'll expect the OCaml looking code to be more pure, while OO looking code many times will not be pure.

By on 4/15/2009 5:58 PM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper