Nigel Swales on Flickr

Software programming does neat things with language, in this case, mixing capital letters.

Which do you think is easier to read, arrsomebigcollectionofdata or arrSomeBigCollectionOfData? If you read software code long enough, you will notice uppercase and lowercase letters are everywhere. What gives?

It’s not a secret code, exactly, and there’s no mysterious list of when to use capital letters and when not. Instead, it’s an example of how software programmers take a technical problem — in this case, how to make code readable — and find a fun way to describe the solution.

The use of capitals and lowercase letters is called CamelCase with the capital letters as the humps in the camel. It’s also been called BumpyCaps and HumpBack and a few other words. The most boring is the technical term, medial capitals. For some reason, CamelCase has stuck despite many cases where there are far more capital letters used than humps in a camel.

There’s also lower CamelCase which begins with a lowercase letter and upper CamelCase which begins with a capital letter.

The rules for how to use CamelCase are set by whoever decides the overall programming standards for a project. Sometimes those standards are defined by the creators of the language used. But mostly the rules for CamelCase tend to be lower CamelCase for variable names and upper CamelCase for functions, methods, and other blocks of code.

In some cases, lower CamelCase also is used to indicate functions and methods that can be used anywhere in the code (public) and upper CamelCase for code blocks that can only be used within another code block (private).

Regardless of the rules, using lower and uppercase letters helps programmers understand the role a name has within their software code.

Learn More


Naming Conventions (Programming)

CamelCase Generator

What is the point of the lower camel case variable casing convention (thisVariable, for example)?

Snake Case

Tall Man Lettering

Title Case


Building and creating your tools with the Minecraft toolbox helps you survive the game.


Sensors give robots the senses humans have.


30+ ideas for all age holiday gifts, from books to apps to board games to VR and more.


There might be a reason that too-real robot and video game character creeps you out.


You computer mouse cursor finally gets a cat to chase it.


Create turtles with Python, the programming language.


This programming language uses colors instead of text and punctuation to add and perform other tasks.


Use micro:bit to water your plants!


Knowing how passwords are cracked can help you create better passwords.

Studying satellite photographs shows a lot about what happens in the world.

There are a number of strategies teachers (plus parents and students) can take to learn programming.

JavaScript Style Guide and Coding Conventions

Always use the same coding conventions for all your JavaScript projects.

JavaScript Coding Conventions

Coding conventions are style guidelines for programming. They typically cover:

  • Naming and declaration rules for variables and functions.
  • Rules for the use of white space, indentation, and comments.
  • Programming practices and principles

Coding conventions secure quality:

  • Improves code readability
  • Make code maintenance easier

Coding conventions can be documented rules for teams to follow, or just be your individual coding practice.

This page describes the general JavaScript code conventions used by W3Schools. You should also read the next chapter “Best Practices”, and learn how to avoid coding pitfalls.

Variable Names

  • At W3schools we use camelCase for identifier names (variables and functions).
  • All names start with a letter.
  • At the bottom of this page, you will find a wider discussion about naming rules.
See also:  Why is the weather so hard to predict?

firstName = “John”;lastName = “Doe”;price = 19.90; tax = 0.20;

fullPrice = price + (price * tax);

Spaces Around Operators

Always put spaces around operators ( = + – * / ), and after commas:

var x = y + z;var values = [“Volvo”, “Saab”, “Fiat”];

Code Indentation

Always use 2 spaces for indentation of code blocks:

