views:

144

answers:

4

If in F# I have methods like:

drawBox
drawSphere
paintImage

Would they be transferred to C#, exactly the same?

If that's the case, then wouldn't it compromise the naming conventions in C#, where methods are supposed to be PascalCase?

Or should I make them PascalCase in F# as well to remedy this?

+1  A: 

type methods names will be the same both in F# and C#. if you want PascalCase in C# - you should use this naming convention in F#, the same with camelCase.

desco
Ok thanks. Since I use C# more, I will probably do that. Was just thinking in that case, it would ruin F#'s naming conventions.
Joan Venge
+7  A: 

You should follow the F# Component Design Guidelines.

The notable parts are:

  • Do use the .NET naming and capitalization conventions for object-oriented code, including F#-facing libraries.
  • Do use either PascalCase or camelCase for public functions and values in F# modules. camelCase is generally used for public functions which are designed to be used unqualified (e.g. invalidArg), and for the "standard collection functions" (e.g. List.map). In both these cases, the function names act much like keywords in the language.

Another way to slice it:

  • members and types should always be PascalCase, just like C#
  • let-bound entities in modules can be camelCase, but this stuff is typically not stuff you'd expose publicly out of a library that is intended to be consumed by C#
Brian
Thanks, out of curiosity, do you also know how free functions in F# show up in C#? Because C# can't have free functions like F#.
Joan Venge
Modules in F# appear like static classes in C#. Note that 'top-level' code in F# is in a module; e.g. top-level code in `Program.fs` is compiled into a module named `Program` and so C# would see `Program.blah`. But avoid public F# modules if you want to interop with C# (as per the recommendations in the doc). In other words, read the doc; we spent a lot of time putting together all this info to answer these kinds of questions.
Brian
Thanks Brian, I didn't know you were one of the F# devs. Btw is it also acceptable to use the CompiledName attribute as Tomas mentioned in his reply? That seems like the best of both worlds.
Joan Venge
You _can_ use it, but... it also gives you the worst of both worlds, in that it can be confusing for non-language-specific assets (like documentation). The guidelines doc does not recommend it (or even mention it). But then again, the guidelines doc steers you in a direction where it's a non-issue (only expose namespaces/type/members publicly to C#, in which case the naming conventions are identical).
Brian
+1 to Brian's comment!
Mitya
A: 

Naming conventions are for humans. Compilers and runtimes really don't care if every variable name is entirely unreadable, they'll still work.

cdkMoose
Why the down vote? My point was to indicate that naming conventions are for us and when mixed environments have different conventiosn we can do what works for us, since the compilers/run-times will do the right thing anyway.
cdkMoose
+3  A: 

As others already pointed out, the names of compiled members are exactly the same as the names you wrote in the F# code. In general, it is a good idea to follow standard C# naming conventions when declaring classes. When declaring an F# module then you can either use camelCase (especially for modules that are intended for F# users) or PascalCase if you want to use them from C#.

Also, there is one trick that you can use (this is used in the F# core library for functions like List.map that are actually compiled as List.Map). You can use the CompiledName attribute to specify the name in the compiled version:

module Bar = 
  [<CompiledName("Foo")>]
  let foo a = a + 1

It is probably better to use a unified naming convention, but if you want to keep a nice short name for F# users and standard .NET name for C# users, this is an interesting option.

Tomas Petricek
Wow, that option rules. Thanks for pointing that.
Joan Venge
Personally, I really dislike `CompiledName`; it creates as many problems as it solves. The best I can say about it is that it's a necessary evil for things like FSharp.Core.dll (if we ever move the F# runtime into the .NET Framework proper, the compiled names must be in alignment with .NET, which is what motivated `CompiledName` in the first place).
Brian
As Brian pointed out above, please only consider that as an option of a last resort.
Mitya
@Brian, @Mitya: It is certainly better to use some unified naming convention (FSharp.Core.dll being a proof of that :-)), but there may be cases where the `CompiledName` attribtue could be useful, so I think it's worth mentioning it.
Tomas Petricek