PSL-Infrastructure icon indicating copy to clipboard operation
PSL-Infrastructure copied to clipboard

Identify code formatter to recommend for PSL projects

Open MaxGhenis opened this issue 4 years ago • 4 comments

I'd vote to recommend (or even require) the black code formatter for PSL Python projects. An advantage of black is that it defines a single best code format; it advertises itself as "uncompromising", removing the code author from any code formatting choices so they can focus on just coding. It's integrated to editors like VS Code and I've enjoyed using it over the past few months.

We may also want to define a standard line length. I've been using black with 79 characters.

MaxGhenis avatar Feb 06 '21 16:02 MaxGhenis

I don't know if we should require a code-formater, but I think using one in more PSL repositories would set a good example for new or prospective projects.

I'm a big fan of black and use it in all of the Compute Studio projects and in ParamTools. I really do hope more projects adopt it. It feels like a chore to format code by hand again once you've gotten used to having your code formatted for you :upside_down_face:.

I think it's up to the project and its contributors' preferences for line length. The 79 character line-length limit really grates on me. I prefer a limit of 90 or 100 characters. IMHO as long as the code isn't 125 or 150 characters and isn't trying to do to much, I don't mind.

For example, I think this code in Tax-Calculator's parameters.py module is more readable with a 95 character limit:

https://github.com/PSLmodels/Tax-Calculator/commit/5bf975d0b20ece23223410988d72de36a72079de

image

image

But, to each their own.

I don't think @jdebacker and @rickecon use code-formatters so I'm curious to hear their takes.

hdoupe avatar Feb 06 '21 21:02 hdoupe

I should probably give Black a try. I've not found formatting my own code a chore (it's easy enough to follow stying guidelines as you go), but I have had some frustration on projects with others who obey no rules. It'd be great to auto-correct that work - or just get them using Black. I'll try to give it a go this week.

jdebacker avatar Feb 07 '21 01:02 jdebacker

Just checking in on this. I've come to habitually rely on black and been running it as I've been working on unrelated PRs, but if we agree on it, it'd be better to run it all at once in repos so future PRs can stay clean.

MaxGhenis avatar Mar 02 '21 17:03 MaxGhenis

I will try to give black a run in the next week. I really don't like lines that are longer than 79 characters, and I have heard great things about black from other Python sources. But I don't think we should require it, at least not yet. But we might want to include it as a SHOULD.

rickecon avatar Mar 02 '21 20:03 rickecon