close up view of plasma

Best practise – what’s that?

It’s really simple and means exactly what you think:

a working method or set of working methods that is officially accepted as being the best to use in a particular business or industry, usually described formally and in detail

Cambridge English dictionary

In ServiceNow projects, I have usually encountered a document with guidelines for new developers, a slideshow or some other wiki pages. Worst case scenario – verbal instructions from co-worker. This is exactly what developers always forget. They are just too lazy to remember, not to mention the search for a document and then in a document just to check if a variable can be called like that or should I use camelCase. I know that, I’ve seen that, I’ve experienced that myself. So how can it be made better in ServiceNow? Since the developers are writing scripts in JavaScript, you can set up a linter!

Linter – what’s that?

In short – it is a process of running a program that will analyze code for potential errors (source). When working with JavaScript, one of the most popular linters is ESLint. And that’s exactly what’s being used in ServiceNow! What a luck!

Linter rules in ServiceNow

The rules are publicly available since New York, as you can read in this blog post. That release introduced a new system property called glide.ui.syntax_editor.linter.eslint_config. It still exists in Utah patch 4 and should be used for all scripts in global scope. Be aware though that it is ES5 complaint. Some ESLint rules may be deprecated and may not work for this release. In this post, I wanted to focus on ES12 scoped application.

For this split case, ServiceNow has given us another system property – glide.ui.syntax_editor.linter.eslint_config.ecmascript2021. It contains some basic rules and sets almost all of them to warn level. But it can be easily updated and force the developer to follow at least some of the best practices defined for the project.

We can pick the rules from the ESLint rules reference documentation page. Some of my favourites include:

Turning all of them on error will probably make most of the OOB scripts turn red from shame… But still, as a developer we should stick to the best practice.

As you can see, there’s a lot that can be setup without using documents or slideshows. If you are an architect or lead developer, help your fellow developers by speaking their language. Show them the errors, don’t make them read the book about code style.

Leave a Reply

Your email address will not be published. Required fields are marked *