What are the reasons to choose between camelCase and Pascalcase in method names?

Question

First, I’m not interested in what you like best or what you use in your language, I want to know the motivation to choose one or the other pattern in a hypothetical language.

Second, this is a bit of coding style, which you should actually follow the pattern that the language has adopted, but mostly about why a language would adopt it like that. It’s not about an existing language, I’ll quote them to illustrate what I want.

A very typical example is that Java has adopted camelCase and C# has adopted Pascalcase. I have one bias Today for Pascalcase, I’m not sure why but once I saw Pascalcase it made a lot of sense to me, even having adopted camelCase before in other languages. But only C# kind of adopted him. I look at that and I feel that it’s more standardized, it looks like something in the structure of the code and differentiates it from the variable that’s part of the algorithm.

Half that everyone adopted the Pascalcase for names of types and even namespaces. In C# it does not differentiate anything for the method, but they are different contexts, the IDE puts proper color. Java, JS, and others preferred to make it clear that it is a method in a different way, while confusing it with variable names, except for the parentheses that is almost always used, but not in all cases. In the beginning Java never had this confusion, today it has, JS had to confuse, but it was not a well thought out language (PHP has a little of the two things, not confused at the beginning and was not well thought out, it does not always respect it). C# was born knowing that this could be confusing.

I like the idea of camelCase, but it looks ugly (it’s very subjective). I consider it an aspect of the programmer’s UX and so considering the design of language, because choosing the standard style does not cease to be part of this discipline, so wanted understand the motivation of each one’s use.

Answer 1

First a little history

This answer is based on this excellent article by Celso Kitamura https://celsokitamura.com.br/pascal-case-e-camel-case/

In 1813 Jacob Berzelius, a chemist, suggested a convention to formalize the way of writing chemical formulas. He proposed to indicate each chemical element by a one or two-letter symbol, the first in uppercase. See Example below:

In the example of the formula NaCl we would have SódioCloro = Sodium chloride, Even at that time there was no single concept for writing chemical formulas, and this proposal was adopted to normalize writing, and eventually became the rule. It was something that facilitated the life of the user, as it generates fewer errors and is easy to understand and use when writing formulas and elements.

This is the convention adopted in the periodic table, which was later applied in other media such as programming.

The cardinal points in turn use another convention for example.

Even between the 70s and 80s there was not quite a pattern, for N reasons, I will try to address them at another time. But what we saw was the Camel Case or Pascal Case being culturally adopted, and even though it’s not the rule they’re encouraged.

In the case of . NET, Microsoft recommends:

• Use Pascal Case for all public membership names, types and namespace consisting of several words.
  Propertydescriptor
  Htmltag
  
• Use Camel Case for parameter names.
  propertyDescriptor
  htmlTag
  

Here’s a list of Naming_Convention of various languages, to reflect on what they have in common, pros and cons, etc. (C and C++, Java, Javascript, . NET, PHP, Python, Ruby, etc.): https://en.wikipedia.org/wiki/Naming_convention_(Programming)

• Provide additional information (ie metadata) on the use for which an identifier is placed;
• Help formalize expectations and promote consistency within a development team;
• Allow the use of automated refactoring or search and replace tools with minimal error potential;
• Increase clarity in cases of potential ambiguity;
• To improve the aesthetic and professional appearance of the work product (for example, disapproving excessively long names, names - comical or "fluffy" or abbreviations);
• To help prevent "naming collisions" that may occur when the work product of different organizations is combined (see also: namespaces);
• Provide significant data to be used in project transfers that require sending the program’s source code and all relevant documentation;
• To provide better understanding in case of code reuse after a long time interval.

A word is a key

Notice how the height variation of the uppercase ascending line creates a visual Pattern, which can be used to easily recognize words. This variation in the frequency of letters helps the eye to recognize patterns and words faster. Already when everything is in HIGH BOX, the line does not vary, it is straight, and to recognize the word we need to really read more carefully.

var UmaChaveUtil //(3 variações de Case)
var umaChaveUtil //(2 variações de Case)

A "key" with more variations of "secret" may be more useful and better for general recognition... (I’ll talk more about it below)

---

Beyond the conventions - Typographical and UX aspects

Regardless of the language other points should be taken into consideration. For example, what is the difficulty of writing Palavraslongasemcamelcase? What is the milkability of this? In a world of words it is easier to recognize UmaPalavra or umaPalavra. Scanning is very important when identifying specific words in the middle of others. And in this Nngroup article there are good clues to the practices you can adopt that will present a better UX https://www.nngroup.com/articles/glanceable-fonts/.

