51369b610e
When an include is not surrounded by empty lines, its content is inlined on the same line as the adjacent content. That can lead to broken tags and other display issues. This PR fixes all such includes and introduces a validation step that forbids introducing the same problem again.
40 lines
927 B
Plaintext
40 lines
927 B
Plaintext
== Why is this an issue?
|
|
|
|
Shared naming conventions allow teams to collaborate efficiently.
|
|
|
|
This rule raises an issue when a struct name does not match a provided regular expression.
|
|
|
|
The convention in Go is to use mixedCaps rather than underscores. See https://golang.org/doc/effective_go.html#names[Go documentation] for the complete naming conventions.
|
|
|
|
Note that the casing of the first character determines if the type is exported or not.
|
|
|
|
For example, with the default provided regular expression ``++^[a-zA-Z][a-zA-Z0-9]*$++``, the struct:
|
|
|
|
[source,go]
|
|
----
|
|
type my_struct struct {...}
|
|
----
|
|
|
|
should be renamed
|
|
|
|
[source,go]
|
|
----
|
|
type myStruct struct {...}
|
|
----
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
include::../message.adoc[]
|
|
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
include::../comments-and-links.adoc[]
|
|
|
|
endif::env-github,rspecator-view[]
|