So, you’re writing Apex. It’s that moment when you move past what Salesforce gives you out of the box and start building something truly custom. It’s powerful, right? You can make the platform do almost anything. But here’s the thing: with that power comes a ton of responsibility, and it’s incredibly easy to write bad code that causes big problems.
I’ve been in the Salesforce world for a long time, and I’ve seen it all. I’ve seen projects grind to a halt because of inefficient code, and I’ve spent weekends cleaning up messes that could have been avoided. I want to give you the advice I wish I had when I started—the real-world rules for writing Apex that works, lasts, and won’t get you in trouble.
First, What Are We Even Talking About?
Let’s get on the same page. Apex is Salesforce’s own programming language. It feels a lot like Java, and it’s what we call “strongly typed” and “object-oriented.”
What does that actually mean for you? It means you’re building the custom engine for your Salesforce org. When a process is too complex for a Flow or you need to connect to an outside system in a specific way, you turn to Apex. It’s your tool for writing custom business logic directly on the server.
The Non-Negotiable Rules of Clean Apex
If you want to be a professional developer and not just a code-slinger, you need to follow some core principles. These aren’t just suggestions; they are the foundation of good development on the platform.
Rule 1: Don’t Make Me Guess (Write Readable Code)
Your code should read like a story, not a puzzle. Six months from now, you—or worse, someone else—will have to look at it again. Will they understand it? Use clear variable names. Use consistent formatting. If a piece of logic is tricky, add a comment explaining why you did it that way, not just what it does. It’s a sign of respect for your future self and your team.
Rule 2: Treat Your Queries Like They’re Made of Gold
Salesforce runs on a shared system, which means it puts limits on what your code can do. These are called governor limits. Think of it like a monthly budget. You only have a certain number of SOQL queries you can run in a single transaction. If you blow your budget, everything stops.
This means you absolutely cannot put a SOQL query inside a loop. It’s the cardinal sin of Apex development. I once had to fix a production process that was failing because a developer did exactly that. A user tried to update 50 records, the code tried to run 50 queries, and the whole thing crashed. Don’t be that person. Learn how to write efficient queries from day one.
Rule 3: Always, Always Think in Bulk
The biggest mistake I see new developers make is writing code that only works for one record at a time. Your triggers and methods must be able to handle a list of 200 records just as easily as they handle one. This isn’t optional. Data imports, integrations, and mass updates will happen. If your code isn’t built for it, it will break. It’s that simple. Design for bulk operations from the start, every single time.
Rule 4: Expect Things to Break
Your code will fail. I promise you it will. A required field will be empty, a query will return no results, a system will be down. The question is, what happens then? Does your application crash and burn, leaving the user with a cryptic red error message? Or does it fail gracefully? You must use try-catch blocks to handle exceptions. Log the error, show the user a helpful message, and prevent a small issue from becoming a catastrophe.
Rule 5: Test Your Code Like You Mean It
Salesforce requires 75% code coverage to deploy to production. Let’s be honest: 75% is a C-minus. It’s the bare minimum to get by. Don’t aim for the minimum. Your tests are your safety net. They prove your code does what you think it does, and they protect you from breaking things later. A good test suite covers not just the “happy path” but also bulk scenarios and edge cases. Good tests are what separate the amateurs from the pros.
Apex Doesn’t Live on an Island
Your Apex code is part of a bigger system. Knowing how to connect it to other parts of Salesforce is what makes it so effective.
Working with Salesforce Flow
Flow is an amazing tool for automation, but sometimes you hit a wall and need more complex logic. You can build an “invocable” Apex method that your Flow can call. This gives you the best of both worlds: the ease of low-code for the overall process and the power of custom code for the really hard parts.
Powering Your User Interface
If you’re building Lightning Web Components (LWC), Apex is your backend. Your LWC is the slick, modern storefront, but Apex is the warehouse and logistics team in the back making it all work. It fetches the data, performs the calculations, and saves the changes. A good partnership between your LWC and Apex controller is key to a fast, responsive user experience.
The Security Stuff You Absolutely Cannot Ignore
Writing insecure code is the fastest way to create a disaster. You have a professional obligation to protect your company’s data.
- Field-Level Security: Just because your code can see a field doesn’t mean the user running it is allowed to. You must check for field and object accessibility in your code to make sure you aren’t accidentally exposing sensitive data.
- Sharing Rules: By default, Apex runs in “system mode,” which means it ignores all sharing rules and can see every single record. This is dangerous. When you need to enforce a user’s permissions, you must use the ‘with sharing’ keyword on your class definition.
- SOQL Injection: This is a huge one. Never, ever build a query by stitching strings together with user input. It’s like leaving your front door wide open for an attacker. Always use binding variables to safely include variables in your queries.
It’s About Professionalism
At the end of the day, writing good Apex isn’t just about making something work. It’s about being a professional. It’s about writing code that is clean, efficient, secure, and maintainable. It’s about thinking of the platform’s limits, the user’s experience, and the next developer who has to look at your work. Master these principles, and you’ll be building valuable solutions for a long time to come.
