Modify rule S1186: LaYC format (#2095)

This commit is contained in:
Sebastien Marichal 2023-06-09 14:51:36 +02:00 committed by GitHub
parent 1a8d33d656
commit a42c849e3b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
16 changed files with 137 additions and 102 deletions

View File

@ -0,0 +1,9 @@
In this case, it is important to put a comment explaining the reason for the empty implementation.
[source,csharp]
----
void DoSomething() // Compliant
{
// Do nothing because of X
}
----

View File

@ -0,0 +1,4 @@
[source,csharp]
----
void DoSomething() { } // Noncompliant
----

View File

@ -0,0 +1,7 @@
You can make clear the initial intention to add an implementation in the future by throwing the https://learn.microsoft.com/en-us/dotnet/api/system.notsupportedexception[`NotSupportedException`].
[source,csharp]
----
void DoSomething() => // Compliant
throw new NotImplementedException();
----

View File

@ -0,0 +1,7 @@
You can make clear the initial intention not to implement the method in the future by throwing the https://learn.microsoft.com/en-us/dotnet/api/system.notsupportedexception[`NotSupportedException`].
[source,csharp]
----
void DoSomething() => // Compliant
throw new NotSupportedException();
----

View File

@ -1,47 +1,20 @@
== Why is this an issue?
There are several reasons for a method not to have a method body:
:operationName: method
:emptyCode: csharp/empty-code.adoc
:notsupportedCode: csharp/notsupported-code.adoc
:notimplementedCode: csharp/notimplemented-code.adoc
:commentCode: csharp/comment-code.adoc
* It is an unintentional omission, and should be fixed.
* It is not yet, or never will be, supported. In this case a ``++NotSupportedException++`` should be thrown.
* The method is an intentionally-blank override. In this case a nested comment should explain the reason for the blank override.
=== Noncompliant code example
[source,csharp]
----
public override void DoSomething()
{
}
public override void DoSomethingElse()
{
}
----
=== Compliant solution
[source,csharp]
----
public override void DoSomething()
{
// Do nothing because of X and Y.
}
public override void DoSomethingElse()
{
throw new NotSupportedException();
}
----
include::../why-dotnet.adoc[]
=== Exceptions
The following methods are ignored:
The following empty methods are considered compliant:
* empty ``++virtual++`` methods,
* empty methods that override an ``++abstract++`` method,
* empty overrides in test assemblies.
* empty `virtual` methods as the implementation might not be required in the base class
* empty methods that override an `abstract` method as the implementation is mandatory for child class
* empty overrides in test assemblies for mocking purposes
ifdef::env-github,rspecator-view[]
@ -58,9 +31,6 @@ include::../message.adoc[]
=== on 11 Nov 2020, 19:45:36 Andrei Epure wrote:
\[~nicolas.harraudeau] I believe this rule could also apply to local functions and to property setters, right?
 
----
public void Method()
{

View File

@ -0,0 +1,8 @@
In this case, it is important to put a comment explaining the reason for the empty implementation.
[source,vb6,diff-id=1,diff-type=compliant]
----
Sub DoSomething()
' Do nothing because of X
End Sub
----

View File

@ -0,0 +1,5 @@
[source,vb6,diff-id=1,diff-type=noncompliant]
----
Sub DoSomething()
End Sub
----

View File

@ -0,0 +1,8 @@
In order to provide the initial intention to add an implementation in the future, you can raise an error and specify that the procedure is not implemented yet.
[source,vb6,diff-id=1,diff-type=compliant]
----
Sub DoSomething()
Err.Raise(1, , "NotImplemented")
End Sub
----

View File

@ -0,0 +1,8 @@
In order to provide the initial intention to not add an implementation in the future, you can raise an error and specify that the procedure will not be implemented.
[source,vb6,diff-id=1,diff-type=compliant]
----
Sub DoSomething()
Err.Raise(1, , "NotSupported")
End Sub
----

View File

@ -1,35 +1,12 @@
== Why is this an issue?
There are several reasons for a method not to have a method body:
:operationName: procedure
:emptyCode: vb6/empty-code.adoc
:notsupportedCode: vb6/notsupported-code.adoc
:notimplementedCode: vb6/notimplemented-code.adoc
:commentCode: vb6/comment-code.adoc
* It is an unintentional omission, and should be fixed.
* It is not yet, or never will be, supported. In this case an error should be thrown.
* The method is an intentionally-blank. In this case a nested comment should explain the reason for the blank method.
=== Noncompliant code example
[source,vb6]
----
Sub DoSomething()
End Sub
Function DoSomething() As String
End Function
----
=== Compliant solution
[source,vb6]
----
Sub DoSomething()
' Not implemented because of reason
End Sub
Function DoSomething() As String
DoSomething = "Value"
End Function
----
include::../why-dotnet.adoc[]
ifdef::env-github,rspecator-view[]

View File

@ -0,0 +1,8 @@
In this case, it is important to put a comment explaining the reason for the empty implementation.
[source,vbnet]
----
Sub DoSomething() ' Compliant
' Do nothing because of X
End Sub
----

View File

@ -0,0 +1,5 @@
[source,vbnet]
----
Sub DoSomething() ' Noncompliant
End Sub
----

View File

@ -0,0 +1,8 @@
By throwing the https://learn.microsoft.com/en-us/dotnet/api/system.notimplementedexception[`NotImplementedException`], the initial intention to add an implementation in the future is clear.
[source,vbnet]
----
Sub DoSomething() ' Compliant
Throw New NotImplementedException
End Sub
----

View File

@ -0,0 +1,8 @@
By throwing the https://learn.microsoft.com/en-us/dotnet/api/system.notsupportedexception[`NotSupportedException`], it makes clear the initial intention not to implement it in the future.
[source,vbnet]
----
Sub DoSomething() ' Compliant
Throw New NotSupportedException
End Sub
----

View File

@ -1,43 +1,20 @@
== Why is this an issue?
There are several reasons for a method not to have a method body:
:operationName: method
:emptyCode: vbnet/empty-code.adoc
:notsupportedCode: vbnet/notsupported-code.adoc
:notimplementedCode: vbnet/notimplemented-code.adoc
:commentCode: vbnet/comment-code.adoc
* It is an unintentional omission, and should be fixed.
* It is not yet, or never will be, supported. In this case a ``++NotSupportedException++`` should be thrown.
* The method is an intentionally-blank override. In this case a nested comment should explain the reason for the blank override.
=== Noncompliant code example
[source,vbnet]
----
Sub DoSomething()
End Sub
Function DoSomething() As String
End Function
----
=== Compliant solution
[source,vbnet]
----
Sub DoSomething()
' Not implemented because of reason
End Sub
Function DoSomething() As String
Throw New NotSupportedException
End Function
----
include::../why-dotnet.adoc[]
=== Exceptions
The following methods are ignored:
The following empty methods are considered compliant:
* empty ``++Overridable++`` or ``++MustOverride++`` methods,
* empty methods that override an ``++MustOverride++`` method,
* empty overrides in test assemblies.
* empty `Overridable` methods, as the implementation might not be required in the base class
* empty methods that override a `MustOverride` method as the implementation is mandatory for child class
* empty overrides in test assemblies for mocking purposes
ifdef::env-github,rspecator-view[]

View File

@ -0,0 +1,26 @@
An empty {operationName} is generally considered bad practice and can lead to confusion, readability, and maintenance issues.
Empty {operationName}s bring no functionality and are misleading to others as they might think the {operationName} implementation fulfills a specific and identified requirement.
Such {operationName}s should be avoided and possibly removed.
include::{emptyCode}[]
However, there are some cases where a {operationName} needs to be empty. In those cases, it is essential to minimize confusion and enhance clarity.
Here are a few examples:
* The {operationName} will never be implemented.
+
--
include::{notsupportedCode}[]
--
* The {operationName} will be implemented in the future.
+
--
include::{notimplementedCode}[]
--
* The {operationName} implementation is empty intentionally.
+
--
include::{commentCode}[]
--