English | 中文简体

NI Programming Guide

This programming guidebook is used for development in Next-Innovation(NI).

The guidebook is designed by the rules below:

• Do not ignore readability in order to blindly pursue the speed of code.
• On the premise of speed , readability is everything.
• On the premise of readability, shorter is better.

Every developer should follow the rules while programming or pushing the code.

This guidebook contains:

1. Suggested VS-Code extensions.
2. The code style.

Table of Contents

• NI Programming Guide
  • 1. VS-Code-Extensions
  • 2. Code-Style
    • 2.1 Source-File
      • 2.1.1 License or copyright information
      • 2.1.2 Package statement
      • 2.1.3 Import statements
      • 2.1.4 Class
    • 2.2 Formatting
    • 2.3 Naming
      • 2.3.1 Rules common to all identifiers
      • 2.3.2 Rules by identifier type
        • 2.3.2.1 Package names
        • 2.3.2.2 Class & Interface names
        • 2.3.2.3 Method names
        • 2.3.2.4 Constant names
        • 2.3.2.5 Non-constant field names
        • 2.3.2.6 Local variable names
    • 2.4 Programming-Practices
  • Maintainers
  • Contributors

1. VS-Code-Extensions

• WPILIB
• Java Extension Pack
• Bracket Pair Colorizer 2
• google-java-format
• Todo Tree
• GitLens — Git supercharged
• Better-Comments

2. Code-Style

Note: To have a better support for 3rd lib, only file names is necessary to be formatted.

2.1 Source-File

• Structure:

  1. License or copyright information(if present).
  2. Package statement.
  3. Import statements.
  4. Class statements.

2.1.1 License or copyright information

• Example:

2.1.2 Package statement

• No line-wrapped.
• The package statement should be divided from import statements by a blank line.

2.1.3 Import statements

• Static import or otherwise are not used.

• No line-wrapped.

• Imports from the same package should be put together.

• Imports from different packages should be separated by a blank line.

• Example:

  Bad:

  

  Good:

  

2.1.4 Class

• The order of members does not need to follow specific strict rules. What is important is that each class uses some logical order.

• Overloads should never be split.

• Members of the same type should be put in the same block, and different blocks should be separated by annotation of a specific style.

• Example:

  Bad:

  

  Good:

  

2.2 Formatting

• NI's format style is following the Google's format style of Java. You can click here for more information: Google Java Style Guide - Formatting.
• In fact, all formatting can be done by the extension -- google-java-format.

2.3 Naming

2.3.1 Rules common to all identifiers

Identifiers use ASCII letters and digits only. On the premise of name readability, shorter is better.

2.3.2 Rules by identifier type

2.3.2.1 Package names

• lowercase

• Example:

  

2.3.2.2 Class & Interface names

• UpperCamelCase

• The name of a concrete class cannot have a prefix or suffix.

• The name of an abstract class should have a prefix of "base".

• The name of the interface should have a prefix of "I".

• Example:

  

2.3.2.3 Method names

• lowerCamelCase

• The name of the same type of method should start with the same word. For example, the subsystem of the chassis may have multiple setters to control the motors in different modes (Open-Loop, Velocity, Position), so their names should start with "set".

• Example:

  

  2.3.2.4 Constant names

• UPPER_AND_UNDER_SCORE_CASE

• Example:

  

2.3.2.5 Non-constant field names

• lowerCamelCase

• Whether the variable is public or private, do not add any prefix or suffix to it.

• Example:

  

2.3.2.6 Local variable names

• lower_and_under_score_case

• Example:

  

2.4 Programming-Practices

• Don't add unnecessary getter or setter.
• Always use @Override.
• Always use synchronized for all methods about IO.
• Do not ignore catching exceptions.
• Always specify the order of instantiation.

Maintainers

@Rocky_ @ljy1992

Contributors

❤️ This project exists thanks to all the people who contribute. ❤️

@ljy1992 @Rocky_ @yukikisss