Wouldn’t it be great to prevent a whole category of bugs by arming your SAP Cloud Application Programming Model projects with a few tools? And wouldn’t it be even better if that would also end stylistic discussions about your code?
Why would you want to use it? You hit save and it formats the code in a consistent style for your entire team. You don’t have to discuss style during code review. It saves you time and energy.
And why can you call Prettier a testing tool? Look at it:
What’s the value of d here? Do you know the order of operations of these operators by heart? If so, great! But do you trust that all your colleagues know them well enough not to introduce an error when refactoring?
Run this code through Prettier, and this is what you get:
Even if you know the order of operations, the extra brackets – which Prettier automatically adds when you save the file – are pretty helpful. And if you realize that this is not what you wanted, you can add the brackets yourself and Prettier will leave it that way.
This is an example of what Prettier does to make the intent of your code more obvious – freeing your brain to focus on more challenging problems.
On formatting, we should mention that ESLint can also format code. And we use that for formatting CDS files. Big thanks to the CAP team for providing this!
So ESLint looks at your code to find problems quickly. If there is an automated solution that applies, it suggests it for you. So it not only finds errors but, sometimes, fixes them for you.
And it’s highly customizable. You can write your own rules that work with ESLint’s built-in rules, and you can customize it to work exactly the way you need it for your project. That’s what the CAP team has done, for example, to provide consistency and help for your CDS files.
Do you recognize the problem? If so, that’s great! But don’t you think it’s cool when you don’t have to strain your brain to find and correct subtle errors like this? I do! Let a computer do as much work for me as possible, please and thank you. That’s what ESLint does for you.
So if you don’t know where the error is yet, let’s look at the error message in a project with ESLint enabled:
Isn’t it great that a simple tool, once configured, can help you catch such errors? Mixing up the order of operations will almost always yield unexpected results. Similarly, misapplied negation will also yield bad results. Here the difference between !recipe in req.data and !(recipe in req.data). The first looks for a boolean value (!recipe) in req.data, and the other looks for a string and inverts the result.
But it doesn’t stop there. ESLint helps you fix this issue. Let’s take a look:
Not only can you check coding errors, but you can also enforce or warn about naming conventions and styling. Let’s look at some warnings that the CAP team provides for cds files:
It helps you come to a standard naming style within your team, for example, for CDS files. No more discussions about indentations, spaces, and capitalization. Great!
Now, what do you need to get started with ESLint in your CAP projects? Just use CDS Lint. Initialize it. That’s it. Simple, isn’t it?
Can you spot the error in this code?
Maybe you can, maybe you can’t. Maybe your employees can, maybe they can’t. It would be cool if we had software that could detect the problem for us. Let’s rewrite this function in TypeScript:
Now if we call it as before, we get:
I like to think of type definitions with TypeScript as a form of automated inline testing. I highly recommend you try it out if you haven’t already.
A step-by-step introduction is possible with these tools. Try it out on your next feature and see what you think.
Use available tools to avoid mistakes and save time
Static code analysis is a great way to gain significant confidence in your code – quickly, efficiently, and with less effort than writing unit tests for your entire codebase.
Since you don’t have to focus on content that you can automate, your mind is free to focus on the critical things.
Stop wasting your time discussing indentations, single quotes vs. double quotes, and avoidable errors.
If you’re not using these tools yet, start now.
Stay healthy, stay curious, and enjoy the process.