One of the things that consistently surprises me as a developer in the Salesforce eco system are the lies developers are comfortable telling themselves. Some lies (like that their code is self-documenting) are common developer myths. Others (like not needing git) are Salesforce community specific.
So, as a public service to the community, I provide here a list of common lies and a sentence or two about why you should stop telling them.
My code is self-documenting
Not once in my career have I heard a developer say this and found their code to be “self-documenting”. Never. Nope. (If we’re friends: yeah, not even yours.)
Developers who claim to write self-documenting code seem to solve problems in the least-obvious way available. Or at least it feels that way to me. Maybe if they left comments explaining why they used their approach it would seem brilliant. I don’t know; it’s never come up.
Self-documenting code doesn’t mean following a variable naming convention and having no comments at all. You still need doc comments. You still need good functional decomposition. You still need comments to say why your code does things. Sure, I can usually figure out what it does, but not why.
If you still want to argue with me make sure you read Chapter 15 of Mythical Man Month before calling.
See Also: Nobody else needs to understand this code; I’m the only one working on it
Just because you are the only one working on it right now, doesn’t mean that will be true 4 years from now. I recently had to update code that had been running happily without attention for 5 years. By the time I was working on it, everyone had forgotten it existed let alone how it worked.
And don’t forget you might be that person who needs to remember these details 5 years from now. Guess who I called first when we realized that code needed updating? Yup, the guy who wrote it. No, he didn’t remember why he had made important choices either.
The only time I am not disappointed in the person who committed code in my name 6 months ago is when he wrote me really good comments to explain what he was thinking. When he didn’t do that: that guy was an idiot.
Future you, your colleagues, friends, clients, strangers, they all will thank you for explaining yourself. Doesn’t that feel better than having them all hate you?
I don’t need to use Git
Yes.
You.
Do.
It’s 2025. Bell Labs invented source control in 1972. “I don’t know how to use it” isn’t a valid excuse. If you’ve been putting off learning to use these tools, it’s time you admit they aren’t going away.
Just because the code exists in a Salesforce sandbox org does not mean you don’t benefit from tracking its history, knowing who (including you) changed what when (and if they wrote good comments why!). The first time it saves you because another developer overwrote your code, it’ll have saved you all the time setup required and more.
I can setup a new repository, with Salesforce configuration, in 90 seconds. It takes 10 seconds to do a commit. Sure, you can have merge problems sometimes – that usually happens when two people make conflicting changes. When do you need source tracking the most? When two people make conflicting changes.
When you see two sandboxes with two different versions of code, how do you know which is right? On my projects it’s the one that matches Git, cause Git is always canonical.
There really is no good argument against putting every line of code into a repo. Just because you have an argument does not mean you have a good argument. It’ll take you less time to start using Git than it will take to argue with me.
See also: I’ll just comment out this section of code for now, and delete it later
No you won’t. Nope, stop kidding yourself. I’ve seen your 200 line blocks of commented out “stuff” (without notes about why it was there in the first place, or why it’s commented out). You want to keep it for 3 or 4 minutes while you test a change – okay sure. But this is part of what source control does for you. Deleted something you want back? Okay, go get it out of your source control system. Delete your block of commented out code before your next commit.
I will fix this hard-coded ID later
If it’s easy to fix, just do it now.
If it’s going to be a bunch of work later, you know as well as I do that you’ll find excuses not to bother at that point either.
Either write the query to get the Id you need now, or move it to custom metadata/setting/environment variable/whatever now. It’ll take probably take 5 minutes to do it right now, and 20 minutes to find the stupid thing later (and 10 minutes to fix it cause you’ll be tired from the 20 minute hunt).
My invocable action doesn’t need to be bulkified
Sure, damn near every example invocable action only processes the first record in the list. Yes, that encourages us to think it’s okay to write code that way. And yes, bulkifying code is hard sometimes.
You might think that your record triggered flow will only need to deal with one user-entered update at a time. And then someone loads a 100,000 records and your action breaks the whole process.
And sure, you always feel like your action is only getting used in that one Screen Flow. But 9 months from now when someone realizes they can get the inputs other ways and call your action with the screens and puts it in a record triggered flow your code will still work.
There exist settings where the screen flow thing is true. They are rare, but I’ve seen them. Use this measure to determine if it applies to your project: if you cannot write a rigorous proof which is good enough for your high school geometry/trig teacher (college CS or Math Professors will also count here) to accept showing this code will only ever be run in a one-record context – you better plan for 200 records.
I will convert this test setup to use a data factory when I have more tests
Why? Why would you think you will take the time to do this conversion later? When you arrive at “later” you will just need one more object added to your setup. Or maybe 2. And you can copy-paste it into the next test setup method. Then maybe add 2 more objects. And then you’ll just…
If you don’t lay down good patterns up front, you won’t convert to them later. Starting a test factory class doesn’t take a lot of time. Just do it now, and thank yourself later when you realize you’ve slowly built a factory that’s supporting 5 different test suites and hundreds of tests.
I’ll move my business logic out of the trigger once it’s working
Once your code is working you have almost no incentive to clean it up. Chances are you’ll just deploy your code and wash your hands of it. It wont be until you’re neck deep in a conflicting sets of requirements that you’ll decide it’s time to refactor this mess – and then you’ll wonder what each conditional was for in the first place (see self-documenting code above).
Even during a recent technical interview, I took the 15 seconds needed to create the trigger and have it call a service class. I didn’t plan to keep that code for more than 15 minutes and I still bothered. I really think it took 15 seconds. Bing, bang, done. Sorting it out later is so much harder then just doing it on the first pass.
As longs as I hit the test coverage requirement, my tests are good enough.
Automated test coverage is not about hitting a certain number of lines run – that’s the minimum threshold. Good automated tests ensure you code works correctly. Good test coverage now means that when you revise the code later you know if your revisions broke something.
- Do not play games with getting the coverage percentage up.
- Do not have tests with no assert statements.
- Do not decide that 75% is just fine because to get to 90% you’d have to write three more tests – write the three tests!
- Do not let test coverage meaningfully change when someone auto-formats your code.
Write tests that ensure your code meets specifications, not tests that make the deployment process happy.
I don’t need automated code standards enforcement
Salesforce Code Analyzer is a free tool you can install right now and will help ensure you don’t do stupid stuff in your code. It will also make sure you team follows the same habits. These tools have been around for Salesforce developers for years, but for some reason we don’t all consistently turn them on.
This is standard fare for professional developers. What makes you special that you don’t need to follow standards? Why would you think you can enforce standards on a team without automation?
Every time I have to do a commit to reformat code to be consistent with all the other code on a project, a [insert sad thing here] happens. This pretty much only comes up with people who don’t have auto-formatting of their own. Their code had blends of tabs and spaces, different line endings within the file, off-by-one spacing error (dear God I hope no one uses 3 on purpose), and all kinds of things that cause other editors to sputter and complain.
If you don’t like Salesforce’s default analyzer rules, you can setup your own. It’s just enforcing ESLint and PMD patterns. I have extremely little interest in debating code standards – just have some!
Special Thanks For Shared Salesforce Developer Lies
The following people sent me lies to include in this list, and I appreciate their shared pain. My rants about each are mine alone.