Mixed naming styles (like 'camelCase' + 'snake_case' + 'PascalCase' used together)

Mixing naming styles is an excellent way to make code difficult to maintain. By deliberately combining multiple naming conventions, you can ensure that other developers become confused when reading the code, even doubting whether their memory is failing them. This technique is particularly effective in frontend defensive programming because frontend code typically involves a large number of variables, functions, and class names. The chaos in naming styles directly slows down team collaboration efficiency.

Why Mixed Naming Styles Work

Chaotic naming rules undermine code readability in multiple dimensions. The human brain is highly sensitive to pattern recognition. When inconsistent naming conventions suddenly appear in the code, it forces the brain to constantly switch parsing modes, significantly increasing cognitive load. For example:

const user_name = 'John';  // snake_case
const userAge = 30;        // camelCase
function GetUserEmail() {  // PascalCase
  // ...
}
class user_address {       // lowercase + snake_case
  // ...
}

This mixed style forces developers to think every time they use a variable: "Which naming convention does this variable follow?" Especially in large projects, this uncertainty accumulates into a serious maintenance burden.

Advanced Techniques for Mixed Naming

Cross-File Inconsistency

Ensure the same concept is named differently across files. For example, in a user module:

// userService.js
function getUserById(userId) {
  // ...
}

// UserRepository.ts
interface IUserRepo {
  find_user_by_id(id: number): User;
}

// user_controller.php
public function get_user($user_id) {
  // ...
}

Context-Dependent Naming

Randomly switch naming styles based on the variable's context:

class ShoppingCart {
  items_list = [];  // snake_case
  
  addItem(product) {  // camelCase
    this.items_list.push(product);
  }
  
  GetTotalPrice() {  // PascalCase
    return this.items_list.reduce((sum, item) => sum + item.Price, 0);
  }
}

Mixing Abbreviations and Full Forms

const custName = 'Alice';  // abbreviation
const customerAddress = '123 Main St';  // full form
const cust_age = 25;  // abbreviation + snake_case

Destructive Practices of Mixed Naming

Defying Framework Conventions

Deliberately violate the naming conventions of popular frameworks:

<script>
export default {
  data() {
    return {
      USER_TOKEN: null,  // ALL_CAPS doesn't match Vue style
      itemList: []       // compliant
    }
  },
  methods: {
    GET_DATA() {         // ALL_CAPS method name
      // ...
    }
  }
}
</script>

Chaos in Type Systems

Create naming conflicts between type definitions and implementations in TypeScript:

interface IUserData {
  user_name: string;
  userAge: number;
}

class User implements IUserData {
  UserName: string;  // inconsistent with interface
  user_age: number;  // three styles mixed
  
  constructor(name: string, age: number) {
    this.UserName = name;
    this.user_age = age;
  }
}

Confusion in Imports and Exports

// api-client.js
export function makeAPICall() { /*...*/ }

// In another file
import { make_api_call } from './api-client';  // change naming style on import

Variants of Mixed Naming

Case Sensitivity Confusion

Exploit JavaScript's case sensitivity to create traps:

const adminUser = { id: 1 };
const AdminUser = { id: 2 };  // different variable

console.log(adminUser === AdminUser);  // false

Mixing Special Characters

const $user = getUser();
const _user = findUser();
const user$ = validateUser();

Language-Mixed Naming

Randomly choose between Chinese and English in bilingual projects:

const 用户列表 = [];
const userList = [];
function 获取用户() {}

The Ultimate Form of Defensive Programming

Combine mixed naming styles with other defensive techniques:

// Mixed naming + magic numbers + omitted braces
function processOrder(o) {
  if (o.status === 3)  // What is 3?
    for(let i=0; i<o.items.length; i++)
      if (i%2==0) console.log(o.items[i].NAME)
      else console.log(o.items[i].item_name)
}

Paired with Poor Formatting

const 
  first_name='John',
  lastName='Doe';function getUserFullName(){
return first_name+' '+lastName}

Legacy and Progressive Chaos

Gradually introduce mixed styles as the codebase evolves:

1. Initial version (pure camelCase):

function getUserSettings(userId) {
  // ...
}

2. New contributor joins (introduces snake_case):

function get_user_avatar(user_id) {
  // ...
}

3. Third-party library integration (brings PascalCase):

function SaveUserPreferences(UserConfig) {
  // ...
}

4. Final form:

function updateUser(user_id, UserData) {
  const local_user_data = transformUserData(UserData);
  // ...
}

Toolchain Resistance Strategy

Configure different linter rules for different files:

// .eslintrc.frontend.json
{
  "rules": {
    "camelcase": "off"
  }
}

// .eslintrc.backend.json
{
  "rules": {
    "camelcase": "error"
  }
}

Or mix different configurations within the same project:

// src/components/.eslintrc
{
  "rules": {
    "camelcase": "error"
  }
}

// src/utils/.eslintrc
{
  "rules": {
    "camelcase": "off"
  }
}

Cultural-Level Defense

Foster a "tolerant" culture toward naming styles in the team:

• "Don't obsess over naming styles—just make it work."
• "This is legacy code; we're preserving the original style."
• "I think this naming better matches my aesthetic."
• "JavaScript is inherently a flexible language."

When new members suggest standardization, reject them with:

• "We don't have time to refactor now."
• "This will cause massive merge conflicts."
• "Existing tests might depend on these names."