DevExpress CodeRush Tips&Tricks

You might have already learned that CodeRush suggests several code issues that highlight the switch (Select in VB) statement with hints and warnings when it has suspicious code. For example, when the switch statement handles only a subset of the possible enumeration values it is checking for, this may be a sign of incomplete code.

Until recently, there were no code fixes of those code issues. Now, they appear:

Read more…

The process of adding a new CodeRush code issue and a code fix provider for the code issue in the Java Script language is the same as for any other supported language. As an example, we are going to add a code issue that will highlight the “for..in” loop with the following structure:

Read more…

Code Issues can be easily fixed with the corresponding code fixes. The code fixes are operations that allow you to automatically fix the issue by changing the source code, so the issue is no longer valid for the block of code in question. The code fixes are refactoring or code providers assigned to the code issues as fixes.

There are several ways to fix an issue:

1. Code Fix hint
2. Zoom Window
3. Manually apply a fix

Read more…

The Undisposed local code issue of the warning type highlights local variables that implement the System.IDisposable interface and are not explicitly disposed. The IDisposable interface was designed to provide a standard way to release unmanaged resources by calling its Dispose method. If the object is IDisposable, it is a good idea to dispose of it when you no longer need it, especially if the object uses unmanaged resources. These are resources that the .NET garbage collector does not manage on our behalf and is unable to clean-up automatically. They include items such as streams, files, database connections, handles and other operating system objects. If the memory and system resources that they use are not properly released, a program may suffer from memory leaks or problems due to locked resources.

Read more…

Cause:

This code issue shows a hint (suggestion) when the nested code structure can be simplified and unintended. This is allowed by converting conditional statements into a guard clauses.

The practical reason for this is that it simplifies your reading of the code and reduces the apparent complexity. There is no specific limit for the amount of nested code blocks, however, if you get your code nested too deep, most likely, it must be refactored. In some cases, it’s better to validate all of your input conditions at the beginning of a method and just bail out if anything is not correct. This follows the “fail fast” principle, and you really start to notice the benefit when you have lots of conditions. You can have a series of single-level if-statement checks that check successively more and more specific things, until you’re confident that your inputs are correct. The rest of the method will then be much easier to write and follow, and will tend to have fewer nested conditionals.

Sample:

How to fix:

Apply the Flatten Conditional refactoring:

Cause:

This code issue shows a dead code when there are unreferenced private property setters. Unused property setters of private properties can be safely removed, which will improve code readability.

Sample:

How to fix:

• Apply the Remove Setter code fix:

Cause:

This code issue shows a hint (suggestion) that a redundant constructor can be safely removed. Redundant constructor is a public, parameterless constructors without any code inside of its body. This constructor doesn’t call base type constructors and it is alone in the current class. The constructor is redundant because such constructors are automatically generated by the compiler. Removing the redundant constructors may improve code readability.

Sample:

How to fix:

• Remove the redundant constructor by applying the corresponding Remove Redundant Constructor refactoring:

• Add another constructor to the class, so the original constructor is no longer redundant:

Also, see the full list of code issues specific to constructors.

Cause:

This code issue shows a hint (suggestion) on the fields which can be marked as read-only. When a field declaration includes a readonly modifier, assignments to the fields introduced by the declaration can only occur as part of the declaration or in a constructor (instance or static) in the same class. Read-only fields cannot be changed by other code or the code from team members, thus making it less likely to be messed up by someone who doesn’t understand the purpose of the code.

Sample:

How to fix:

The Make Read-only refactoring is a code fix for this issue: