Back to the CLS project

A concrete example

LCE — Making code changes safer

Seeing a colleague manually replace literals with constants, without safeguards, prompted me to propose a tool to make the process safer. That initiative became LCE, the Literal Cleaning Environment, developed with a small team at IBM for critical interbank software. Tens of thousands of literals were involved.

How it worked

LCE analysed source files and marked literal occurrences. Developers chose meaningful symbolic names; the tool applied the replacements and generated the corresponding headers. Separating analysis from replacement allowed other developers to continue working between the two stages.

The workflow
The workflow. From source analysis and naming decisions to transformed code and generated headers.

Select any image to enlarge it. These original captures include masked source code and personal details.

From analysis to transformation

Generated header
Generated header. Collecting the constant definitions, including distinct names for different uses of the same value.
Configuration
Configuration. Setting include paths, headers, user-defined types and the categories of literals to process.

A method around the tool

The approach also defined how the team would work: module ownership, reviews by developers familiar with other modules, and three code reviews during the cleanup. Documentation covered requirements, internals, deployment, user guidance and known bugs.

Documentation
Documentation. The documentation set included known limitations alongside instructions for using, deploying and maintaining the tool.

Read the original presentation · PDF, 11 slides
Rationale, safeguards and deployment strategy.

The team

LCE 1.0.1
LCE 1.0.1. Team credits and original 2001–2003 copyright information.