There is a document about naming conventions at Don Syme's WebLog:

[link:blogs.msdn.com]

//Huusom

By on 11/20/2007 2:27 AM ()

Yep, its kinda of a mixture of .NET and ocaml, tending more towards .NET. The biggest move away from ocaml is that F# tries to avoid underscores in identifier names, and I think the lack of underscores generally improves the readablity of the code. But I guess thats just my personal taste.

By on 11/20/2007 2:48 AM ()

Will the rest of core library eventually get a Camel casing convention? As I find it highly inelegant to see underscore and Camel mixed together.

I even see this mix within the same module like List.sumByFloat and List.fold_left

By on 7/29/2008 1:58 AM ()

Hi,

We've been looking at this issue and will be making some cleanup here in the F# CTP, especially for the inconsistencies like the one you mention.

Kind regards

don

By on 7/30/2008 4:54 PM ()

Hi,

We've been looking at this issue and will be making some cleanup here in the F# CTP, especially for the inconsistencies like the one you mention.

Kind regards

don

Thanks, so will that mean fold_left will become foldLeft ?

By on 7/31/2008 7:13 PM ()

I'm hoping for "FoldLeft" since that would follow the conventions of general .NET Framework.

By on 9/10/2008 5:20 AM ()

Agree that "FoldLeft" will be the way to go it terms of clarity and general .NET consistency.

By on 1/6/2009 8:14 PM ()

One more vote for FoldLeft.

By on 1/7/2009 4:07 AM ()

One things for sure - I don't think everybody's going happy whatever conventions finally get chosen :)

By on 9/10/2008 5:23 AM ()

I personally have no preference for camelcase or underscore style, but a mixture of the two styles is not nice imo. For F# the logical choice would be to use camelcase everywhere.

By on 9/10/2008 6:26 AM ()

Thanks, so will that mean fold_left will become foldLeft ?

I hope it becomes foldl as in Haskell :-)

By on 8/8/2008 10:30 AM ()

I don't hope so. :)

I see a tendency of functional programmers to use abbreviated names all the time; I guess this somehow derives from the higher terseness of functional syntax in general and a historical acceptance for abbreviations.

While over time there seems to have been achieved some common sense about using meaningful, unabbreviated names for functions/methods/variables and all the like (though sometimes a bit overboarding), the area of functional programming does not seem to have adapted that.

IMHO, some the "typical" function names to be found in languages as LISP, Haskell, Ocaml, aso. are horrible. While admirably terse for the knowing wizard, they have to be learned by the beginners, who, in most cases, won't be able to guess the meaning of a function by it's name. I have to admit, though, that there are enough functions, where I could not think of a name that would truly describe what the function does - higher order functions, like map and fold_left are good examples.

Some renamings (mostly de-abbreviations) I would suggest to make life easier for beginners might be:

  • fst -> first
  • snd -> second
  • hd -> head
  • tl -> tail
  • mem -> contains
  • assoc -> associate
  • ...

I know how this would upset the community of traditional functional programmers, and that this would be an all too great change to the library to really consider doing that, but looking from the perspective of a C#-convert, I guess I would shake my head at the sight of such names, and I do: my personal all-time-favourite is the "assq"-function.

By on 9/10/2008 4:52 AM ()

As an F# beginner with an extensive background in other (non-functional) languages over a couple of decades, I am puzzled by the mix of names I'm encountering. I'm coming to realize that many of these are historically motivated or used for compatibility with existing languages; these are items such as 'fst' and 'snd' (my first thoughts were 'fast' and 'sound').

The only time I've used such abbreviated names was when I coded in IBM 360 assembly, where 8 characters was the maximum. Thus, items like 'hd' and 'tl' at first looked like variable names to me. I thought this was just, as Josquin said, "admirably terse for the knowing wizard". Turns out he was right, but I was only partly right. (I got on a lot better with my F# programs once I realized that they were not variable names after all.)

Someday, I too will be a knowing wizard. But even when I become one, I know that the following will still be true:

1. Terseness is not particularly a virtue. Editor macros and VS Snippets make having to type All Those Extra Characters less of a pain point. Once spelled out, functions and variables are much better understood. And after all, don't we as professional programmers write to be understood?

2. Mixing conventions is not helpful. One of the beautiful aspects of .NET is that there is a great deal of consistency in both naming and in the common methods you will find for any type. Consistent naming helps you grok code better, understand it more readily. I am still struggling with this as I read some of the more substantial F# samples, especially those that combine .NET calls with calls to the "compatible" methods. At first glance, it's almost like the code is slipping back and forth between two much-different languages.

I've always been able to see the other side of the coin, and one of the special qualities of F# is precisely that it DOES have that polyglot nature. You can use it functionally or imperitively or both at once in the same code. You can understand it from the OCaml viewpoint, or use it just as a front end to .NET. It's like a lovable mongrel puppy. You don't like when it pees on the carpet, but it's just too cute to kick to the curb.

But while I'm still a beginner, I guess I'll have to put up with getting my assqicked by the mix of conventions.

By on 1/7/2009 10:58 AM ()

Consistency is a must.

This, however, does not mean that we need CamelCase everywhere. I would be perfectly happy with using underscores for the "functional" part of F# (Modules members, that is) and .NET conventions with normal class members. Unfortunately, this approach does not really answer the question with regards to static members of normal classes. (Not modules)

Abbreviations: Try to avoid them. I really couldn't see the reason why first and second had to be abbreviated.

Speaking of fold_left: Seq.fold should be renamed to Seq.fold_left even though there is no corresponding fold_right for sequences, making it more obvious how the function works. But that's just my opinion.

By on 1/7/2009 7:38 PM ()

So... the CTP is out... what about the naming conventions? I'm struggling with my boss right now to use the lowercase-Ocaml-like.

:-)

By on 9/9/2008 12:30 AM ()

Thanks, guys!

I've read the document... the usage of the mixture syntax is much clearer now...

By on 11/20/2007 11:25 AM ()
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