🎉 Benchmarking at repo root on my intel i7-9700 CPU

hyperfine "cpp-linter -l false -a false -j 1" "cpp-linter -l false -a false -j 0"
Benchmark 1: cpp-linter -l false -a false -j 1
  Time (mean ± σ):     51.437 s ±  2.264 s    [User: 25.653 s, System: 12.871 s]
  Range (min … max):   49.109 s … 54.378 s    10 runs

Benchmark 2: cpp-linter -l false -a false -j 0
  Time (mean ± σ):     26.391 s ±  0.498 s    [User: 26.286 s, System: 12.340 s]
  Range (min … max):   25.500 s … 27.063 s    10 runs

Summary
  cpp-linter -l false -a false -j 0 ran
    1.95 ± 0.09 times faster than cpp-linter -l false -a false -j 1

I'm also noticing that you don't use a word delimiter _ in your variable names (which should be snake-cased according to PEP8). This is throwing my spellchecker in a frenzy.

If you want to change some names, please locate the names so I could update them.

It is odd to request a refactor from the reviewer. Maybe I didn't describe what I wanted (in accordance with PEP8).

Thanks for the suggestions! I don't use a spell checker, so I just wanted to know the spell checker output of your environment.

I'm adding a pre-commit hook to run codespell in #93. I realized my request wasn't integrated into our CI checks. ruff is pretty relaxed about variable naming in a function's scope.

The actual spell checker that I'm using is a VSCode extension (not the codespell package).

I just finished variable renaming! No more force pushes.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (e33a5e6) to head (a4abbe3).
Report is 2 commits behind head on main.

@@            Coverage Diff            @@
##              main       #92   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           20        20           
  Lines         1392      1437   +45     
=========================================
+ Hits          1392      1437   +45     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I think there are some suspicious missing lines in the coverage report. I will investigate them first.

The "missing" lines are actually covered in tests (checked manually), but coverage could not track the changes. Are we ok to skip them or need some workarounds?

Well, I'm still puzzled why only the lines_changed_only arg isn't triggered in coverage.

I'd rather not skip the lines just to make coverage report "look" better. I prefer we actually have reproducible results to measure for code coverage.

I'll experiment for other methods to get coverage report correctly and share if any succeded. I think this looks like an upstream bug tho.

I'm seeing a lot of .coverage files created in the tests folder. When I run coverage combine, these tests/.coverage.* files are not combined into the report. I think one of the tests is changing coverage's working directory.

If I move all the rogue .coverage files into repo root and run coverage combine, then the output says it skips 146 "duplicate data"; only 6 .coverage files are actually combined.

This skipping "duplicate data" isn't a new thing, but spawning the coverage files in the tests folder is a new thing. I hesitate to call it a problem because I don't know the inner-workings of the coverage package.

None of this actually changed the overall code coverage reported.

Yes, I also just found out that the monkeypatch might cause problems for subprocesses. Fixed in 696d83c.

The rogue .coverage file are were spawned when running

• tests/capture_tools_output/test_database_path.py

Oh, ok. It seems the tests are not very pleased with out-of-order logs. I'll update them shortly.

I must say, you are picking up on the cause of these errors faster than I'm accustomed to. Its very refreshing!

@jnooree Thank you soooo much!❤️ I don't think I would've been able to solve #74 on my own.

I should thank you and the maintainers first for creating such a great package/workflow. Great work!