Super streamlined Java-Scala programming specification

The coding standard explained by the big guys in the group , the fundamental purpose of the coding standard is to not only make the code clear at a glance, but also make it easy to understand the purpose and meaning of the code program written by the developer . As a result, it is used to reduce the difficulty and ambiguity in understanding the real function of the code due to the replacement of development and maintenance personnel or memory blur or confusion caused by long-term non-maintenance in the project. In addition, the efficiency and effectiveness of code review are also improved .

Good code is not a mountain of shit, it is something that everyone can understand and rewrite

Industry solutions:

Ali: https://github.com/alibaba/p3c
databricks：https://github.com/databricks/scala-style-guide/blob/master/README-ZH.md
google：https://github.com/zh-google-styleguide/zh-google-styleguide

Code that is easy to maintain or understandable to others, consisting of at least three parts

Naming conventions

code display style

code comment

1. Naming convention

in principle

The naming conforms to the characteristics of the language
Naming reflects the characteristics of code elements
Naming is best read from the text

specific methods

Do not start and end with an underscore or a dollar sign: must start with a letter, end with a letter and a number
Mixing Pinyin and English is strictly prohibited, let alone Chinese
Camel-Case naming: classes use big hump, variables and methods use small hump
The constant name must be capitalized, and the words should be separated by underscores, so as to ensure complete semantics and not be too long
Abstract classes must start with Abstract or Base, exception classes must end with Exception, and test classes must end with Test
Boolean in POJO class cannot be prefixed with is
Package names are uniformly lowercase, and can only be used in singular numbers. Package names should follow the naming convention of package names in Java, that is, use all lowercase ASCII letters.
Put an end to non-standard abbreviations: condition -> con ? connection?
When constants or variables are named, the word indicating the type is placed at the end to increase recognition: xxxList, xxxMap
Modules, interfaces, classes, and methods appear to use design patterns, and specific design patterns should appear when naming
The enumeration class is suffixed with enum, members are capitalized, and words are separated by underscores
Direct use of magic values (i.e. non-predefined constants) in code is not allowed

2. Code display style:

in principle:

Express the hierarchy and regularity of the code
Intuitive, fast and accurate understanding of business logic

specific methods

Indentation with spaces? tab? 2, 4, 8 spaces, two spaces are recommended
Spaces must be added to the left and right sides of the binary and ternary operators: val i = 1 + 1
There is only one space between the double slashes of the comment and the content of the comment // Comment text
There should be no spaces between the left and right parentheses and the adjacent characters inside the brackets: (aa, bb)
There must be a space before the opening brace
Leave a space after the comma. Seq("a", "b", "c") // use this way
Leave a space after the colon.
operator wraps with the following
The dot notation for method calls wraps with the following
When multiple parameters of a method call need to be wrapped, wrap after the comma
Do not break line before parentheses
Control statements: Braces must be used in if, else, for, while, do-while, etc., even if there is a line of code
Assignment operations are not allowed in conditional expressions, and complex (3 or more) logical combinations are not allowed in judgment expressions

3. Code comments:

in principle

write as much comment as possible

Less comments, good code can understand the content of the method according to the naming convention and naming

Modify the code and also modify the comments

style:

Documentation comments

Text Comments: Comments are "hints" to the code, not documentation

Class annotations must have,

Variable comments are commented after

Classes and methods are annotated above

add a class template

About closures

Avoid using return in closures
will be turned into an scala.runtime.NonLocalReturnControlexception try/catch, which may lead to unexpected behavior
Closures are not suitable for complex large-scale projects
Abstract and improve some tool classes

other

Avoid multi-argument lists
- case class Person(name: String, age: Int)(secret: String)
- Implicit has very complicated parsing rules, which can make the code extremely difficult to understand.
Do not use symbols as method names
- channel ! msg
- stream1 >>= stream2

General Mandatory Regulations:

Do not start and end with an underscore or a dollar sign: must start with a letter, end with a letter and a number
Mixing Pinyin and English is strictly prohibited, let alone Chinese
Camel-Case naming: classes use big hump, variables and methods use small hump
The constant name must be capitalized, and the words should be separated by underscores, so as to ensure complete semantics and not be too long
Abstract classes must start with Abstract or Base, exception classes must end with Exception, and test classes must end with Test
Boolean in POJO class cannot be prefixed with is
Package names are uniformly lowercase, and can only be used in singular numbers. Package names should follow the naming convention of package names in Java, that is, use all lowercase ASCII letters.
Spaces must be added to the left and right sides of the binary and ternary operators: val i = 1 + 1
There should be no spaces between the left and right parentheses and the adjacent characters inside the brackets: (aa, bb)
There must be a space before the opening brace
Leave a space after the comma. Seq("a", "b", "c") // use this way
Leave a space after the colon.
It is used to divide code fragments with similar functions, logical cohesion, and similar meaning to make the code layout clearer and try to bring related code blocks together.
operator wraps with the following
The dot notation for method calls wraps with the following
When multiple parameters of a method call need to be wrapped, wrap after the comma
Do not break line before parentheses
Try to avoid using negated logical operators
Method declarations should be parenthesized (even without parameter lists)
Assignment operations are not allowed in conditional expressions, and complex (3 or more) logical combinations are not allowed in judgment expressions
Variable comments are commented after
Classes and methods are annotated above

Thanks for sharing!