Java Fundamentals

Constants, final & Naming Conventions

15 min Lesson 7 of 14

Constants, final & Naming Conventions

Every program has values that should never change once they are set — the number of hours in a day, a tax rate, a maximum retry count. Java gives you the final keyword to lock a variable so its value cannot be reassigned. Combine final with the static modifier and you get a true class-level constant. On top of that, the Java community follows a strict set of naming conventions that tell every reader instantly what kind of identifier they are looking at. Both topics are short rules with outsized impact on code quality.

The final Keyword

Marking a local variable or a field as final means it can be assigned exactly once. Any attempt to reassign it is a compile-time error, so the compiler catches the mistake before the program ever runs.

public class FinalDemo {

    public static void main(String[] args) {

        final int MAX_RETRIES = 3;

        // MAX_RETRIES = 5; // compile error: cannot assign a value to final variable

        System.out.println("Max retries allowed: " + MAX_RETRIES);
    }
}

final does not mean immutable for objects. When you mark an object reference final, the reference cannot point to a different object — but the object itself can still be modified. For example, a final List<String> cannot be reassigned to a new list, but you can still call add() on it.

Class-Level Constants with static final

A final local variable is only useful inside one method. To share a constant across an entire program, declare it as public static final at the class level. The static part means it belongs to the class itself, not to any instance, so it is created once and reused everywhere.

public class MathConstants {

    public static final double PI          = 3.14159265358979;
    public static final int    DAYS_IN_WEEK = 7;
    public static final String APP_VERSION  = "1.0.0";

    public static void main(String[] args) {
        double radius = 5.0;
        double area = MathConstants.PI * radius * radius;
        System.out.println("Circle area: " + area);
    }
}

Callers refer to a public constant as ClassName.CONSTANT_NAME, or just CONSTANT_NAME from within the same class.

Naming Constants: UPPER_SNAKE_CASE

The Java convention is to write static final constants in UPPER_SNAKE_CASE — all capital letters with words separated by underscores. This is a visual signal that a value is fixed and should not be changed.

MAX_CONNECTIONS — good
TAX_RATE — good
defaultTimeout — bad (looks like a regular variable)
MAXCONNECTIONS — bad (hard to read without separators)

When in doubt, extract a constant. If you type the same literal number or string more than once, extract it to a named static final constant. Reading MAX_LOGIN_ATTEMPTS is far clearer than reading the bare number 5 scattered through your code.

Java Naming Conventions Overview

The Java community uses a single consistent naming system. Learn these rules once and your code will look professional to every Java developer who reads it.

Classes and Interfaces — PascalCase

Every word starts with a capital letter, no separators. Nouns for classes, adjectives for interfaces.

class BankAccount { }          // class — noun, PascalCase
class HttpRequestHandler { }   // class — two-word noun
interface Runnable { }         // interface — adjective, PascalCase
interface Comparable { }

Methods and Variables — camelCase

Start with a lowercase letter; every subsequent word starts with a capital. Methods are verb phrases; variables are noun phrases.

int accountBalance = 1000;         // variable — camelCase noun
String firstName = "Alice";

void calculateInterest() { }       // method — camelCase verb phrase
boolean isAccountActive() { }      // boolean method starts with is/has/can

Packages — all lowercase

Package names are fully lowercase, typically reversed domain names with dots separating segments. No camelCase, no underscores.

package com.mycompany.banking.accounts;
package org.example.utils;

Constants — UPPER_SNAKE_CASE

As shown earlier, static final fields use all-caps with underscores. This is the only case in Java where underscores appear in names.

public static final int    MAX_CONNECTIONS = 100;
public static final double TAX_RATE        = 0.08;
public static final String DEFAULT_CHARSET = "UTF-8";

Putting It All Together

The following class uses every convention correctly:

package com.example.shop;   // lowercase package

public class ShoppingCart { // PascalCase class

    public static final double MAX_DISCOUNT = 0.50; // UPPER_SNAKE constant
    public static final int    MAX_ITEMS    = 100;

    private String customerName;  // camelCase variable
    private int    itemCount;

    public ShoppingCart(String customerName) { // camelCase parameter
        this.customerName = customerName;
        this.itemCount    = 0;
    }

    public void addItem() {           // camelCase verb method
        if (itemCount < MAX_ITEMS) {
            itemCount++;
        }
    }

    public boolean isEmpty() {        // boolean method with is-prefix
        return itemCount == 0;
    }

    public int getItemCount() {       // getter with get-prefix
        return itemCount;
    }
}

Do not mix conventions. Writing Max_Discount or maxDiscount for a constant, or shopping_cart for a class name, signals to every Java reader that something is wrong. Java IDEs and static-analysis tools (like Checkstyle) flag convention violations automatically — follow them from the start.

Quick Reference

Classes / Interfaces — PascalCase — BankAccount, Serializable
Methods / Variables — camelCase — calculateTax(), totalAmount
Constants (static final) — UPPER_SNAKE_CASE — MAX_SIZE, PI
Packages — all.lowercase.dots — com.example.util

Summary

Use final to prevent reassignment of a variable and signal intent to future readers. Use public static final to create a shared class-level constant. Name those constants in UPPER_SNAKE_CASE, name classes in PascalCase, and name everything else in camelCase. These conventions are not optional style preferences — they are the standard every Java codebase follows, and breaking them is a clear sign to maintainers that something does not belong.