GreenCode
Scientific Method

The GreenCode Method: transparency first.

GreenCode doesn't make up grades. It translates computational patterns into verifiable metrics, combining static scoring and dynamic profiling to estimate energy and carbon impact.

Energy Score (Statico)

Proxy Metrics e classi energetiche da A a G

The static phase analyzes code with AST rules and weights each anti-pattern by its potential impact on CPU, memory and battery, especially in mobile scenarios. Examples: N+1 queries in loops, redundant API/LLM calls, heavy frontend dependencies, inefficient React rendering.

Computing the score

Each finding lowers the score with a penalty proportional to the estimated energy severity. The final score is mapped to an A-G class to make the energy risk immediately readable.

Interpretazione

A low class is not an aesthetic judgment: it indicates a higher probability of computational waste, more battery use and higher cloud costs in production.

Static analysis commands

  • ecocode analyze: local AST parsing on JS/TS/React with energy findings and A-G score.
  • ecocode analyze --max-files N: limits the analysis scope.
  • ecocode analyze --host URL: sends report metadata to a specific dashboard endpoint.
Software Physics (Dynamic)

From CPU time to Joules, Watts and CO2

The CLI command ecocode profile <file>runs the file locally and measures user/system CPU time with native Node.js modules. For more representative analysis on real repositories, ecocode profile-projectruns multiple scenarios from config, repeats the benchmarks and produces a weighted average. From these measurements we estimate energy in mWh with the model:

Energia_mWh = (CPU_Time_ms * Standard_CPU_Wattage) / 3600
CO2_g = (Energia_mWh / 1_000_000) * Carbon_Intensity_gCO2e_per_kWh

This is an engineering estimate, not a lab measurement. Still, it follows computational efficiency logic consistent with the principles promoted by the Green Software Foundation: use observable data, state assumptions explicitly, and optimize where real consumption is demonstrable.

Dynamic scenario config (project)

{
  "repeat": 3,
  "scenarios": [
    { "name": "API startup", "file": "./dist/server.js", "weight": 3 },
    { "name": "Batch nightly", "file": "./dist/jobs/nightly.js", "weight": 1 }
  ]
}

This way GreenCode combines global static analysis with dynamic benchmarks of real flows, reducing the risk of metrics disconnected from production.

Single File Profiling

  1. Build the project if the target is TypeScript: npm run build
  2. Run: npx ecocode@latest profile ./dist/index.js
  3. Compare CPU/mWh/gCO2e before and after a change.

Scenario Project Profiling

  1. Create the config file: ecocode.profile.json
  2. Run: npx ecocode@latest profile-project --config ./ecocode.profile.json --repeat 3
  3. Use the weighted average as the repository's energy baseline.

GreenCode functional coverage

  • Static analysis: detects energy anti-patterns and generates an A-G Energy Score.
  • Profiling file: measures real CPU consumption on a script/entrypoint.
  • Project profiling: aggregates multiple real scenarios with weights and repeated runs.
  • Report dashboard: visualizes energy KPIs and optimization priorities.