Sema scans code with popular, actively developed linters for thousands of possible warnings. We group the outputs into language-agnostic categories to help understand and prioritize lint and it's impact across codebases and organizations. Every occurance of a warning appears at a line in a file.



Tools in use

Warning Categories

Security

Items which are known security flaws, which may allow various exploits at varying severity levels.


Action Fix high severity issues with priority.


Severity Varies per warning and application. Code used internally, which doesn’t handle external user data might make these less of a priority


Examples

  • Use of “eval” or “exec” - a classic, high severity security issue where an external user can submit arbitrary code via a web interface and have the server execute this code. This could allow anyone to submit code which accesses the database and sends info back to the attacker.
  • “The user-supplied array 'lines' is stored directly.”
  • “eval can be harmful.”    

Potential Bug

Issues which may affect functionality in some circumstances. They are at the very least misleading to developers and so should be fixed as they pose a high risk that they either currently affect functionality or may mislead developers in such a way as to introduce bugs in the future.


Action Fix now


Severity High


Examples

  • “Expected an assignment or function call and instead saw an expression.”
  • “Invoke equals() on the object you've already ensured is not null”
  • “Use equals() to compare strings instead of '==' or '!='“


Misleading

Issues that may mislead developers in such a way as to introduce bugs in the future.


Action Fix if you care about readability or extendibility of your codebase.


Severity Medium


Examples

  • Multiple conditions in an if statement (if this and that or the other and not such-and-such) can be confusing to a developer. Changing this code is risky.
  • “A method should have only one exit point, and that should be the last statement in the method”
  • “Use equals() to compare object references.”
  • “Avoid unused imports such as 'java.net'“


Performance

Issues which result in less efficient code.


Action Fix if performance is important or a known issue in the application


Severity Low-High


Examples

  • Deeply nested loops are sensitive to data size, execution may grow exponentially with larger data. Deeply nested loops may contain opportunities for reducing the number of iterations needed. Multiple calls to the same method may recalculate data multiple times, opportunity here to cache results and skip recalculating.
  • “StringBuffers can grow quite a lot, and so may become a source of memory leak (if the owning class has a long life time).”
  • “System.arraycopy is more efficient”

Smell

Code structure that is abnormal, such as a large or overly complex method or class.


Action Fix if readability is important.


Severity Low


Examples

  • “Potential violation of Law of Demeter (method chain calls)”
  • “A high number of imports can indicate a high degree of coupling within an object.”
  • “High amount of different objects as members denotes a high coupling”

Stylistic

Code structure that is abnormal at the line level. e.g. brackets on same line as for statement, instead of on the next line. This category has no bearing on performance generally.


Action Fix if style is important


Severity Low


Examples

  • “Parameter 'category' is not assigned and could be declared final”
  • “Field comments are required”
  • “Comments are too large: line too long”

Environment Sensitive

Warnings that are relevant depending on whether strict mode is turned on or not. Issues that may affect functionality in the future. As the underlying platform evolves, the use of deprecated features may be risky, given that they may disappear in the future. 


Action Check in context of how the code is deployed. No real fix in the code necessary. Fix if the underlying libraries are being updated. It’s mostly an operation issue for the developers. 

Severity Low-High, depending on deployment context 


Examples

  • "Unit tests should not contain more than 1 assert(s)."
  • "If you run in Java5 or newer and have concurrent access, you should use the ConcurrentHashMap implementation"
  • "Consider replacing this Hashtable with the newer java.util.Map"