• Guides
  • Videos
  • Publications
  • API
  • Github
  • Community
  • Release Notes
  • Plugins
Installing Origen
  • Introduction
  • How to Install
  • How to Install (Windows)
  • Company Customization
  • Understanding Gems
  • Invoking Considerations
  • Workspace Management
Getting Started with Origen
  • Core concepts
  • Creating a New App
  • Directory Structure
  • The Initial Commit
  • Creating New Files
  • Understanding Blocks
  • Application Architecture
Runtime Environment
  • Introduction
  • Mode
  • Environment
  • Target
  • Production Targets
  • Global Setup
  • Load Order
  • Programming
Models
  • Introduction
  • Naming
  • Definition & Hierarchy
  • Adding Attributes
  • Versioning
  • Bugs & Features
  • Package, Mode & Configuration
  • Registers
  • Pins
  • Power Domains
  • Hardware Attributes
  • Parameters
  • Specifications
  • Fuses
  • Generic Components
  • Creating Your Own Components
Compiler (Views)
  • Introduction
  • Creating Templates
  • Using Sub-Templates
  • Helpers
  • Running The Compiler
  • Inline Compiler
Controllers
  • Introduction
  • Shadow Controllers
  • Direct Controllers
Pattern Generator
  • Introduction
  • Creating Patterns
  • Pins
  • Timing and Waiting
  • Registers
  • Documenting Patterns
  • Generating by Name
  • Common API
  • J750 API
  • V93K API
  • UltraFlex API
  • STIL & Other Formats
  • Custom Testers
  • Running The PatGen
  • Concurrent Patterns
Test Program Generator
  • Introduction
  • Philosophy
  • Creating Flows
  • Managing Flow Control
  • Creating an Interface
  • Additional Resources
  • Dynamic Custom Code
  • Characterization API
  • J750 API
  • V93K Common API
  • V93K SMT7 API
  • V93K SMT8 API
  • UltraFLEX API
  • Documenting the Program
  • Creating Custom Testers
  • Running the ProgGen
Decompilation
  • Overview & Example
  • Decompiling, Adding Pins, & Executing
  • Working with Decompiled Patterns
  • Platform Specifics
Simulation
  • Introduction
  • How It Works
  • Compiling the DUT
  • AMS Support
  • Environment Setup
  • Application Setup
  • Simulating Patterns
  • Simulating Flows
  • Direct DUT Manipulation
  • Simulator Log Output
  • Artifacts
  • Debugging
Documentation Generator
  • Introduction
  • Markdown
  • Linking
  • Styling
  • Testing
  • API Generation
  • Deploying
Plugins
  • Introduction
  • Using a Plugin
  • Creating a Plugin
  • Current & Default Plugins
  • Dev Environment
  • Dev Considerations
  • Paths & Origen.root
  • Config & Origen.app
Miscellaneous
  • Revision Control
  • Origen Remotes
  • Lint Testing
  • Session Store
  • LSF API
  • Users, Emails & Maillists
  • Utilities & Helpers
  • Ruby Extensions
  • Logger
  • Adding Commands
  • Overriding Commands
  • Callbacks
  • Application Callbacks
  • Miscellaneous Topics
Advanced Topics
  • Introduction
  • Invocation Customization
  • Custom App Generators

Miscellaneous

Lint Testing


What is ‘Lint and Style Testing’?

Lint testing refers to looking for suspicious or unusual coding patterns which could be an indication of buggy or hard to maintain code.

Style checking refers to ensuring that the general coding style, for example the use of indentation, is consistent and follows generally accepted conventions.

Since Origen applications are typically developed and maintained by multiple engineers it is important to establish common coding practices so that code can be easily read and reasoned about by anyone involved in the project.

The Origen lint test uses a 3rd party tool to enforce the Ruby community maintained style guide. Best of all this tool can automatically correct many of the common style violations, including the (very common) inconsistent use of indentation.

By taking this approach individual preferences are taken out of the equation and adherence to the standards are no longer reliant on individuals remembering to use spaces instead of tabs (for example).

How to Run the Tests

Invoke the lint tests via the following command, by default this will run on the application’s lib directory:

origen lint

To run on individual files, or other directories:

origen lint pattern config/application.rb

To automatically correct violations where possible:

origen lint -c

Waivers for Legacy Applications

By default the tests will be fairly strict and will enforce most of the requirements of the Ruby style guide.

However many of the checks will involve some manual modification of the code to resolve them and for legacy applications with large code bases this is probably not worth the effort. In that case an easier set of tests can be run instead:

origen lint -e

The easier set will mainly limit the tests to those which can be corrected automatically, which still covers the most annoying issues such as inconsistent indentation and general code formatting problems.

However all new applications should use the strict tests and Origen core has already been made clean to the strict checks.

Setting Application Defaults

An application configuration option can be added to specify the default options that should be applied when the origen lint command is run without any arguments.

Here is the default value that will be present in all new Origen applications:

# config/application.rb

config.lint_test = {
  # Require the lint tests to pass before allowing a release to proceed
  run_on_tag: true,
  # Auto correct violations where possible whenever 'origen lint' is run
  auto_correct: true, 
  # Limit the testing for large legacy applications
  #level: :easy,
  # Run on these directories/files by default
  #files: ["lib", "config/application.rb"],
}

Pre-Release Validation

The lint test will be run automatically when a user tries to tag/release the application whenever the Origen.config.lint_test[:run_on_tag] attribute is set to true as shown above.

In such a case the user will not be allowed to release until the issues are resolved and this should be the approach taken by all new applications.


Comments

Generated with the Origen Semiconductor Developer's Kit

Origen is released under the terms of the MIT license