linting/formatting convention #20

New Issue

asdf · 2019-11-23T00:00:13Z

asdf commented

2019-11-23 00:00:13 +00:00

It would be nice to perform linting and formatting of stuff when it is submitted. Are there any preferences on this?

I use black to format code, and am looking at pylint for static analysis.

It would be nice to perform linting and formatting of stuff when it is submitted. Are there any preferences on this? I use black to format code, and am looking at pylint for static analysis.

cmccabe commented

2019-11-24 03:46:58 +00:00

Give it a shot and I'll learn from watching what you set up. This seems worthwhile to me!

asdf commented

2019-11-25 02:53:02 +00:00

Maybe to clarify, there are many approaches to doing this, the three I know about are:

from time to time we perform linting/formatting as a PR
we all agree to use some linters/formatters on PRs submitted
tools like TravisCI can be used to automatically check PRs for linting/formatting issues (at least, I think this is the case)

Handling some of this manually for now is a good opportunity to learn, but will also help us understand which lint warnings we don't think are important. To illustrate, here are some examples:

linkulator:44:0: C0103: Constant name "link_data" doesn't conform to UPPER_CASE naming style (invalid-name)
linkulator:150:12: C0103: Variable name "dt" doesn't conform to snake_case naming style (invalid-name)

These are preferential - how closely do we want to conform to python naming standards?

linkulator:227:8: R1723: Unnecessary "elif" after "break" (no-else-break)

This is likely solid advice that needs to be actioned.

Later today I'll look in to this further.

Maybe to clarify, there are many approaches to doing this, the three I know about are: - from time to time we perform linting/formatting as a PR - we all agree to use some linters/formatters on PRs submitted - tools like TravisCI can be used to automatically check PRs for linting/formatting issues (at least, I think this is the case) Handling some of this manually for now is a good opportunity to learn, but will also help us understand which lint warnings we don't think are important. To illustrate, here are some examples: ``` linkulator:44:0: C0103: Constant name "link_data" doesn't conform to UPPER_CASE naming style (invalid-name) linkulator:150:12: C0103: Variable name "dt" doesn't conform to snake_case naming style (invalid-name) ``` These are preferential - how closely do we want to conform to python naming standards? ``` linkulator:227:8: R1723: Unnecessary "elif" after "break" (no-else-break) ``` This is likely solid advice that needs to be actioned. Later today I'll look in to this further.

cmccabe commented

2019-11-25 12:29:43 +00:00

I'm happy to try very hard to conform to standards and pythonic coding practices. I code Python in a wild and unprincipled way, and this is a good opportunity to learn some manners and civilized coding practices.

asdf commented

2019-11-27 02:00:50 +00:00

For now, I'd recommend installing black and pylint and running them over any new changes you make. This is manual, but helps as follows:

running black on files you change helps keep a standard document format
running pylint on new changes helps to avoid issues
At the moment, there are too many issues coming up from pylint as it is unconfigured, so don't feel the need to do everything or anything it says.

For now, I'd recommend installing black and pylint and running them over any new changes you make. This is manual, but helps as follows: - running black on files you change helps keep a standard document format - running pylint on new changes helps to avoid issues At the moment, there are too many issues coming up from pylint as it is unconfigured, so don't feel the need to do everything or anything it says.

cmccabe commented

2019-11-27 11:46:00 +00:00

Ok, I just made central installs of black and pylint on rawtext.club

Do you want to discuss using TravisCI? or should I just close this issue?

Ok, I just made central installs of black and pylint on rawtext.club Do you want to discuss using TravisCI? or should I just close this issue?

asdf commented

2019-11-29 02:04:33 +00:00

We could come back to TravisCI or some automated task runner at a later date. It may be best to understand how it all works manually first. If you agree, lets close this off.

Another tool is 'mypy' to validate type hinting. I have been hinting types where possible, I'm not sure what you guys think about it but I like it.

We could come back to TravisCI or some automated task runner at a later date. It may be best to understand how it all works manually first. If you agree, lets close this off. Another tool is 'mypy' to validate type hinting. I have been hinting types where possible, I'm not sure what you guys think about it but I like it.

cmccabe commented

2019-11-29 12:34:56 +00:00

Ok, installed mypy now (on rtc). I would like to learn more about TravisCI too. Travis works through hooks in the repo, right? Like an integration with Github? Does it work with Tildegit? Or can we use it directly from the shells where we're coding?

sloum commented

2019-11-29 15:58:59 +00:00

I have not used type hinting in python before. I have in PHP. I do not care for it in PHP (it doesnt actually handle types correctly in PHP and there are some edge cases that arent that far out on the edge that you can get in trouble with). So, not sure how well Pythons work. I have generally felt that if you want static typing use a language that does that, otherwise use dynamism to your full advantage... but I am good either way. It will be interesting to see how it works in Python, as I didnt even know that it was a thing.

asdf commented

2019-12-07 02:07:07 +00:00

I haven't tried using TravisCI, or something hosted locally, to integrate with Tildegit and automatically lint/test/package. It would be a bit of work to do so, and I think for the initial release we have enough in place to help in this area, so perhaps this can be deferred to a future release?

asdf added the

future release

label 2019-12-16 01:35:44 +00:00

sloum added the

non-code

label 2020-01-16 19:46:11 +00:00

Sign in to join this conversation.