-
Notifications
You must be signed in to change notification settings - Fork 1
Style Analysis: Java
Java is programmed in one main style: the Google Style. Many programmers tend to adhere to this style loosely, but incorporate elements of other styles. For most of the style elements discussed, this program will check whether it adheres to Google Style or not. In the case of curly braces, there are a few other styles that will be checked for as well. It is important to note that this program works only for runnable Java code.
| Classes | Constants | Variables | Methods | Control Statements | Import Statements | Files | Package declarations | |
|---|---|---|---|---|---|---|---|---|
| Naming | x | x | x | x | x | |||
| Indentation | x | x | x | |||||
| Tabs vs. spaces | x | x | x | x | x | |||
| Line length | x | x | x | x | x | |||
| Blank lines | x | |||||||
| Imports | x | |||||||
| File encoding | x | |||||||
| Curly Braces | x | x |
Naming will be evaluated on whether it is in accordance with Google style or not. Due to the fact that it is hard to distinguish between actual words in a name programmatically, if a class, local variable, or a method only contain alpha-numeric characters, they will be classified as Google style.
If a variable is not named in the Google style, this will count as an error for the naming category analysis.
The Google style guide says that classes should be named UpperCamelCase, and local variables and methods should be named with lowerCamelCase. Due to the restriction mentioned above, class names will be considered compliant if they start with a capital letter and contain only alphanumeric characters. Local variables and methods will be considered compliant if they begin with a lowercase letter and only contain alphanumeric characters.
Google style says that package declarations should only contain lowercase letters and consecutive words should beaeen.
Constants have the modifiers static final. Google style says to name them with CAPITAL_SNAKE_CASE. Constants will be considered compliant if they only contain uppercase letters. Because there are instances where a constant name has only one word, the presence of underscores will not be taken into account.
Indentation will also be evaluated on whether it is compliant with the Google Style Guide or not. Google says that an indent is 2 spaces, and does not allow for the usage of tab characters.
If indentation does not follow the Google Style Guide, then it will count as an error for the indentation category analysis.
Many programmers prefer to use tab characters instead of spaces to be more efficient and reduce file sizes, and some use both. Each line of code that is not an import or a package declaration will be parsed to see whether the file uses spaces for indents, tab characters, or both.
The Google Style Guide provides no official guidelines regarding the use of tablets vs spaces. The standard recommendation is to have 2 or 4 space width tabs.
The Google style guide says that lines of code must be under 100 characters long. Import statements and package declarations have no length limit. The number of lines that are over 100 characters will be counted and reported as a line length category error.
In the Google Style Guide, the usage of blank lines is less regulated and left for stylistic choice. Metrics collected for this section will focus on how often extra blank lines are used.
The Google Style Guide says to have one blank line in between class members and methods. It is important to note that the absence of a blank line in between multiple fields is allowed and sometimes even encouraged. Therefore, the program will check for one blank line in between the last of the fields and the first method, and in between the methods.
The Google Style Guide does not allow for multiple import statements in one line, using the wildcard (*). Therefore, the program checks for the usage of wildcards.
The Google Style Guide says that all source files should be encoded in UTF-8. Therefore, the program check the encoding of the source files to ensure the proper encoding is used.
This module counts several important LOC Metrics: LOCSingleComments (//), LOCMultComments (/**/), LOCTotalComments (LOCSingleComments + LOCMultComments), LOCBlankLines, and LOCSourceCode (After you remove comments from a line, if not a blank line, then it counts as source). If there are any questions, refer to how this example file would be counted:
/*
multline comment
//ignored single comment
*/
String s = 'testing' /* multiline comment right of code */
/* multiline comment left of code */ String s = 'testing'
String /* multiline comment middle of code */ s = 'testing'
String s = ' /* ignore multiline comment in string */ testing'
// Single comment
String s = 'testing' // single comment next to code
String s = ' //ignore single comment in string '
"A bit of code" /* mixed with */ //everything
Expected: LOCSourceCode: 8, LOCSingleComments: 2, LOCMultComments: 8, LOCTotalComments: 10, LOCBlankLines: 4, LOCTotalLines: 17
In regards to curly braces, Google style often incorporates a lot of the general K & R (Kernighan & Ritchie) style that is applicable to C. However, there are some attributes exclusive to K & R, which will be identified as "EX_KR_style". Blocks inside of methods are grouped into two styles: "single" and "multiple". Single blocks denote blocks that are created by either a for loop, a while loop, or a do-while loop. They will not have an immediate block afterwards associated with it. Multiple blocks are try/catch/finally blocks and if/else if/else blocks. These types of blocks typically have one or more following blocks that correspond with the first block. In the case of the if block, even if there are no blocks following it, it is still considered a multiple block.
For "single" blocks, that don't have an immediate block after, there are 3 styles:
- Exclusive K & R --
- When there is one line in the block, and no braces before and after the line.
- Google --
- when there is one line in the block, and braces before and after the line.
- when there are multiple lines in the block, and opening brace is same-line, closing brace is on the line after the last statement in the block.
- Allman --
- No matter how many lines the block is, the opening brace is on a new line by itself, and the closing brace is on the line after the last statement in the block.
For "multiple" blocks, that have an immediate block after:
- Exclusive K & R --
- When each block is comprised of a single line, and does not use braces.
- Google --
- Despite whether each separate block is one or more lines, there are always braces--the opening brace is on the same line as the control statement, and the closing brace will be on the line after the last statement in the block.
- A following block statement will not use a separating line break after the closing brace from the previous block.
- Allman --
- No matter how many lines the block is, the opening brace is on a new line by itself, and the closing brace is on the line after the last statement in the block.
Any style that does not match these patterns will be considered a "weird" style. For analysis purposes, any curly brace style not matching the "Google" style will be counted as an error.