CoDiver routes uploaded source files to AST engines and sprint analytics

One upload, three kinds of analysis

CoDiver is aimed at people who already know their codebase needs measuring but do not want to run a separate tool per language. The project presents itself as a unified platform for code quality, architectural metrics and Agile analytics, and the interface reflects that ambition: a single drag-and-drop ingestion point accepts Python files, Java files and JSON, and the application decides what to do with each. The audience is a developer or team lead who wants complexity numbers and smell findings next to sprint velocity rather than in three separate reports. The philosophy section frames the goal in terms of technical debt being made visible and actionable rather than abstract, and it explicitly claims to remove the borders between languages so the focus stays on the code. The project was previously called SMC-Software-Metrics-Calculator, and the rename is still only partly complete in the packaging metadata, which matters for anyone wiring it into a build.

The control center routes by file extension

The architecture is described as zero-coupling and event-reactive, and the diagram shows how that works in practice. A Streamlit frontend sends every uploaded file to a Universal Control Center, which routes .py files to a Python AST engine, .java files to a Java AST engine, and .json files to an Agile process engine. Each engine produces its own results, and a single aggregator collects them before the data is handed back to the frontend as Pandas DataFrames and rendered as Plotly visuals. The request lifecycle is worth reading closely, because it explains why the app feels instant. The interface stays stateless until the user explicitly executes an analysis, and only then does the backend dispatch raw UTF-8 strings along with configuration. The engines generate abstract syntax trees, traverse classes, fields and methods, and evaluate smells and constraints, then yield structured dictionaries into session state. Transformation into DataFrames and the reactive re-render both happen after that, so a large upload costs nothing until you press the button.

The Python engine measures complexity, defects and effort

The Python side is the part with the most familiar metrics. It relies on the standard library ast module and on radon, and its listed responsibilities are AST generation, cyclomatic and cognitive complexity mapping, defect density prediction and COCOMO estimation. The distinction between cyclomatic and cognitive complexity matters for anyone reading the output, because radon computes both and they answer different questions: one counts paths through a function, the other estimates how hard the code is to understand. Defect density prediction and COCOMO sit on top of the size numbers, which means the dashboard is doing estimation work rather than only reporting raw counts. The tree confirms the layout, with the calculation algorithms kept in src/software_metrics/calculators/ and the chart and card components in src/software_metrics/ui/, and a tests/ subdirectory inside the subsystem for validation. The tradeoff is that these are model-based estimates, and the dashboard presents them in the same visual language as measured complexity, so a reader has to know which numbers come from the parser and which come from a formula.

The Java engine reports design smells, not just style

Java support runs on javalang and covers what the project calls static architecture analysis. The listed detectors are God Class detection, Feature Envy identification, naming convention checks, Javadoc validation and raw line-of-code distributions. God Class and Feature Envy are both object oriented design smells rather than formatting issues, which means the engine is judging structure and responsibility distribution, not whether a team follows a style guide. Javadoc validation is a different category again, closer to a documentation audit, and the raw LOC figures feed the size side of the analysis. The implementation lives in src/java_analyzer/, with the tree walk in analyzer_engine.py, the smell logic split into a detectors/ directory, session state and execution handlers in dashboard.py, and UI helpers in utils/. The interesting engineering choice is that this engine is a separate subsystem with its own dashboard module, mirroring the Python side rather than sharing one analysis layer, so cross-language correlation happens in the aggregator and not in the parsers.

Sprint JSON becomes velocity and scope creep charts

The third route takes .json files to the Agile process engine, which works in pandas and plotly rather than on a syntax tree. Its listed responsibilities are velocity tracking, sprint burndown visualization and scope creep calculation. The practical implication is that a sprint export in JSON is enough to populate the charts, so the Agile view needs no repository access and no issue tracker connection. That makes CoDiver usable in a planning meeting with a file export on a laptop, which is a different operating mode from the code analysis features that require a folder of source. Velocity and burndown sit side by side because the burndown is what tells you whether a committed velocity was real, and scope creep is computed by comparing planned and delivered work across sprints. The limit is that the JSON schema the engine expects is not documented in the README, so a first time user has to discover the expected shape by trial rather than by reading a schema file.

Local development and the Streamlit Cloud path

The README gives a short local workflow, and every command in it can be copied as it stands. The clone URL in the snippet is a placeholder that you replace with your own fork:

# 1. Clone the repository
git clone https://github.com/yourusername/CoDiver.git
cd CoDiver

# 2. Install AST parsers and UI dependencies
pip install -r requirements.txt

# 3. Boot the reactive frontend server
streamlit run app.py

The dependency set is small and the parser is the piece to watch. requirements.txt carries the four dashboard libraries and one parser:

streamlit>=1.30.0
pandas>=2.0.0
plotly>=5.18.0
numpy>=1.24.0
javalang>=0.13.0

Javalang is the only dependency that parses a language, and it is absent from the pyproject dependencies list, which means a pip install of the packaged project would lose the Java engine while the raw requirements file keeps it. For hosted use, the project points at Streamlit Community Cloud: fork the repository, connect the fork through share.streamlit.io, point the main file path at app.py and let the cloud environment parse requirements.txt. The live instance sits at codiver.streamlit.app, and the README notes that the application cannot be served statically through GitHub Pages because the backend does the AST work.

The package metadata still answers to the old name

The most concrete rough edge is naming. The README says the project was previously known as SMC-Software-Metrics-Calculator, and that is still what the build configuration calls it. The distribution name in pyproject.toml is software-metrics-calculator, the version field reads 1.0.0 while the README badge advertises version 4.1, and both project URLs point at the Software-Metrics-Calculator repository path. The packaging section is otherwise conventional:

[project]
name = "software-metrics-calculator"
version = "1.0.0"

The dependency block that follows lists the four dashboard libraries and nothing else:

dependencies = [
    "streamlit>=1.30.0",
    "pandas>=2.0.0",
    "plotly>=5.18.0",
    "numpy>=1.24.0",
]

The same file restricts package discovery to the src directory and includes only the software_metrics* and java_analyzer* packages, which is consistent with the tree but means a third party module cannot be added without editing it. There is also a .pre-commit-config.yaml and a CHANGELOG.md at the top level, so the project has the habits of a maintained tool, yet no GitHub releases are published and the last push was on 2026-06-30. Expect to read the source for anything the README leaves out, including the JSON schema the Agile engine expects.

Editorial conclusion

CoDiver suits a team that wants a single browser surface for code metrics, Java smell detection and sprint reporting without writing a scraper for each, and it suits a student learning how AST driven metrics work. It does not suit a monorepo pipeline, since analysis is a manual upload with no command line entry point documented, and it does not suit anyone who needs a reproducible release, because the repository publishes no GitHub releases and the last push was on 2026-06-30. Before adopting it, check that the pyproject metadata naming mismatch does not break your packaging, run pip install -r requirements.txt on a clean environment to confirm the javalang parser still installs, and confirm the dashboard on codiver.streamlit.app matches the metrics your team already trusts.

Frequently asked questions

Official sources

1. AhmadHassan-BTed/CoDiver on GitHub
2. Issues
3. License: MIT
4. Project website
5. README