Culture
-related information when parsing Date
and Time
-s CS-W1092Failing to pass Culture
-related information when parsing Date
and Time
-s prompts the runtime to use the host system's information.
If your application runs on systems that are spread across different regions with different locales, this can cause problems with the formatting.
One such example is DD/MM and MM/DD. To avoid such pitfalls, always pass in the Culture
-related information.
Length
-like property is compared against values which always evaluate to the same result CS-W1090Length
-like properties are usually used to "count" the number of elements.
For example, in the context of an array, Length
tells us the number of elements in the array.
Comparing this property against 0
using the <
or >=
operators is meaningless and will always evaluate to false
and true
respectively.
This comparison is likely a mistake and should be rewritten meaningfully.
DateTime.Now
that relies on system-specific information CS-W1091DateTime.Now
refers to the date and time that is local and specific to the computer on which the program is running.
Because you may either misinterpret this information or miss out on any additional information, it is recommended that you use DateTime.UtcNow
.
This ensures that your program, irrespective of which computer it runs on, utilizes information that is kept consistent.
IEnumerable.Skip()
takes in number of elements to skip rather than the index CS-W1093The Skip()
method takes in an int
parameter that denotes the number of elements to skip rather than the index of the element to skip.
Passing in 0
to this method is the same as saying "not to skip any element".
The correct syntax instead is Skip(1)
. Consider making the appropriate changes to ensure your program does not rely on flawed logic.
lock
on local variables is error-prone CS-W1094Trying to acquire a lock on a local variable is error-prone as different threads may end up locking on different instances of the same variable. Instead, you should be locking on a class field that is preferably designated as private
and readonly
, i.e. a dedicated object. Microsoft guidelines explicitly state that you should avoid locking on:
A conditional expression is an expression which contains the code that is to be executed depending on whether a condition is true or false. Having identical expressions for both the true and false branches is likely a mistake and can affect your program's execution path and is therefore recommended that you fix it.
A for
loop has 3 basic elements:
In this case, the inner for
loop is modifying a variable that belongs to the outer/enclosing for
loop. This can result in an undefined behavior such as infinite loop. It is therefore recommended that you modify the right variable to ensure that your loop terminates as required.
object[]
to string[]
will result in CastException
CS-W1075Casting a generic array of type object
to a string
array will always fail even if all the elements are strings. It is therefore recommended that you use a suitable and correct alternative such as System.Linq.Select
to convert the elements.
lock
statements should be avoided CS-W1076lock
statements allow you to safely access a resource in a concurrent environment. However, there are certain risks associated with it such as properly acquiring and releasing a lock, deadlocks, etc. An empty lock statement acquires the lock and releases it almost immediately and is usually not considered a proper practice and should be replaced with a suitable replacement such as wait handles.
if
statements should be avoided CS-W1077If statements allow you to execute code depending on whether the specified condition evaluates to true
or false
. An empty if
statement has no statements in both of its branches and effectively accomplishes nothing. Such statements should be avoided.
Synchronization allows you to safely access resources that may be subject to race conditions. If one of the accessors, getter, for example, utilizes lock
statements, it means that there is room for race condition and that the underlying resource may be concurrently accessible. In such cases, it is possible that there might be a similar race condition for the setter as well. It is therefore recommended that both accessors be mutually synchronized.
DateTime
object CS-W1080The DateTime
constructor allows you to specify the year, month, day, and time to construct a DateTime
object. However, this constructor throws an ArgumentOutOfRangeException
exception if the specified date is invalid.
The use of addition and subtraction operations can lead to the creation of invalid dates. Instead, it is recommended that you use APIs such as AddDays()
, AddMonths()
, and AddYears()
to construct a DateTime
object since these methods handle invalid dates more appropriately.
enum
should be unique CS-W1088Values in an enum
should always be unique. Having 2 different members of an enum
carry the same value is likely a mistake. Since such a flawed value can affect how your application behaves, it is recommended that you fix it as soon as possible.
An object was passed to a method that belongs to itself. However, the method in this case likely expects an argument that is different than the object upon which it is invoked. This is likely a typographical error and should be rectified immediately as it may alter your program's behavior.
C# allows you to define operators just like normal methods. However, these operators should not refer to themselves in their implementation. Doing so may result in unterminated recursive calls.
for
loop due to stackalloc
CS-W1025A stackalloc
expression allocates a block of memory on the stack and is cleaned up only when the controller exits the method. Placing a stackalloc
expression inside a loop continuously allocates memory and does not let it get discarded despite the controller exiting the loop's scope. It is therefore recommended that you rethink your approach.
DateTimeKind
when possible CS-W1099The DateTime
object has an overload that accepts DateTimeKind
. DateTimeKind
helps indicate whether the time represented
by this instance is based on local time, Coordinated Universal Time (UTC), or neither.
Because this value allows you to introduce uniformity when dealing with DateTime
-s, consider using the appropriate overloads
that accept this value, especially if your application runs across different time zones.
An object was instantiated but was neither assigned to a variable nor passed as an argument and was dropped immediately. This is likely a mistake. Consider utilizing the object appropriately. If the object is not required, remove the instantiation. If the object was instantiated because the constructor has side-effects, it is a bad design pattern. Instead, consider moving the side-effects to a separate method.
Accessors such as getter and setter are responsible for fetching and setting a backing field's value. It is always expected that these accessors refer to and operate on the same backing field. However, in this case, each accessor accesses a different field. This is likely a mistake and should be fixed accordingly.
Accessors, i.e. getters to be precise, returns a specific value. There are no constraints placed on what a getter can return.
However, in this case, the accessor seems to return an array that is a private
field.
In such cases, the returned array may be modified by the user as they are not write-protected.
Instead, it is recommended that you either not return an array or convert this property to a method and return a copy instead.