Independent of being adopted Camel or Pascal the system is case sensitive? Using these rules will result in more errors or fewer errors, is it easier to write or read? For a system that doesn’t exist yet, consider an A/B Test. Reserved words can follow a convention, whereas classes that are first names can have another one... So even a Qualitative Research can be interesting in this work, something that is very common to do in UX and Design Thinking.

4° Heuristic Law: Users should not ask themselves whether different words, situations or actions mean the same thing.

When talking about heuristics the main factor may be consistency, so having clear rules avoids errors and makes the user more comfortable. So when defining a rule, avoid letting things like this be valid, because in addition to not having coherence, it can be ambiguous and confuse the user.

Source: https://www.nngroup.com/articles/ten-usability-heuristics/

Notice again the image above. Could the user understand "Calendar" differently than "calendar"? I can’t say, but it may be that people understand this differently, a calendar may be any calendar, the Calendar may be the Calendar App.

Visual prominence

Note the image above, see as a title with Cases varied seems to stand out more than the other only with the initial letter capitalized.

Source: https://medium.com/@jsaito/making-a-case-for-Letter-case-19d09f653c98

A little opinion

When you think of systems, the reserved words or standard words of the language, or that repeat themselves all the time and are equal to all, could be "more discreet", already the variáveis or classes (as in CSS), which are words that the user "invents" (and that each one can write in a way), you could define clear rules. For as are words designed by the user himself rules could be better than good practices. This would be a way to normalize writing independently of who writes. In CSS .classe is different from .Classe, but both work... Is that good or bad? Logically it depends, but if only one of the forms were allowed could be better for the user. The user likes to follow patterns, and the eye learns to find patterns... And Pascal Case can be an easier default for the user to identify non-original words in the language (words that are defined by other users). But as I said, more research and testing must be done.

Example table with clear rules:

Gestalt

When it comes to "pattern recognition," remember that not everything we see we’re actually reading. One of the principles of Gestalt is the recognition of forms. The human eye and the brain always tend and recognize shapes and patterns. And this can be fundamental to the scanning of code. It’s like a ruse that can help you quickly recognize words in the middle of the text.

As our brain uses visual reading parameters, when we see a compound of elements (be they objects, people, landscapes, animals or texts), the tendency is to group characteristics that are similar, so that their interpretation is as fast as possible.

Source: https://whitecom.com.br/8-principios-da-gestalt/

Wiki da Gestalt: https://en.wikipedia.org/wiki/Gestalt_psychology

Although it has been known for some time that the larger text is more readable, this study has shown that weight and process are also important. Lower-case letters required 26% more time to read accurately than upper-case letters, and condensed text required 11.2% more time than normal. There were also significant interaction effects between the case and the size, suggesting that the negative effects of lowercase letters are exacerbated with small font sizes.

Formerly the Ides, Terminals and Prompts were not so customizable, they had a font-size as well as a font-family standard, and color. Everything was thought for the user to have a better experience. So the typographical choices are also linked to how you will write. It is already proven that long texts not all written in capital letters, just as more "condensed" sources are more difficult to read.

Note the shape of the "shapes" see how Uppercase is more difficult to identify the character, mainly because of the "lack" of contrast because it has no descendants (p) and ascending (d) in base-line and caps-line.

See how a font with a small "X Height" is harder to tell the difference between Upper and Lower case (the first source has the X Height minor).

Self-regulation

But when language is free what we see is the emergence of conventions, whether written or organized, as is the case with CSS and its nomenclature methodologies as OOCSS, SMACSS, BEM, DRY. Site with some examples and definitions https://tableless.com.br/oocss-smacss-bem-dry-css-afinal-como-escrever-css/ it is worth saying that for each of them there are pros and cons, but choosing a standard rules should be followed, even in a "language" that has no rules :)

And in Mobile?

Have you ever wondered how tiring it can be to write in lower case letters on a mobile device? Especially with the spell checker trying to turn the camelCase every time? This is an environment that certainly would have to be studied to evaluate what would be easier and more productive for the user to work in. I didn’t think you were referring to the subject, but maybe the kebab-case (hyphenated words) are easier to type in cell phone.

So all these choices can influence the UX and the choice of what to adopt...

Recommended book Design-Time Web Usability Evaluation with Guideliner: https://site-109191.mozfiles.com/files/109191/2228-7961-1-SM.pdf

OBS 1: The Nngroup article quoted above made with "loose" words and not in plain text. It does not specifically address Camel Case or Pascal Case, and even suggests further studies.

OBS 2: I didn’t talk about it, but think about which of the two styles would be more interesting for Dyslexis. Thinking about accessibility and inclusion would be nice to have more information and take into account how a person with dyslexia or ADHD interact with these types.