Menu Home

Some Typescript compiler options for improving code quality

Set your compiler’s warning level to the highest, pickiest level possible and fix the code so that it doesn’t produce any compiler warnings

Steve McConnell Chapter 28 Debugging, Code Complete

The Typescript compiler has a number of options that can help improve the code within your project.

Switch on

The compiler options are found in the root directory of your Typescript project within a file named tsconfig.json file.

Typescript Additional Checks

The four options that are the focus of this post are grouped together under the heading “Additional Checks”. Initially they are commented out and in order to be used they should be uncommented. With the comment removed it is possible to enable\disable the option by using true or false respectively.

Once you have chosen which option(s) to enable, you should then recompile your project for the changes to take effect.

noUnusedLocals

noUnusedLocals issues a warning if you have declared a local variable or constant and it has not been used.

function foo(a: number, b: number) {
    const notUsed = 'I am never used';
    return a + b;
}

function foo above, has a unnecessary constant named notused. The default behaviour is for this to go unnoticed by the Typescript compiler.

noUnusedLocals disabled

If the noUnusedLocals compiler option is enabled you will see two notable differences.

noUnusedLocals enabled

The first is that my editor, VS Code has displayed a yellow wavy line under the unused constant. Hovering over the wavy line displays the following message

 'notUsed' is declared but its value is never read.ts   

The second difference is the compiler has also reported the error and the unused constant will either have to be used or deleted before compilation can succeed.

noUnusedParameters

This compiler warning indicates the presence of unused formal parameters.

function foo(a: number, b: number, c: number) {
  return a + b;
}

The formal parameter “c” is not used. If the compiler option noUnusedParameters is disabled no warnings or compiler errors are reported.

Once enabled and the project has been recompiled, similar to noUnusedLocals two differences are apparent.

noUnusedParameters enabled

VS code shows the now familiar yellow wavy line under the parameter named “c” . Hovering over this reveals the following:

'c' is declared but its value is never read.

The compiler reports the same error.

noImplicitReturns

This option reports an error when not all code paths in a function return a value.

To illustrate, I have changed the foo function which now only returns a value if the parameter “a” is greater than 10.

function foo(a: number, b: number) {    
    if(a > 10) {
        return a + b;
    }    
}

The default behaviour of noImplicitReturns is for the foo function to compile cleanly.

Once noImplicitReturns has been enabled the now familiar yellow wavy line within VS Code is displayed. Hovering over the function name reveals the message:

Not all code paths return a value

This message is also shown in the output from the Typescript compiler

noImplicitReturns enabled

noFallthroughCasesInSwitch

The final option is very useful in quickly highlighting potential problems in a switch statement.

The example below shows a switch statement and you will see that within the Grapes case I have omitted a break.

let fruit = 'Grapes';

switch (fruit) {
    case 'Apples':
        console.log('Apples selected');
        break;
    case 'Grapes':
        console.log('Grapes selected');        
    default: 
        console.log('Unknown fruit');
}

When this statement is executed I see the following unwanted output:

Grapes selected
Unknown fruit

Enabling noFallthroughCasesInSwitch highlights problems like this. Once enabled and I recompile I see the following:

noFallthroughCasesInSwitch enabled

Hovering over the yellow wavy line displays:

Fallthrough case in switch.

As with the previous examples the compiler also shows an error.

noFallthroughCasesInSwitch can get in the way when there are valid reasons for not having a break statement within the case statement so for those times you will need to consider disabling noFallthroughCasesInSwitch.

Categories: Typescript

oraclefrontovik

Developer

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.