One of the interesting challenges of working with the Salesforce platform is its limits. To a developer who works in an open-source fashion (freedom of hardware/software to use), the only limits tend to be straight performance based (how much CPU/bandwidth/memory can I get?). Salesforce has these too, but they also have subtler limits, how many characters of code you can have deployed to a Salesforce server instance.
Floppies of Code
Imagine someone came to your (virtual) desk, and tossed seven 3.5” floppies onto it. “Alright, this is all our server can handle.” That what happens now for the default Salesforce “org” (synonym for server/environment), you have ten million characters. Before the Salesforce Summer 2018 update, the default was three million characters, roughly two 1.44 MB floppy disks.
This applies to the deployed Apex code on a server. Apex is a Java-esque, compiled language for Salesforce that allows you to program database triggers, and other ommon backend concepts.
Best Practices
Descriptive variables
Take the two variable declarations in Apex that represent a business rule:
Integer maxAmountofItemsInCart = 100;
Integer c = 100;
In practice, we can use either one of these to represent 100. Which one do you prefer?
Most developers are bound to say maxAmountofItemsInCart. It is descriptive, you have a clear idea of what the variables purpose is.
However, when limited, you are punished by a large factor (1 character to 22) for this choice.
Service Oriented Architecture / Tightly coupled APIs
In Salesforce, one of the useful features of the ability to write a custom REST endpoint using Apex. It would consume the amount of characters needed to code the endpoint.
An alternative though, is that you could also hit the basic CRUD/sObject REST API to get data, and then transform the data client side or in middleware. This would consume no Apex characters.
Maybe you want to decouple your backend’s schema from this service’s API. You could only do that is you took the first path (custom REST endpoint), which would involve you using X more Apex characters. You are technically punished for this.
Tabs are King
One of the stranger restrictions of the Salesforce platform’s Apex Character limit that is that it counts spaces in some ways. Spaces count in every context except when it is a only new line.
(taken from https://salesforce.stackexchange.com/questions/37265/percent-of-apex-used-do-spaces-count)
The implications for this are much worse. No indentation is now the maximum, with tabs being the “optimal” since it is 1 character for 4 characters (1 tab = 4 spaces).
Solution
One relatively easy solution could use the Apex prettier plugin to format all code to a tabWidth of 1, or you could use 100% tabs to reduce consumption.
Another mid-weight solution is a minifier that refactors local variables (in order to prevent breaking dependencies).
A heavy set solution involves dependency management and total minificiation of the org’s Apex code. Something similar to a 64K intro…
Conclusion
As much as I love the challenge of optimization, this is one silly hill to die on. The current default limit for all orgs is ten million characters, roughly 10 megabytes by UTF-8 standards. These kind of restrictions are stinky enough to would-be developers away from the platform.
I like developing on Salesforce for a variety of reasons, but this is not one of them. Hopefully, it changes in the future.
If you are running a SAAS platform, this is one area you should avoid if possible to build developer support and rapport.