function toCelsius(fahrenheit) {   return (5 / 9) * (fahrenheit – 32);


Do not use tabs (tabulators) for indentation. Different editors interpret tabs differently.

Statement Rules

General rules for simple statements:

  • Always end a simple statement with a semicolon.

var values = [“Volvo”, “Saab”, “Fiat”];var person = {  firstName: “John”,  lastName: “Doe”,  age: 50,  eyeColor: “blue”


General rules for complex (compound) statements:

  • Put the opening bracket at the end of the first line.
  • Use one space before the opening bracket.
  • Put the closing bracket on a new line, without leading spaces.
  • Do not end a complex statement with a semicolon.

function toCelsius(fahrenheit) {   return (5 / 9) * (fahrenheit – 32);


for (i = 0; i < 5; i++) {  x += i;


if (time < 20) {  greeting = "Good day";} else {   greeting = "Good evening";


Object Rules

General rules for object definitions:

  • Place the opening bracket on the same line as the object name.
  • Use colon plus one space between each property and its value.
  • Use quotes around string values, not around numeric values.
  • Do not add a comma after the last property-value pair.
  • Place the closing bracket on a new line, without leading spaces.
  • Always end an object definition with a semicolon.

var person = {  firstName: “John”,  lastName: “Doe”,  age: 50,  eyeColor: “blue”



camelCase is a naming convention in which each word within a compound word is capitalized except for the first word. Software developers often use camelCase when writing source code.

camelCase is useful in programming since element names cannot contain spaces. The camelCase naming convention makes compound names more readable. For example, myOneMethod is easier to read than myonemethod.

Other examples of camelCase are listed below:

  • newString;
  • getNewString()
  • myVariableName;

The name camelCase (also “camel case” or “dromedary case”) comes from the hump on a camel, which is represented by the capital letter in the middle of the compound word. A camelCase word may have one or more capital letters.

camelCase vs PascalCase

camelCase is similar to PascalCase, which capitalizes the first letters of all words in a compound word, including the first word. For example, myFunction() in PascalCase would be MyFunction().

Programmers may choose to use either font case when writing source code, since it does not affect the syntax. While each developer can choose his or her preferred style, some programming languages have standard naming conventions.

For example, in Java, the following cases are recommended:

  • Classes: PascalCase — class VectorImage {}
  • Methods: camelCase — drawImage()
  • Variables: camelCase — string newImageName

NOTE: PascalCase is sometimes called “UpperCamelCase,” while standard camelCase may be specified as “lowerCamelCase.” In recent years, developers have moved away from these terms and use PascalCase and camelCase instead.

Updated: October 7, 2019

Cite this definition:

This page contains a technical definition of CamelCase. It explains in computing terminology what CamelCase means and is one of many software terms in the TechTerms dictionary.

All definitions on the TechTerms website are written to be technically accurate but also easy to understand. If you find this CamelCase definition to be helpful, you can reference it using the citation links above. If you think a term should be updated or added to the TechTerms dictionary, please email TechTerms!

See also:  Can i start a sentence with a conjunction?


У этого термина существуют и другие значения, см. Camel.

CamelCase (с англ.

 — «ВерблюжийРегистр», также «ГорбатыйРегистр», «СтильВерблюда») — стиль написания составных слов, при котором несколько слов пишутся слитно без пробелов, при этом каждое слово внутри фразы пишется с прописной буквы.

Стиль получил название CamelCase, поскольку прописные буквы внутри слова напоминают горбы верблюда (англ. Camel).

Частным случаем стиля является lowerCamelCase, когда с прописной буквы пишутся все слова, кроме первого.


Примеры CamelCase-написания: BackColor, backColor, CamelCase.

Иногда встречаются также следующие названия этого стиля:

  • BiCapitalization
  • BumpyCaps
  • BumpyCase
  • CamelCaps
  • CamelHumpedWord
  • CapWords
  • ClCl (Capital-lower Capital-lower) иногда ClC
  • CoolCaps
  • HumpBackNotation
  • InfixCaps
  • InterCaps
  • InternalCapitalization
  • MixedCase или mixedCase
  • Multicapitalization
  • NerdCaps
  • PascalCase
  • PolyCaps
  • WordCase
  • WordMixing
  • WordsStrungTogether или WordsRunTogether



CamelCase широко используется в языках программирования:

  • В языке Java принято использовать UpperCamelCase для именования классов и lowerCamelCase — для именования экземпляров классов и методов.
  • В Microsoft .NET принято использовать UpperCamelCase для именования классов и методов.
  • В PEP8, руководстве по написанию кода на языке Python, стиль CamelCase предлагается к использованию для имён классов.
  • В языке Wolfram Language стиль CamelCase используется для именования переменных, функций и опций. При этом объекты, встроенные в язык, всегда именуются в стиле UpperCamelCase, а для объектов, создаваемых программистом, принято использовать lowerCamelCase.

Использование стиля CamelCase в коде программы определяется личным вкусом программиста, если проект невелик по размеру. В крупных проектах, как правило, существует специальный документ, определяющий правило создания имён (переменных, функций, констант и пр.) для всех участников проекта.

Некоторые среды разработки (например, Qt Creator) предоставляют возможность автозаполнения по прописным буквам при использовании CamelCase (sCM → setContentMargins).

Принято считать альтернативным способом создания имён в программном коде стиль_змеиный_регистр, через_подчёркивание, или его вариант шашлычный-регистр (позвоночный-регистр) с дефисами, используемый в Лиспе. Тем не менее стили можно смешивать (например: среднее_КоличествоЯблок), поскольку стили создания имён являются лишь условной договорённостью и не влияют на работу программы.

Собственно стили появились из-за того, что в коде программы желательно иметь осмысленные имена переменных (описывающие смысл содержащегося в переменной значения), но не слишком длинные, а правила синтаксиса языков программирования налагают ограничения на средства для создания имён (к примеру, в большинстве языков допускается использование только буквенных символов, цифр и знака подчёркивания).

В некоторых wiki-движках, особенно ранних, используются CamelCase-ссылки (текст в CamelCase-стиле автоматически отображается как ссылка на другую wiki-страницу)[1]. К таким движкам относятся, например, MoinMoin, TWiki, JSPWiki, FlexWiki и DokuWiki.


  1. ↑ The Wiki Way | Dr Dobb’s


  • To CamelCase or Under score / 978-1-4244-3997-3/09
В этой статье не хватает ссылок на источники информации.Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена.Вы можете отредактировать эту статью, добавив ссылки на авторитетные источники.Эта отметка установлена 28 июня 2010 года.

camelcase – Rules

When it comes to naming variables, style guides generally fall into one of two camps: camelcase (variableName) and underscores (variable_name). This rule focuses on using the camelcase approach. If your style guide calls for camelCasing your variable names, then this rule is for you!

Rule Details

This rule looks for any underscores (_) located within the source code. It ignores leading and trailing underscores and only checks those in the middle of a variable name.

If ESLint decides that the variable is a constant (all uppercase), then no warning will be thrown. Otherwise, a warning will be thrown. This rule only flags definitions and assignments but not function calls.

In case of ES6 import statements, this rule only targets the name of the variable that will be imported into the local module scope.


This rule has an object option:

  • “properties”: “always” (default) enforces camelcase style for property names
  • “properties”: “never” does not check property names
  • “ignoreDestructuring”: false (default) enforces camelcase style for destructured identifiers
  • “ignoreDestructuring”: true does not check destructured identifiers (but still checks any use of those identifiers later in the code)
  • “ignoreImports”: false (default) enforces camelcase style for ES2015 imports
  • “ignoreImports”: true does not check ES2015 imports (but still checks any use of the imports later in the code except function arguments)
  • allow (string[]) list of properties to accept. Accept regex.
See also:  What is the famous monty hall problem?

properties: “always”

Examples of incorrect code for this rule with the default { “properties”: “always” } option:

  • import
  • from
  • “external-module”
  • var
  • “#112C85”
  • function do_something()
  • function()
  • function foo({ no_camelcased })
  • function foo({ isCamelcased: no_camelcased })
  • function foo({ no_camelcased = 'default value' })
  • var
  • my_pref
  • 1
  • var
  • 1
  • var
  • foo
  • var
  • foo
  • 1

{ no_camelcased } my_favorite_color = ; { } obj.do_something = { }; { }; { } { }; obj = { :
}; { category_id = } = query; { : no_camelcased } = bar; { : bar_baz = } = quz;

Examples of correct code for this rule with the default { “properties”: “always” } option:

  1. import
  2. as
  3. from
  4. “external-module”
  5. var
  6. “#112C85”
  7. var
  8. “#112C85”
  9. var
  10. “#112C85”
  11. var
  12. “#112C85”
  13. var
  14. var
  15. qux
  16. new
  17. var
  18. category_id
  19. function foo({ isCamelCased })
  20. function foo({ isCamelCased: isAlsoCamelCased })
  21. function foo({ isCamelCased = 'default value' })
  22. var
  23. 1
  24. var
  25. foo
  26. var
  27. foo
  28. 1

{ no_camelcased camelCased } ; myFavoriteColor = ;
_myFavoriteColor = ;
myFavoriteColor_ = ;
foo = bar.baz_boom;
foo = { : bar.baz_boom }; obj.do_something();
do_something(); { : category } = query; { }; { } { }; { categoryId = } = query; { : isCamelCased } = bar; { : isCamelCased = } = quz;

properties: “never”

Examples of correct code for this rule with the { “properties”: “never” } option:

  • var
  • my_pref
  • 1

obj = { :

ignoreDestructuring: false

Examples of incorrect code for this rule with the default { “ignoreDestructuring”: false } option:

  1. var
  2. var
  3. 1
  4. var
  5. category_id
  6. var
  7. category_id
  8. var
  9. category_id

{ category_id } = query; { category_id = } = query; { : category_id } = query; { : category_alias } = query; { : categoryId, …other_props } = query;

ignoreDestructuring: true

Examples of incorrect code for this rule with the { “ignoreDestructuring”: true } option:

  • var
  • category_id
  • var

{ : category_alias } = query; { category_id, …other_props } = query;

Examples of correct code for this rule with the { “ignoreDestructuring”: true } option:

  1. var
  2. var
  3. 1
  4. var
  5. category_id

{ category_id } = query; { category_id = } = query; { : category_id } = query;

Please note that this option applies only to identifiers inside destructuring patterns. It doesn't additionally allow any particular use of the created variables later in the code apart from the use that is already allowed by default or by other options.

Examples of additional incorrect code for this rule with the { “ignoreDestructuring”: true } option:

  • var
  • var
  • 1

{ some_property } = obj; foo = some_property + ;

A common use case for this option is to avoid useless renaming when the identifier is not intended to be used later in the code.

Examples of additional correct code for this rule with the { “ignoreDestructuring”: true } option:


{ some_property, …rest } = obj;

Another common use case for this option is in combination with { “properties”: “never” }, when the identifier is intended to be used only as a property shorthand.

Examples of additional correct code for this rule with the { “properties”: “never”, “ignoreDestructuring”: true } options:


{ some_property } = obj;
doSomething({ some_property });

ignoreImports: false

Examples of incorrect code for this rule with the default { “ignoreImports”: false } option:

  1. import
  2. from
  3. 'mod'

{ snake_cased } ;

ignoreImports: true

Examples of incorrect code for this rule with the { “ignoreImports”: true } option:

  • import
  • from
  • 'mod'
  • import
  • as
  • from
  • 'mod'

default_import ; * namespaced_import ;

Examples of correct code for this rule with the { “ignoreImports”: true } option:

  1. import
  2. from
  3. 'mod'

{ snake_cased } ;


Examples of correct code for this rule with the allow option:

function UNSAFE_componentWillMount()



function UNSAFE_componentWillMount()

{ }

function UNSAFE_componentWillMount()



When Not To Use It

If you have established coding standards using a different naming convention (separating words with underscores), turn this rule off.


This rule was introduced in ESLint 0.0.2.


  • Rule source
  • Documentation source

Be the first to comment

Leave a Reply

Your email address will not be published.