Inappropriate Source Code Style or Formatting

Incomplete Class
Structure: Simple
Description

This weakness occurs when source code violates established style guidelines for formatting, indentation, whitespace, or commenting, making it difficult to read and maintain.

Extended Description

While inconsistent formatting doesn't directly cause security vulnerabilities, it creates a breeding ground for them. Poorly structured code is harder to review, making subtle logic flaws, missing security checks, or unintended behaviors much easier to miss during manual inspection or automated analysis. This readability deficit directly undermines the team's ability to identify and fix critical security issues before deployment. Addressing this requires integrating automated style checkers and formatters into the development workflow. Tools like linters and code formatters enforce consistency automatically, ensuring the codebase remains clean and reviewable. This proactive practice reduces cognitive load for developers, accelerates code reviews, and significantly improves the team's overall capacity to spot and remediate genuine security defects hidden within complex logic.

Demonstrative Examples 1

ID : DX-215

The usage of symbolic names instead of hard-coded constants is preferred.
The following is an example of using a hard-coded constant instead of a symbolic name.

Code Example:

Bad
C
c
If the buffer value needs to be changed, then it has to be altered in more than one place. If the developer forgets or does not find all occurrences, in this example it could lead to a buffer overflow.

Code Example:

Good
C
c
In this example the developer will only need to change one value and all references to the buffer size are updated, as a symbolic name is used instead of a hard-coded constant.