rikatee

it's a good start. VSCode is most popular. Largest impact. More potential users. More likely to find a customer base.

internally and see a 5-10x boost on some tasks.

That's my experience with co-pilots too:

- Generating tests

- Generating functions consistent with prevailing style of similar functionality in the existing codebase. The greater the consistency, the more helpful the AI is at generating.

- Telling me why my code is crap by adding a `# todo: ` above some code and seeing what the AI suggests should be changed :)

What other tasks do you see as good target for 5-10x boosts?

I like this. I think AI agents are the future of software development.

AI will not replace devs. Devs that use AI will replace devs that do not use AI.

The most effective devs will be those employing a fleet of AI agents, acting as the glue and guiding hand for what the agents should produce.

This helps us get to that future, so I think this has legs.

I use VS code. I will try this out.

FWIW, HN is much more positive (while also raising valid points that will be taken into account going forward)

flake8 does not currently support this check, as they are concerned about the false positives from "what if the string it later used in .format(...)"

However, Code Review Doctor is more of a "this MIGHT be a problem. have you considered..." rather than "it wrong"

what's also ironic is I left an easter egg in the code sample for how we downloaded the list of repositories and no one has noticed it yet.

klyrs was right about the reply from me (a dev behdind Code Review Doctor) being dismissive in the issue. I apologise for that.

FWIW my reaction was classic "expectations not meeting reality": weeks of work to do (what I thought) was a mutually beneficial helpful thing. I was naively not expecting non-positive responses and was ill prepared when you raised valid concerns I had not considered.

Again, I am working on that and sorry I was passive aggressive to you.

Yeah good point that sucks. I will move off wordpress because I'm not a fan of tracking cookies. It's got ridiculous.

interestingly 69 of the 666 repos had the f string issues

of the codebases checked yep (20 of 666 checked).

Bear in mind only 28% of codebases actually use built-in unittest package that this gotcha is affected by, so really it's 20 of 28% of 666 aka 10% ... but that claim would be hard to justify by folks that dig stats.

Agreed in perfect world, but unfortunately any process that involves humans will involve human error.

We do code review because we expect human error when the code was written by a human, but then we also expect not human error when the code is being read (reviewed) by a human? Any process that expects zero human error will always fail.

That's where linters add value: they allow devs to do what humans are good at (the creative complex and interesting stuff) while the bots do what bots are good at (the boring repetitive stuff)

we were all waiting for you to

yes that's exactly the kind of problem :)

it does not, it just prints them out in the console

the post covers the built-in unittest package, which 28% of devs still use. But pytest is nicer to work with. I think brownfield codebases and inertia are the reason 28% of devs work (or have to work) with unittest

you're right thanks! Updated :)

deep ninja turtles lore

oh dear time for a edit as I did indeed mean Schrödinger!

once tensorflow pointed to keras-team this happened

https://github.com/keras-team/keras/issues/15854

resulting in

https://github.com/keras-team/keras/pull/15876

cool product :) it is just linting or do any of the tools do code transformation to offer the fix for the lint failure? (code review doctor also offers the fix if you add the github PR integration)

in a blog post about the evils of typos there was a typo! classic https://en.wikipedia.org/wiki/Muphry%27s_law ;)

there is also https://pypi.org/project/flake8-tuple/

typo in the url (or in HN's markup) btw: it's https://codereview.doctor

can do a good job at allowing long urls for example, but would be whack a mole trying to cater for "all" purposeful implicit string concatenations

unfortunately like 10% of the bugs were in the tests themselves. e.g., the sentry one https://codereviewdoctor.medium.com/5-of-666-python-repos-ha...

the tests are only as good as the code they're written with, and as good as the code review process they were merged under.

yeah the impact varies. the sentry one seems pretty big: https://codereviewdoctor.medium.com/5-of-666-python-repos-ha...

test did not work but did not fail either, imagine being that dev maintaining the code that the test professes to cover. Imagine being the user relying on the feature that test was meant to check (if the feature under test actually broke).

yeah something like sonarqube or https://codereview.doctor (if you use GitHub)

http://codereview.doctor/

It's static analysis SaaS that detects bugs and code smells and offers the fix right inside the GitHub PR, so no need to context switch - just click commit and continue with your day

It's a code review copilot for GitHub that suggests fixes to bugs it finds e.g, if you missed a comma in a list, accidentally committed a breakpoint, used deprecated features, using "==" when you should use "is" and vice versa, if you're making your life harder than it needs to be, and more.

This started life as a Django-specific toolbut I recently overhauled it to also support checking Python code in general hence changed the name from Django Doctor to CodeReview Doctor. So now it does both (and will do more languages and frameworks in future).

Feedback on landing page would be appreciated and of course give it a spin. it's free to public repos!

We use python's AST to power https://pypi.org/project/django-doctor/ - it's a Django linter that suggests the fix and makes the change it suggests if you approve the change.

Eventually we will replace AST with a CST (Concrete Syntax Tree) because the tricks we used maintain new lines and comments indicate CST was actually needed.

6 months ago I released Django Doctor to review github pull requests.

Now it can be installed as a command line tool via `pip install django-doctor`.

So now instead of reviewing deltas in GitHub PRs it runs locally and analyses your entire codebase to suggests improvements.

A nifty trick is it uses the browser to allow you to pick and choose which suggestions to take and then adds `# django-doctor: skip foo` to lines you don't want changing.

Hopefully after 6 months, 1000 installations on github, and tens of thousands of builds in the cloud it shouldn't have too many bugs when running locally! Let me know!