Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Identify code formatter to recommend for PSL projects #235

Open
MaxGhenis opened this issue Feb 6, 2021 · 4 comments
Open

Identify code formatter to recommend for PSL projects #235

MaxGhenis opened this issue Feb 6, 2021 · 4 comments

Comments

@MaxGhenis
Copy link
Contributor

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.

@hdoupe
Copy link
Collaborator

hdoupe commented Feb 6, 2021

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 🙃.

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:

PSLmodels/Tax-Calculator@5bf975d

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.

@jdebacker
Copy link
Member

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.

@MaxGhenis
Copy link
Contributor Author

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.

@rickecon
Copy link
Member

rickecon commented Mar 2, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants