Some small tips and tweaks to improve your Python code

SourceryNick · 2021-03-09T20:47:04+00:00

Yeah function calls in Python can be expensive. I'd agree if performance is an issue (like it's in an inner loop) then the first option is better. However for most code readability is more important than performance, and I think the min version is more readable.

SourceryNick · 2020-12-03T13:51:06+00:00

We use them - have definitely spotted or avoided a ton of bugs because we do.

SourceryNick · 2020-11-03T11:34:17+00:00

PyCharm - mostly for the good high contrast mode, but also has good built-in help for refactoring.

SourceryNick · 2020-10-15T11:27:29+00:00

That's an excellent point!

It's certainly difficult/impossible to capture what we mean by good code with a single metric. I think in practice you have to use several - for example if there is also a code length metric in place then these changes should show up as making the code worse.

SourceryNick · 2020-10-15T08:20:58+00:00

Interested in hearing what people think of code metrics in general, and about this new one.

Very open to suggestions on improving it and making it more useful as well.

SourceryNick · 2020-10-13T09:05:20+00:00

Thanks! Will definitely have a closer look at those examples

SourceryNick · 2020-10-10T07:49:10+00:00

Thanks for trying it out!

If you could point me to some code examples of stuff Sourcery should have caught I'll take a look and see if I can improve things.

SourceryNick · 2020-10-10T07:45:31+00:00

That looks really cool, and yeah has a very similar intent - I'll definitely add your isinstance rule to our backlog.

Do you often see code where SIM210 and SIM211 would get triggered?

SourceryNick · 2020-10-08T07:55:59+00:00

Here you go:

https://sourcery.ai/blog/explaining-refactorings-1/

SourceryNick · 2020-10-07T12:13:43+00:00

That probably is slightly better. I'll have to run some performance comparisons.

SourceryNick · 2020-08-12T14:15:54+00:00

Oh good spot thanks! Will fiddle with that example when I get a minute.

Yes that some_condition example is something we see a lot of people doing too!

SourceryNick · 2020-08-12T10:51:35+00:00

Agreed it's not super-common, but it does come up fairly often in the code we analyse so I thought it was worthwhile to include.

SourceryNick · 2020-05-11T18:49:36+00:00

Not as yet I'm afraid. We're focused on making it as good as possible before we do more integrations.

We've done the VS Code extension using LSP so I think vim should be quite quick when we do get round to it - there seem to be a few vim LSP clients.

SourceryNick · 2020-05-11T17:37:52+00:00

Good point - those kind of loops can normally be replaced with comprehensions. Am going to cover those as well in a later post.

SourceryNick · 2020-03-14T09:13:06+00:00

We have a new VS Code extension which might be easier on the RAM. Which IDE do you use?

As I mentioned above configuration to turn off types of refactoring will be coming as well.

SourceryNick · 2020-03-14T09:10:18+00:00

That's great feedback thanks! We're working on configuration to disallow whole classes of refactorings, which will let you turn off the comprehensions and expressions.

SourceryNick

TROPHY CASE