1

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?

Joan Venge
  • 1,950
  • 2
  • 18
  • 24
  • 1
    related: [What is the philosophy/reasoning behind C#'s Pascal-casing method names?](http://programmers.stackexchange.com/questions/53498/what-is-the-philosophy-reasoning-behind-cs-pascal-casing-method-names) – gnat Apr 08 '14 at 04:05

2 Answers2

5

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.

daniel gratzer
  • 11,678
  • 3
  • 46
  • 51
  • But in other languages rewriting the base library is close to impossible, right? Like C# or Python. And even if you do, I think you won't be able to benefit from their fixes and additions. – Joan Venge Apr 07 '14 at 22:14
  • There are two other ways of doing it (that I know of) that could be called "no casing": c_style_underscores and lisp-style-hyphens. I agree with your second paragraph that justrunningitalltogether is bad, but I don't think "no casing" is the best thing to call it. – Michael Shaw Apr 07 '14 at 22:20
  • @MichaelShaw I'm going off the OP's usage of "no casing". It probably could be more accurately termed "unseperated and no casing" – daniel gratzer Apr 07 '14 at 22:21
  • Casing matters. www.therapistfinder.com Two words or three? – Loren Pechtel Apr 08 '14 at 03:10
  • @LorenPechtel Yep, that's what I meant by "unfortunate ambiguities". Experts exchange had to change their URL I believe – daniel gratzer Apr 08 '14 at 03:23
  • @jozefg I was just providing an example of "unfortunate ambiguities". – Loren Pechtel Apr 08 '14 at 03:36
  • Haskell is a bad example for rewriting the standard library to change case, since the language assigns different semantics to uppercase and lowercase identifiers. – Max Nanasy Jun 24 '14 at 04:09
2

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.

Idan Arye
  • 12,032
  • 31
  • 40