Skip to content

racodond/sonar-jproperties-plugin

master
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Code

Latest commit

 

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
its
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Release Build Status AppVeyor Build Status

Quality Gate status Lines of code Coverage

SonarQube Java Properties Analyzer

Disclaimer

I don't want to keep maintaining this plugin. Feel free to ping me if you want to take over.

Description

This SonarQube plugin analyzes Java Properties files and:

  • Computes metrics: lines of code, comments lines, etc.
  • Checks various guidelines to find out potential bugs, vulnerabilities and code smells through more than 30 checks
  • Provides the ability to write your own checks

Usage

  1. Download and install SonarQube
  2. Download and install the Java Properties plugin. The latest version is compatible with SonarQube 6.7+
  3. Install your favorite scanner (SonarQube Scanner, Maven, Ant, etc.)
  4. Analyze your code.

Custom Checks

You're thinking of new valuable rules? Version 2.1 or greater provides an API to write your own custom checks. A sample plugin with detailed explanations is available here. If your custom rules may benefit the community, feel free to create a pull request in order to make the rule available in the Java Properties plugin.

You're thinking of new rules that may benefit the community but don't have the time or the skills to write them? Feel free to create an issue for your rules to be taken under consideration.

Available Rules

  • "FIXME" tags should be handled
  • "TODO" tags should be handled
  • All comments should be formatted consistently
  • All properties and comments should start at column 1
  • Byte Order Mark (BOM) should not be used for UTF-8 files
  • Credentials should not be hard-coded
  • Different keys having the same value should be merged
  • Duplicated keys across files should be removed
  • Duplicated keys should be removed
  • End-line characters should be consistent
  • File names should comply with a naming convention
  • Files not defining any properties should be removed
  • Files should contain an empty new line at the end
  • Keys should follow a naming convention
  • Lines should not be too long
  • Missing translations should be added to default resource bundle
  • Missing translations should be added to locale resource bundles
  • Number of keys should be reduced
  • Property with empty value should be removed
  • Regular expression on comment
  • Regular expression on key
  • Regular expression on value
  • Sections of code should not be commented out
  • Separators should follow a convention
  • Tabulation characters should not be used