Composition and sizing

Why CAST Profiler reports two file counts and two size figures, how source lines are counted, and how files are classified

Overview

The composition panel is the part of the results most often quoted into a scoping document, and the part most often quoted wrongly. CAST Profiler deliberately reports the volume of an application twice, because “how much source code is there” and “how much of it will CAST Imaging analyze” are different questions with different answers.

The two file counts

Count	What it includes
Total files found	Every file collected during the scan, whatever its content, including binaries, images, archives and documentation
Files to be considered	Only the files whose language CAST Imaging analyzes

The first number describes the delivery you were given. The second describes the analysis you are about to scope. A large gap between the two is normal for a repository that carries binaries, vendored assets or generated documentation, and is worth investigating when it is not.

Neither count includes files inside the folders CAST Profiler skips automatically, and those files are not reported anywhere. See folders excluded automatically before you reconcile these figures against a git ls-files count.

The two size figures

The same split applies to volume:

Figure	What it measures
Total lines found	The total line count of every scanned file, whatever its content
Source lines to be considered	That count restricted to the files whose language CAST Imaging analyzes

Binary files are sized in bytes and appear in the inventory, but they contribute no lines to either figure.

How lines are counted

Line counting is lexical, not syntactic. CAST Profiler does not parse the code, so the figures are cheap to produce and are not identical to what a language-aware counter would report:

Every language gets a plain line count.
For the 270 languages with a comment syntax in the reference data, that count is broken down into code, comment and blank lines, carried in the result file as nbLocs, nbCommentLocs and nbBlankLocs alongside nbBytes and nbFiles. The results page labels these Source lines, Lines of comments and Lines of blanks.
A language without a breakdown reports its total lines only.

Source lines names two different figures. The one in the page header is the application-level total described above. The per-language column of the same name is nbLocs, which counts code lines only: the comment and blank lines of that language are reported separately and are not included in it. The product FAQ refers to this second figure as “Lines of Code”.

nbNonUTF8Files counts files that could not be decoded as UTF-8. A non-zero value there usually means an EBCDIC or legacy single-byte encoding in the delivery, and the line figures for those files are unreliable.

File classification

Every language in the reference data carries a classification, and each file inherits the classification of its language. There are eight:

Code	Label	What it covers
`project`	Project	Project configuration
`programming`	Programming	Regular source code with programming statements
`markup`	Markup	Regular source code with markup tags
`data`	Data	Data storage
`sensitive`	Sensitive	Sensitive, private or confidential information that should not be disclosed: passwords, keys, personal information
`prose`	Prose	Text, notices, documentation
`resource`	Resource	Miscellaneous extra files
`none`	None	Unclassified

The classification decides which side of the two counts a file falls on. A pom.xml is project, not programming, so it appears in the total file count and not in the files-to-be-considered count - while still being one of the most informative files in the scan, because it is where the declared dependencies come from.

Classification follows the language, not the content, so it is only as precise as the extension-to-language mapping behind it. A .sql file is programming whether it defines a schema or holds nothing but INSERT statements, which is why the alerts inspect content separately.

The type and kind values written into the result file by CLI 2.0.3 do not cover all eight codes. project, programming, markup, data and prose appear as listed. In place of resource and none the file carries unclassified, and it uses a further value, unknown, for a file whose extension matches nothing in the reference data. A .env file holding passwords and API keys was classified data, not sensitive. Read a result file against the values it actually contains rather than assuming a one-to-one match with this table - see Result files.

Reading the per-language breakdown

Each language entry in the composition carries a density, which is its share of the scanned files, and a supported or supportLevel value. Sort by density to find the languages that dominate the delivery, then check the support level of each one before you commit to a scope. A language with high density and no CAST Imaging support is the single most important thing a CAST Profiler scan can tell you, and it is covered under technology tree and support levels.

Size buckets shown on the results page (S, M, L, XL, XXL, XXXL) are a coarse label derived from the total volume. Use the underlying figures rather than the bucket in any document that matters.