This is a MUA project aiming at "attracting more developers to Moodle project" - https://moodleassociation.org/mod/page/view.php?id=520.
I would like to ask Moodle HQ for an estimate of the effort required here.

Short version

Change Moodle variables from using $moodlecase standard to $camelCase.

Long version

Description

Change naming convention for variables from $moodlestandard to $camelCase. This is to bring Moodle naming convention in line with most of the current PHP projects.
It seems that camelCase is by far the most popular standard of naming variables, it is used by:

• Symfony - http://symfony.com/doc/current/contributing/code/standards.html#naming-conventions
• Zend - https://framework.zend.com/manual/2.4/en/ref/coding.standard.html#variables
• CakePHP - https://book.cakephp.org/3.0/en/contributing/cakephp-coding-conventions.html#variables
• Drupal - https://www.drupal.org/docs/develop/standards/coding-standards#naming
• Laravel - https://github.com/laravel/framework/blob/5.5/src/Illuminate/Database/Connection.php
• Yii - https://github.com/yiisoft/yii2/blob/master/framework/data/ActiveDataProvider.php#L180

• CodeIgniter is the only one I found using snake_case https://codeigniter.com/user_guide/general/styleguide.html#variable-names

Initial idea of the tasks required

• Update https://docs.moodle.org/dev/Coding_style#Variables.
• Update code checker.
• Extract a list of all variables used in Moodle code.
• Create a file with mappings between an old and new variable name, e.g.:
  • node,node
    contextlevel,contextLevel
    courseorsystemcontext,courseOrSystemContext
• Create a list of core Moodle files (exclude 3-rd party libraries).
• Create a script to replace variables. Ideas: fancy sed-like script, tokenizer: http://www.php.net/manual/en/function.token-get-all.php or PHP parser: https://github.com/nikic/PHP-Parser
• Run against the whole code.
• To avoid changes in the DB schema, some DB API methods may need to be changed - e.g. conver members of $dataobject in $DB->insert_record to lowercase.
  See if Moodle still works.
• Run all automated tests.
• Commit, tag.

Challenges

git blame will be broken.

After refactoring on this scale, most of the lines of code will change. This means that git blame will point to this change, until more commits over-write it.

Solution:
If a developer wants to find out the meaningful last commit that affected given line and git blame points to commit that introduced the refactoring - he must look at the commit before that. To make it easier, we can:

• make all changes in one big commit

• tag the commit, e.g. REFACTORING

Then one can call git blame REFACTORING~1 file_name.php

 h3. cherry-picking to older branches will be more difficult

The commit introduced after refactoring will not apply cleanly in an older branch. The variable names will need to be changed manually. If the lazy ones simple bash script that uses previously created substitution list can be created - you take git commit, pipe it into the variable substitution script and then to git apply.

Breaking the code

We could break the code in many ways here. For example imagine that core Moodle code uses a class Mailer from 3-rd party library.
If it would use a code like this in core:

$mymailer = new Mailer();

$mymailer->mymailerattribute = 17;

Then refactoring mymailerattribute into myMailerAttribute will not work - since we're doing the change in core files only.

Solution: hopefully the above is not a problem at all, since we only do replacements for moodlecase variables - no other library seems to be using this standard, so they are safe.