We can learn so many things from software development and architecture principles. In software development, writing clean code is crucial; if you are a software developer, you would 100% appreciate the importance of clean code.

You might argue that the word ‘clean’ is a bit arbitrary here and what makes a code clean? Another thing you might say is that ServiceNow is a kind of low-code or no-code platform, so how is this applicable?
Let us look at the tenets of clean code and see how we can apply this to our ServiceNow implementation.

Reliability

If new features work half the time, we are probably better off without the feature. So the question is then, what makes something reliable?

for a function, feature, or implementation to be reliable means to be qualified as correct, stable, and resilient

Let us go through those points.

Correct: the code(client script, business rule, flow) conforms to a set of expectations which is the requirement.

Stable: this means the behavior is always consistent and correct given different valid input and situations.

Resilience: is about avoiding failure, so you can ensure that your flow or code always works.

Example of unreliable implementation :

• a Client script uses DOM manipulation
• a UI policy that sometimes works and sometimes does not due to an ordering issue-this implementation is not stable as UI policy is not constantly working
• Not implementing a retry policy for REST/SOAP in a flow- this implementation is not resilient as the flow would stop if it encounters a network issue.

Efficiency

when we design and implement solutions in the NOW platform, we should be doing so with an eye toward efficiency because resources are finite. We want to ensure that we use resources in the best way possible.

So when we talk about resources, what factors should we look at? The answer is time and space.

Time: we should always look for ways to optimize the time spent on any given action. For example, how long does it take to submit a request or incident? How long does it take to perform POST/GET if we integrate with a third-party tool?

Let’s contemplate those two blocks of code.

var count = 0;
var gr = new GlideRecord('incident');
gr.addQuery('category', 'software');
gr.query();
while(gr.next())
{
count++;
}
  gs.info('COUNT: ' + count);

var gr= new GlideAggregate('incident');
gr.addQuery('category', 'software');
gr.addAggregate('COUNT', 'sys_mod_count');
gr.query();
if (gr.next()) {
  gs.info('COUNT: ' + gr.getAggregate('COUNT', 'sys_mod_count'));

}

Block numbers 1 and 2 are reliable and meet our principle 1 for clean implementation; however, block number 1 is doing needless work! When code does an unnecessary job, it consumes too much time acting. in a large organization, those inefficient workflows, code, and integrations can add up together and massively effects the platform in negative the usability the platform

Space: when we talk about space, we are concerned with the size of things, so when we are building a portal, for example, we might be using an image as a logo or banner, we should be thinking about how to optimize the size of the image so will not affect page initial load time.

Maintainability 

When talking about maintainability, we refer to the ease with which we can make appropriate changes to configuration or code. An excellent example would be a hard-coded value in a business rule versus a value stored in the system property.

gr.assignment_group = gs.getProperty("incident.default_assignment");

gr.assignment_group= '4baec2fe07d3f0101263f19d7c1ed0a6';

So, how can we ensure that our implementation is maintainable? The answer is to ask yourself a few questions during the implementation

is my solution rigid? How easy can I extend the functionality of x or y?

A rigid solution is tough to change and maintain. If you spend too much effort to accommodate a small change, you likely have a rigorous solution in your hands

how fragile is my solution?

You can measure a solution’s fragility by understanding the impact of changing one area on another area. Let us say we change a code to make a bug fix or add a feature if it affects several unrelated things in a different part of your solution. We can say the solution is fragile.

Usability

Usability is all about creating a good experience. Creating an experience for end-users and also creating an experience for technical users. Usability is not only about fulfilling user requirements but about creating experiences that enable users to achieve their goals with minimal time and effort.

Suppose your employee service center or service portal is hard to navigate. In that case, they are probably not as usable as they suppose to be, but that is one type of usability.

The other type of usability that benefits your technical team is following a typical pattern for implementation. Suppose the function of your business rule or flow is unclear to the foreign eye. In that case, your implementation is not very usable.

How to make your code more usable?

Always use comments to explain what your code does.

    showEditOrNewButtonForPol: function(parent, targetTable) {
        // If parent table is policy, 'Edit'/'New' button will be only shown for the published policy
        // If parent table is profile/profile type, 'Edit'/'New' button will be always there
        var table = parent.getTableName();

        if (((table == targetTable) || ((table == 'sn_compliance_policy') && (parent.state == 'published'))) && parent.active == "1")
            return true;
        return false;
    },

The name of your client script, business rule, flow, or workflow should clearly indicate its function.

Consistently links the update set to the original user story that contains the business requirements.

Example: as part of story STRY0010001, We implement flow using update set STRY0010001-New Incident Caller-02022022