So it’s basically similar to .onion on Tor Browser, but without requiring a blockchain. The idea sounds interesting. If you can find strong use cases for it, it could be very promising. (Monetizing OSS is always difficult.)
Isn't high quality defined by how easy it is to maintain as the scale grows? I feel there is a disconnect between the "quality as perceived by developers" and the "quality as experienced by designers and users."
I agree with most of this. I think code quality has been improving though. Compared to a year ago, the difference is pretty noticeable.
I ran into many of the same issues, and they motivated me to experiment with a linter that flags duplication and architectural problems across a codebase. It’s still a work in progress though:
I recently reviewed some code written by a non-engineer using Cursor's vibe coding. It was full of dead code and patchwork logic. Vibe coding can build a working prototype, but maintaining it? That's another story.
So I built a GitHub App that audits your Python codebase. It reviews PRs and runs weekly scans on the entire repo, catching complex functions, dead code, and duplicates. When it finds issues, it posts comments and Issues with concrete suggestions.
It catches things like complex functions, dead code, and duplicated logic. It can also analyze your entire codebase architecture, something most review bots can't do since they only look at diffs.
Wow, was it really in some newsletters? That's awesome to hear, and would definitely explain the recent spike on GitHub!
Thanks a lot for the bug report and for providing the details. I have a hunch—it's possible that you need to explicitly specify the path depending on your directory structure. For example, if your Python files are under a src directory, could you try running it like [your_tool_name] analyze src/?
If that still doesn't solve the problem, it would be a huge help if you could open a quick issue on GitHub for this.
Pylint's duplication check is text-based (compares lines), while pyscn uses tree edit distance on ASTs. This means pyscn can catch structural clones even when variable/function names differ.
They complement each other - Ruff for style, pyscn for architecture. pyscn focuses on structural quality - checking if your code follows fundamental design principles like DRY, YAGNI, or other best practices.