DevExpress CodeRush Tips&Tricks

Cause:

The redundant field initialization code issue of type ‘dead code‘ highlights unecessary initialization of fields that can be safely removed (because the common language runtime initializes all fields to their default values, regardless of their type). Value types are initialized to 0 and reference types are initialized to null. Explicitly initializing a field to its default value is redundant, degrades performance and adds to maintenance costs.

Read more…

The Base type constructors are not implemented code issue is an alternative code issue to the “Can implement base type constructors“. The different between these two is in their type – one is an error and another one is a hint. When the current type doesn’t implement non-default constructors from a base type the “Base type constructors are not implemented” error is shown.

Read more…

Cause:

The Can Implement base type constructor code issue of type hint suggests that you implement the constructors that are missing for the current class, but exist in the ancestor (base) class.

For instance, once you implement your custom exception class derived from the System.Exception, you have to provide the full set of its constructors. Failure to provide all of the constructors of the Exception class can make it difficult to correctly handle exceptions. For example, the constructor with the signature “Exception(string, Exception)” is used to create exceptions that are caused by other exceptions. Without this constructor, you cannot create and throw an instance of your exception descendant that contains an inner exception, which is what managed code should do in such situations.

Read more…

Cause:

When working with strings that contain multiple lines of text, you have to add newline characters to your strings, so each line is separated with a line break. Line breaks are often added by inserting a carriage return line feed escape characters. This can cause cross-platform compatibility issues, because your code might end up being compiled under Mono in Unix, for example.

The “Environment.NewLine can be used” CodeRush code issue shows a suggestion to convert escape characters (“\r\n“) inside your code into the constant value defined in .NET Framework. Changing these strings to the Environment.NewLine constant will, firstly, improve the code clarity, so you don’t have to use escape characters, and, secondly, fix potential platforms portability issues – so, you don’t have to be concerned about such problems.

Read more…

Cause:

The else statement is redundant when it doesn’t contain any code, and can be safely removed to improve readability. The type of code issue is a dead code.

Sample:

How to fix:

• Apply the Flatten Conditional refactoring:

CodeRush code issues technology highlights found issues right inside the Visual Studio code editor with different colors. There are two permanent bars with issue indicators to the left of the code editor, and to the right of the vertical scroll bar. The third optional bar is intended to view solution wide analysis statistics for files and projects. This bar appears at the bottom of the code editor, if enabled.

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 of a dead code type shows type parameters to a generic type, or method definitions that are not referenced within its scope, and can be removed. In a generic type or method definition, a type parameter is a placeholder for a specific type that a client specifies when they instantiate a variable of the generic type. Removing the unused type parameter may improve readability.

Read more…