I like both but I notice languages that use camelCasing for members sometimes need more adjustments when you want to edit your code. For example (in Python):
node.customData()
vs
node.setCustomData()
custom changes casing. It could be avoided if it was:
node.getCustomData()
In C# they will use PascalCasing for example.
I know some even use no casing so:
node.getcustomdata()
It seems to be that scripting languages generally prefer camelCasing more than PascalCasing to be more relaxed?
Is there a reason for choosing one over the other from a programming language design POV?
1
There really isn’t hard evidence for preferring camel-casing over pascal-casing. Though that doesn’t stop people from arguing over it a lot. If you’re consistent, then there’s not a huge difference either way.
No casing comes with disadvantage of providing no hints for what words start where, which makes it more difficult to mentally parse and can lead to unfortunate ambiguities.
Finally, this really isn’t a design choice from a programming language point of view, but a standard library point of view. This may seem like a silly distinction, but nothing really stops you from building a new standard library and importing it. In fact people do this quite often in Haskell. There’s nothing that stops you from changing conventions with a new standard library, as everything could then be kept consistent.
7
In many languages the convention is to use PascalCasing for types(the only exceptions I can think of are lisps and STL). Using camelCasing or snake_casing allows you to easily name a variable after it’s type(like void foo(Bar bar)).
snake_casing also allows that. You’ll have to change more letters(remove underscores and decapitalize letters), but you get the ability to prefix get_ and set_ to intact property names. Some languages use this and some use that.
While it sounds like C# could benefit from using camelCasing for things like property names(public CustomData customData{get; set;}) it have to consider the other main language of the .NET framework – Visual Basic.NET. VB.NET is case insensitive and can’t differ between CustomData, customData and cUstOMdAta. By making everything PascalCased C# ensures no name conflicts when using C# classes in VB.NET.