I am mainly a C programmer. In my world, writing likeThis or like_this is just a matter of style. In Haskell however, it seems that camelCase is the definite choice. Personally, I find the later much more readable. Think pthread_mutexattr_init vs PthreadMutexAttrInit.
What’s more, I have configured vim to swap the numbers and their alternate symbols (in C), since numbers happen to be written much less frequently than symbols such as parentheses, star, ampersand etc, which makes life easier on my wrist. As a bonus, this lets me write this_sort_of_thing without using the shift key.
My question is, from the Haskell programmers, whether using underscore in names is acceptable to the Haskell community or not. Is camelCase an unwritten rule or common convention? Would it be ok to make the public functions likeThis but internally write like_this?
7
There’s nothing particularly bad about using underscores in Haskell. One convention I have seen is to use underscore_case for local bindings and camelCase for top-level functions, or to prefix fields of a record with the record name and an underscore:
data These a = These { these_fooBar, these_barBaz :: a }
However, I prefer to use camelCase everywhere since it’s not worth fretting over, that’s what a majority of Haskell code is like, and it’s consistent with module names and constructors—unless you like This_Sort_of_Thing.
2
We conform to conventions and standards so that our code is intuitive for other programmers to work with.
private string _field;
public string Property { get; set; }
public void PublicMethod(string parameter)
{
string localVariable;
}
private void privateMethod()
{
}
Most people that have been in a microsoft shop for a few years would be pretty familiar with this convention.
I wouldn’t need to question the scope of _appleCore or AppleCore; I know _appleCore is a private field and AppleCore is a public property.
Part of your pride as a developer should be in how easily other people can understand and work with your code. Making maintainable and extensible code means making it maintainable/extensible for other people as well, not just ourselves.
As for the question about Haskall specifically:
http://www.haskell.org/haskellwiki/Programming_guidelines#Naming_Conventions
They have guidelines, but ultimately the owner of the codebase can define the convention as whatever they choose, that much isn’t open for debate or question. Thus, this question you ask can’t be answered definitely by us.
2