Qual è il motivo della scelta di PascalCasing su camelCasing o viceversa da un linguaggio di programmazione POV?

Non esistono prove concrete per preferire il rivestimento del cammello al rivestimento pascal. Sebbene ciò non impedisca alle persone di discuterne molto. Se sei coerente, in ogni caso non c'è un'enorme differenza.

Nessun involucro presenta uno svantaggio nel non fornire suggerimenti su quali parole iniziano dove, il che rende più difficile l'analisi mentale e può portare a sfortunate ambiguità.

Infine, questa non è una scelta di design dal punto di vista del linguaggio di programmazione, ma da un punto di vista della libreria standard. Può sembrare una sciocchezza, ma nulla ti impedisce di costruire una nuova libreria standard e di importarla. In effetti, le persone lo fanno abbastanza spesso in Haskell. Non c'è nulla che ti impedisca di cambiare le convenzioni con una nuova libreria standard, poiché tutto potrebbe essere mantenuto coerente.

In molte lingue la convenzione è usare PascalCasing per i tipi (le uniche eccezioni che posso pensare sono lisps e STL). L'uso di camelCasing o snake_casing ti consente di assegnare facilmente un nome a una variabile dopo il suo tipo (come void foo(Bar bar) ).

anche snake_casing lo consente. Dovrai modificare più lettere (rimuovere caratteri di sottolineatura e lettere di decapitalizzazione), ma avrai la possibilità di prefissare get_ e set_ a nomi di proprietà intatti. Alcune lingue usano questo e altri lo usano.

Anche se C # potrebbe trarre beneficio dall'uso di camelCasing per cose come i nomi di proprietà ( public CustomData customData{get; set;} ), deve considerare l'altra lingua principale del framework .NET - Visual Basic.NET. VB.NET è case insensitive e non può differire tra CustomData , customData e cUstOMdAta . Rendendo sicuro tutto PascalCased C # non si verificano conflitti di nomi quando si utilizzano classi C # in VB.NET.