Getters must not throw exceptions CS-R1038
While it is acceptable for setters to throw exceptions, getters are simply expected to return a value. Throwing any exception is considered an antipattern and is not a recommended practice. It is recommended that you refactor your code accordingly.
Use of TODO/FIXME comment encountered CS-D1000
TODO/FIXME comments are usually placed within the source code to indicate that there might be a scenario that is either unaccounted for or that a feature requires further enhancements to function as expected/required. In either way, they must be addressed when and where possible to avoid unintended side-effects or breakdown.
Calling garbage collector manually does not necessarily improve performance CS-P1001
The .NET runtime ships with a GC (Garbage Collector) that is responsible for allocation and freeing up of memory as deemed necessary during an application's lifetime. It is responsible for automatically handling memory management-related tasks and preventing accidents such as memory leaks, accidental double frees, etc. Manually invoking the GC does not necessarily improve your application's performance and, in some cases, may even adversely impact the performance. If you wish to improve your application's performance, consider measures such as:
Explicit trap of NullReferenceException CS-R1009
Explicit trapping of NullReferenceException is usually considered a bad practice. It usually means that your application has come across a null reference in an unexpected manner which you're trying to suppress by explicitly trapping through a catch block rather than finding the root cause. Since this was unexpected, it is probably not safe for your application to continue with the execution.
Consider discarding empty blocks CS-R1012
Empty blocks do not necessarily add any value to the codebase and should be discarded if possible. Therefore, it is recommended that you either discard this empty block or refactor it accordingly.
Audit required: Call to potentially dangerous method DangerousGetHandle CS-A1001
Handle returned by DangerousGetHandle can be invalidated, become stale, or be recycled when APIs such as SetHandleAsInvalid is invoked. This can lead to potential security vulnerabilities within your application. It is therefore recommended that you use this method only if you know what you're doing and absolutely require it.
Audit: Consider using System.URI instead of strings CS-A1000
Representing URIs as strings can prove to be a security risk as they are difficult to parse, validate and encode. It is therefore recommended that you use the more safer and reliable built-in alternative System.URI.
Audit required: Switch to a better crypto algorithm CS-A1002
One or more crypto algorithms such as TripleDESCryptoServiceProvider, DESCryptoServiceProvider, and RC2CryptoServiceProvider are being used by your application. These algorithms are marked as obsolete and are no longer recommended. Please consider switching to a more modern and robust algorithm instead. Please check out the reference for some recommended algorithms.
Avoid empty finalizers CS-P1000
Finalizers, i.e., destructors, perform clean-up operations as an instance is picked up for garbage collection (GC). If a class has a finalizer defined, it is added to the Finalize queue, which is later processed by the GC when deemed appropriate. An empty finalizer adds unnecessary additional overhead to the GC since it does not perform effective clean-up operations. Therefore, it is suggested that you either remove the empty finalizer or add relevant clean-up operations.
Consider using Environment.ProcessId instead of Process.GetCurrentProcess().Id CS-P1002
Using Process.GetCurrentProcess().Id requires that an instance of Process be allocated to access the required Id. It then adds additional overhead, i.e., disposing of the Process instance. It is therefore suggested that you use the reliable and performant alternative Environment.ProcessId.
Consider making static readonly fields const CS-P1003
Expressions marked as static readonly do not require an object/instance of a class and can be accessed directly.
Since they're marked as static, they cannot be modified outside a static constructor. If such fields exist in a class without a static constructor, it is recommended that you mark them as const since expressions marked as const are fully evaluated at the compile-time.
Use aliases when using built-in types CS-R1000
Most of the built-in types in the language have aliases defined for them. Some such examples are:
[Type] [Alias] 1. System.String [String] -> string 2. System.Boolean [Boolean] -> bool 3. System.Byte [Byte] -> byte 4. System.Int32 [Int32] -> int
and so on. Therefore, it is suggested that you use these aliases when and where possible.
Do not overload the == operator to perform value equality checks CS-R1001
Operators such as == and != are expected to perform reference comparisons rather than compare values. If you intend to compare two different objects, consider implementing a relevant method in your class or look into interfaces such as IComparable<T> and IEquatable<T>.
Methods with Pure attribute should return a value CS-R1002
A method with the Pure attribute suggests that it does not have any side effects, i.e., does not mutate the object's state. Therefore, having such a method have a return type void does not make any sense. Therefore, it is suggested that you refactor your code accordingly, i.e., drop the said attribute or modify your method's logic.
Methods with DoesNotReturn attribute should not return a value CS-R1003
A method with the DoesNotReturn attribute suggests that the method does not return anything. Therefore, having return statements inside such methods does not make any sense. Therefore, it is suggested that you refactor your code accordingly, i.e., drop the said attribute or modify your method's logic.
Consider using .TryParse over .Parse when converting types CS-R1004
Methods such as int.Parse and double.Parse throw Exceptions such as ArgumentNullException, ArgumentException, FormatException or OverflowException depending on the input. Incorrectly handling these Exceptions can cause issues during the runtime. It is therefore suggested that you use the safer alternative .TryParse.
Async methods should not have a return type of void CS-R1005
An async method with return type void does not provide any reliable way to know if the intended task has been completed or not. It is a fire-and-forget method and provides no reliable way to handle any Exceptions should things go wrong. It is therefore suggested that your method have a return type Task.
Non-Async methods with return type Task/Task<T> should not return null CS-R1006
A non-async method with a return type of either Task or Task<T> should never return null. Doing so may result in a NullReferenceException at runtime. Therefore, it is suggested that you either modify your method's logic or use Task.FromResult<T>(null).
Use Guid.Empty to create an empty GUID CS-R1007
new SomeClass() is the syntax to instantiate a class in C#. However, new Guid() does not generate a new GUID. It instead returns an empty GUID. If you intend to use an empty GUID, consider using Guid.Empty as it is more straightforward to comprehend. If you wish to generate a new usable GUID, consider using Guid.NewGuid().
Exception caught is generic CS-R1008
The exception caught is generic and defeats the purpose of exception handling. Each type of exception provides an insight into what exactly went wrong and provides scenario-specific ways for graceful recovery. While it is easy to recover from some exceptions, a small subset of them make the recovery very difficult, usually because the conditions are not suitable for the program to continue executing. It is therefore suggested that you switch to a better approach of exception handling and recovery.