Code quality

Code quality, and what a low score actually predicts

This is the one category where a poor score rarely loses you a customer on its own. What it tells you is how expensive your website will be to change.

What you are really buying information about

A website can be built out of tangled markup and still sell perfectly well. Nobody visiting your site reads the HTML. What untidy code changes is the price of every future change to the site: a new page, a colour change, a payment provider swap. Work that should take an hour takes a day, because the person doing it has to find every place the same thing was written out again by hand.

The engine treats the category with that weight and no more. In the overall score, Code Quality carries a weight of 0.7, against 1.4 for Performance, SEO and Security. In the ranking that decides which findings open the report, HTML validation, source maps and deprecated markup are filed under the class the code labels "worth tidying, but nobody loses a sale over it", weighted 0.7 — the lowest class there is. Nothing in this category is written up as an emergency, because none of it is one.

The validation is done by the W3C, not by us

The page your server sent is posted to the W3C Nu Html Checker's public API, and the messages it returns are read back. Errors and warnings are separated: ten errors or fewer is reported as a warning, more than ten as critical. The report carries a sample of the first eight errors, each trimmed to 120 characters, so you can see what kind of mistake it is rather than a bare number. Warnings are counted and shown, but they carry no score.

There is no home-grown list of deprecated tags in this engine. Obsolete elements reach your report through the validator's own messages, alongside unclosed tags, duplicate ids and attributes that do not belong where they are. The request has a 25-second timeout. If the validator cannot be reached, the result is recorded as not validated, with the reason, and no finding is raised. A check that failed to run is a fact about our connection, not a defect on your site.

The time this check was wrong about our own site

The library this engine uses to fetch pages follows an old rule from RFC 2616: when a server sends text without naming its character set, assume Latin-1. No browser has behaved that way for years, but the fetcher did. A site serving UTF-8 without declaring it in the HTTP header — common on older shared hosting, which describes a lot of who we audit — therefore arrived garbled. Every em dash became three stray control characters, and the validator dutifully reported one "Forbidden code point" error for each.

Measured on this project's own website, which is valid UTF-8 and contains sixteen em dashes: 32 validation errors that did not exist, a critical finding, and a Code Quality score of 75 for a document with nothing wrong with it. After the fix, zero errors and 100. Nothing about the failure looked like a failure — the page parsed, every other check ran. Decoding now follows the order the HTML standard sets out: an explicit header charset first, then the document's own meta charset, then UTF-8.

Inline styles, semantics and leftovers from the build

Inline style attributes are counted; more than 30 on a page raises an informational finding. The cost is not to visitors, it is to whoever changes the site next: a colour or spacing change has to be hunted through every tag it was written into. Inline script blocks are counted and recorded but never scored. Semantic elements are checked separately — header, nav, main, article, section, aside, footer, figure, figcaption, time and mark — and fewer than three types in use is a warning, because that structure is also what screen readers and crawlers navigate by.

Source maps are the other common leftover. A sourceMappingURL comment, or a reference to a .js.map file, means your original uncompiled source is being published alongside the site. It is informational, not critical. Our own audit of this website, published in full, scored Code Quality 95 on a single finding: 125 inline style attributes. It is true, it stands, and it is exactly the kind of finding this category is for.

What sits outside this category, and what nobody can see

Two things people expect to find here are checked elsewhere and weighted very differently. JavaScript errors are collected from a real browser under Functional, as a warning, and in the impact ranking they sit at 2.4 as something that stops a visitor completing what the page exists for — not 0.7 — because an error thrown during load stops later scripts running, which is how a submit button silently stops working. Errors caused by our own machine's tracker blocking are excluded: before that fix, one client was told their site had 87 failed requests and 51 JavaScript errors when it had approximately none. Page weight belongs to Performance, measured on the HTML document: over 500 KB is informational, over 1 MB a warning, over 2 MB critical.

Six things cannot be established from outside a website at all: linting in CI, tracked technical debt, dependency updates, documentation, test coverage and git hygiene. They appear in the report under "Not assessed remotely" and carry no score. They used to be emitted as findings on every single site, regardless of the code, which cost a flat 12 points and capped this category at 88 for a site with nothing wrong with it — and padded the issue count printed on the front of the report. Not looking at something is not the same as finding something.

What the engine checks here

Each of these is a rule in the code, not a category heading.

HTML validation, via the W3C Nu Html CheckerYour page is posted to the public validator API and its messages read back. Ten errors or fewer is a warning; more than ten is critical. The first eight errors are quoted, each trimmed to 120 characters. Warnings and informational messages are counted and shown but carry no score.
Deprecated and obsolete markupNo separate rule and no list of our own. Obsolete elements are reported by the validator itself, so they arrive inside the error count rather than as a category of their own. In the impact ranking, deprecated markup is classed as tidying work at weight 0.7.
Semantic structureEleven element types are looked for: header, nav, main, article, section, aside, footer, figure, figcaption, time and mark. Fewer than three types in use raises a warning, because that structure is what assistive technology and crawlers use to navigate the page.
Inline style attributesCounted across the whole document. More than 30 raises an informational finding, with the fix being to move them into a stylesheet. Inline script blocks — script tags with no src — are counted and reported as well, but deliberately carry no score.
Exposed source mapsA sourceMappingURL comment or a .js.map reference in the page means the original, uncompiled source is being served publicly from a production build. Reported as informational.
Correct decoding before anything is judgedThe page is decoded the way a browser would: header charset first, then the document's own meta charset, then UTF-8. Latin-1 is never assumed. Getting this wrong produced 32 validation errors on a clean document, and it is now locked by tests.
Runtime JavaScript errors (Functional, not here)Collected from a real Chromium session. Reported as a warning, and ranked at 2.4 as blocking the action the page exists for. Errors caused by tracker blocking on the auditing machine are excluded, so the count does not change depending on whose network the audit ran from.
Page weight (Performance, not here)Measured on the HTML document itself: over 500 KB informational, over 1 MB a warning, over 2 MB critical. Total transfer weight and request count are measured separately from the rendered browser session and feed the Performance category.

Questions

Our code quality score is low. Do we need a rebuild?

Almost certainly not, and the report is weighted so that it never argues for one. This category carries 0.7 in the overall score, and its findings are ranked in the lowest impact class. Treat a low score as a cost estimate rather than a fault: it says the next change to the site will take longer than it should. If nothing needs changing, it costs you nothing.

Do you look at our source code or our repository?

No. Everything here is read from the page your server sends to any visitor. Linting, technical debt, dependency updates, documentation, test coverage and git hygiene are listed in the report under "Not assessed remotely" precisely because they cannot be seen from outside, and they are not counted against your score.

The validator did not run on our audit. Is that a fail?

No. The result is recorded as not validated, with the reason given, and no finding is raised. The request has a 25-second timeout and the W3C service is sometimes unavailable. Reporting an unreachable check as an error is how free scanners produce long red lists that mean nothing.

Sources

Public and checkable. Nothing here rests on a number we cannot point at.

This is one of fifteen categories. You can read a real report this engine produced on this very site — including the findings it raised against us — or ask for an audit of yours.