8 Classic Beginner Bugs Every Programmer Should Avoid

1. Punctuation Errors

New programmers often type Chinese punctuation such as full‑width commas ( ，) or quotes ( “”) inside source code, which the compiler cannot recognise. The author shows a snippet where a Map<String， Integer> declaration and a map.put("key1"， 1) call both use a Chinese comma, causing a compile‑time error. IDEs usually flag these characters, and the fix is to replace them with standard ASCII punctuation.

2. Updating Data Without a WHERE Clause

Because many modern ORM frameworks hide raw SQL, beginners may write an UPDATE or DELETE statement without a WHERE condition, unintentionally affecting every row. The article presents a dangerous query: UPDATE orders SET role = 'admin'; and then the correct version with a condition:

UPDATE orders SET role = 'admin' WHERE id = xxx;

The author notes that experienced developers instinctively add a WHERE clause and that production databases are often configured with safeguards to prevent full‑table updates.

3. Forgetting to Release Resources

Unclosed files, database connections, or network sockets cause resource leaks and eventual crashes. An example method opens a FileReader but never calls close():

public void readFile(String path) throws IOException {
    FileReader reader = new FileReader(path);
    char[] buffer = new char[1024];
    reader.read(buffer);
    // forgot to close the file
}

The author recommends always checking for a close method, using try‑with‑resources when possible, and shows the safe version:

public void readFile(String path) throws IOException {
    try (FileReader reader = new FileReader(path)) {
        char[] buffer = new char[1024];
        reader.read(buffer);
    }
}

4. Storing Passwords in Plain Text

Saving raw passwords in a database is a severe security flaw. The article displays an INSERT statement that stores "123456" directly:

INSERT INTO users (username, password) VALUES ('admin', '123456');

It then advises hashing with a salt, e.g. using BCrypt:

String hashedPassword = BCrypt.hashpw("123456", BCrypt.gensalt());

A real‑world case is cited where a company was fined €91 million for such a mistake.

5. Hard‑Coding API Keys in Front‑End Code

When a front‑end script embeds a third‑party API key, anyone can view it via the browser console, even if the code is obfuscated. The author shows:

// Third‑party API key
const API_KEY = "yupi123456";
async function getWeather(city) {
    const url = `https://codefather.cn/weather?city=${city}&apikey=${API_KEY}`;
    const response = await fetch(url);
    const data = await response.json();
    console.log(data);
}

The recommended mitigation is to proxy the request through a back‑end service so the key never reaches the client.

6. Mixing Environments

Developers sometimes deploy code that still points to a development database because they forgot to switch configuration files. An example application.yml points to jdbc:mysql://localhost:3306/dev_db. The author suggests using profile‑specific files such as application-dev.yml and application-prod.yml and selecting the active profile at startup.

7. Force‑Merging or Force‑Pushing Code

When a merge conflict appears, some rush to resolve it by running:

# ignore conflicts, force merge
git merge branch-feature --strategy-option=theirs
# force push, overwriting remote history
git push --force

The author warns that this creates hidden bugs and breaks team workflows. Instead, conflicts should be resolved manually, and protected branches should be enabled to prevent unreviewed pushes.

8. Committing Sensitive Information

Inexperienced developers may accidentally commit files containing database credentials or API keys to public repositories. The author recounts personal experience of a shared image‑hosting service key being exposed on GitHub. The solution is to keep secret configuration files out of version control (e.g., add them to .gitignore) and maintain separate files for open‑source and private use.