I know Java/C#, so developing in Salesforce's Apex will be easy, right?

Well, maybe. Apex definitely looks like Java. But if you’re coming from something like a Java or C# background, you might find that Apex doesn’t always behave in the ways you’d expect. In this post, I’m going to walk you through a few of the pitfalls I came across as an experienced developer picking up Apex.

Watch out for these Apex gotchas!

Apex lets you add business logic to your Salesforce orgs. From the Apex Developer Guide, we know that Apex is a strongly typed, object-oriented programming language that’s used to execute flow and transaction control statements on Salesforce. And, yes, Apex uses a Java-like syntax. So far, so good –– at least the syntax is something I recognize 😅

But not so fast! Precisely because of Apex’s similarities to other languages, you might find yourself running into one or more little pitfalls when you start out.

‘public’ doesn’t mean the same thing

In Java and C#, I’m obviously very familiar with the access modifier keywords (public,private,protected, etc.). So you can forgive me for thinking thatpublicwould make my Apex classes visible to everyone –– accessible to any other class. Nope, not in Apex! Joining code for separate applications is discouraged. To make a class public like in Java, you need to use theglobalaccess modifier.

No namespaces

In Apex you can’t use namespacing to avoid collisions with other objects in the global namespace. For example, say I wanted to use two classes both calledScheduler. In Java or C#, that wouldn’t be an issue because I’d just include each instance of theSchedulerclass within its own separate namespace. But we can’t use namespaces in Apex, so that’s not an option. Instead, in this example, I’d need to give one of mySchedulerclasses a different name.

Tricky error messages

As well as getting to know the language itself, you might also stumble when it comes to the development environment. Error messages in the Salesforce Developer Console can be more difficult to decipher than what you might be used to in other languages.

As an example, I ran into this error after I saved my work and it tried to compile:InvocableMethod methods do not support parameter type of List–– a message that had me stumped at first. Luckily, Salesforce Stack Exchange is an extremely useful resource. In this case, I soon realized that the class I was using in my List didn’t contain at least one member variable with the invocable variable annotation.

Turn on your logging

When you inevitably hit a bug in your Apex, you’ll probably want to check your logs to find out what’s gone wrong. Gotcha! This is where I got caught out. One of our classes that’s meant to report on changes in our org reported zeros one day, which wasn’t what I’d expected. That’s fine, I thought, I can check the logs, right? But when I went to look, there was nothing there:

It turns out, debug logging in Apex needs to be turned on in advance and will only run for a maximum 24-hour period each time. I had to to go back and replicate the issue after I’d switched the logging on.

Use single quotes for strings

A simple thing, but one that might trip you up: Apex’s string delimiter uses single rather than double quotes. Yep, every language has its quirks.

Remember, remember, case insensitive

One last thing that might catch you out: it’s worth knowing in advance and remembering that all variables, methods, SOQL/SOSL statements and references to objects and fields are case insensitive in Apex.

Testing your Apex

Once you’re up and running with Apex, you’ll probably want to look into automating your unit tests. Unit testing is necessary in Salesforce both to check your code is doing what it’s meant to do, and also to meet Salesforce’s code coverage requirements.

Gearset lets you schedule automated testing jobs that allow you to specify and track your level of code coverage. You’ll receive automatic notifications of test failures and get reports on the changes to code coverage as well as the outcomes of all the unit testing jobs you’re running.

Another way of improving the quality of your Apex code is to use static code analysis (SCA) tools to check your code conforms to best practice in areas such as code style, design, security and performance. Any Apex code deployed by users on Gearset’s automation tier gets checked for issues including security vulnerabilities, code complexity and class-naming best practices by our PMD-based code analyzer.

Want to get started with Apex?

A good place to start is the Apex Developer Guide, which includes an excellent learning section to get you up to speed on the basics. Salesforce also offers lots of Trailhead modules on Apex, of course. And if you’re looking to acquire your first coding skills with Apex, there’s a useful overview of the best learning resources for those new to programming that’s published on Salesforce Ben.

As you get to grips with Apex, you’ll also want to think about code quality. For more on this, check out Gearset's whitepaperwhitepaper on static code analysis, or take a course right here on DevOps Launchpad!