Skip to main content

​
Overview

This guide outlines the coding standards and conventions used in Minecraft Community Edition. Consistency is important for maintainability and collaboration.

​
General Principles

  • Readability: Code should be clear and self-documenting
  • Consistency: Follow existing patterns in the codebase
  • Maintainability: Write code that others can understand and modify
  • Performance: Consider performance implications, especially in hot paths

​
Naming Conventions

​
Classes and Structs

Class names use PascalCase: 
class Entity { };
class TileEntity { };
class MinecraftServer { };

​
Member Variables

Member variables use camelCase: 
class Tile {
    int lightEmission;
    float destroyTime;
    bool isTransparent;
};

​
Static Members

Static members follow the same camelCase convention: 
static Tile *rock;
static wstring TILE_DESCRIPTION_PREFIX;
static const float INDESTRUCTIBLE_DESTROY_TIME = -1.0f;

​
Constants

Constants use UPPER_SNAKE_CASE: 
static const int TILE_NUM_COUNT = 4096;
static const int TILE_NUM_MASK = 0xfff;
static const int TILE_NUM_SHIFT = 12;

​
Methods and Functions

Method names use camelCase: 
void updateEntity();
int getSmallId();
void setPosition(float x, float y, float z);

​
Namespaces

The project uses Java-style namespace organization through header file naming: 
#include "net.minecraft.world.entity.h"
#include "net.minecraft.world.level.tile.h"
#include "net.minecraft.world.item.h"

​
File Organization

​
Header Files

Header files follow this structure: 
#pragma once

// System includes
#include <string>
#include <vector>

// Project includes
#include "Material.h"
#include "Vec3.h"

using namespace std;

// Forward declarations
class Level;
class Player;

// Class definition
class Tile {
public:
    // Public members
protected:
    // Protected members
private:
    // Private members
};

​
Source Files

Source files follow this structure: 
#include "stdafx.h"

// Related header files
#include "net.minecraft.world.h"
#include "net.minecraft.world.entity.h"

// Local header
#include "Entity.h"

// Static member initialization
int Entity::entityCounter = 2048;

// Implementation
void Entity::update() {
    // ...
}
Always include stdafx.h first in .cpp files for precompiled header support.

​
Code Formatting

​
Indentation

  • Use tabs (not spaces)
  • Tab width: 4 characters
  • Indent each level consistently

​
Braces

Use K&R style bracing (opening brace on same line): 
if (condition) {
    // code
} else {
    // code
}

for (int i = 0; i < count; i++) {
    // code
}

class MyClass {
public:
    void myMethod() {
        // code
    }
};

​
Spacing

  • Space after keywords: if (condition), for (int i = 0; ...)
  • No space between function name and parentheses: doSomething()
  • Space around operators: a + b, x = y, i < count

​
Line Length

  • No strict limit, but prefer keeping lines reasonably short
  • Break long lines logically for readability

​
Comments and Documentation

​
Code Comments

Use comments to explain why, not what: 
// 4J - changed initialiser to 2048, as we are using range 0 - 2047 
// as special unique smaller ids for things that need network tracked
int Entity::entityCounter = 2048;

// If we are the server, check if there are any small Ids which are
// still in the ServerPlayer's vectors of entities to be removed
if (TlsGetValue(tlsIdx) != 0) {
    // ...
}

​
Team Comments

The codebase includes developer/team tags: 
// 4J added so we can have separate shapes for different threads
class ThreadStorage { };

// 4J Stu - Stair tile accesses the protected members
friend class StairTile;
When making significant changes, consider adding your own tags to track modifications.

​
TODO Comments

Use TODO comments for future work: 
// TODO: Optimize this loop for better performance
// TODO: Add validation for negative values

​
C++ Standards

​
Pointers and References

  • Use pointers (*) for optional/nullable values
  • Use references (&) for required parameters
  • Prefer smart pointers where appropriate
void processEntity(Entity* entity);  // May be null
void updateLevel(Level& level);      // Required, not null

​
Memory Management

  • Be explicit about ownership
  • Clean up resources properly
  • Use RAII patterns where appropriate
  • Be careful with manual new/delete

​
Type Usage

  • Use int for general integers
  • Use unsigned int for bit flags and sizes
  • Use float for game coordinates and math
  • Use wstring for text (wide strings)
  • Use bool for boolean values

​
Platform-Specific Code

When adding platform-specific code: 
#ifdef PLATFORM_DURANGO
    // Xbox-specific code
#endif

#ifdef PLATFORM_WINDOWS
    // Windows-specific code
#endif

​
Best Practices

​
Avoid Magic Numbers

Use named constants: 
// Bad
if (value > 4096) { }

// Good
static const int MAX_TILES = 4096;
if (value > MAX_TILES) { }

​
Prefer Early Returns

// Prefer this
if (!isValid) {
    return;
}
// Continue with main logic

// Over deeply nested code
if (isValid) {
    // lots of nested code
}

​
Initialization

Initialize variables when declaring them: 
int count = 0;
Entity* entity = nullptr;
bool isActive = false;

​
Code Review Checklist

Before submitting code:
  • Follows naming conventions
  • Properly formatted (tabs, bracing, spacing)
  • Comments explain complex logic
  • No compiler warnings
  • Builds without errors
  • Consistent with surrounding code

​
Learning from the Codebase

The best way to understand the code style is to read existing code:
  • Minecraft.World/Tile.cpp - Good example of static initialization
  • Minecraft.World/Entity.cpp - Complex entity management patterns
  • Header files in net.minecraft.world.*.h - Project organization
When in doubt, look at how similar code is written elsewhere in the project and follow that pattern.

Build docs developers (and LLMs) love

Get started for freeTalk to us