3 ms·

I love the way you format your py code. clean and super easy to read. https://github.com/minimaxir/facebook-page-post-scraper/blob/master/get_fb_posts_fb_group

I love the way you format your py code. clean and super easy to read. https://github.com/minimaxir/facebook-page-post-scraper/blob/master/get_fb_posts_fb_group.py https://github.com/minimaxir/facebook-page-post-scraper/blob...

dirtyaura 10y ago
It seems pretty standard to me. Curious, what is there that you especially like? I only noticed a couple things that is different from what I usually see (and write): - newline after function declarations - assigments with `= x if pred else y` style and trailing \ formatting
- johnwheeler 10y ago
  Mostly the liberal code spacing and the comments. I tend to omit both. I like how comments > 1 line have newlines before and after them.
  - avar 10y ago
    This is obviously just some guy's mostly throwaway code, but FWIW it's got the type of comments I don't find useful at all when reading code. I.e. comments that purely duplicate what can be trivially inferred from code: # retrieve data data = json.loads(request_until_succeed(url)) Not ambiguous, but better done by just naming the function in such a way that it's obvious that it's the thing retrieving the data. And: num_processed = 0 # keep a count on how many we've processed Is another example of a comment that doesn't compliment the code, but just distracts the reader from information they could equally, more accurately & more briefly have gotten from reading the corresponding code.
    - gjm11 10y ago
      I think there's a place for the "# retrieve data" sort of comment. Suppose you're skimming rather than reading the code, either trying to get a high-level overview of what it does or looking for the particular bit of it where a particular thing happens. Then, sure, you could just read all the code; but most of us can skim-read a small quantity of text faster than a larger quantity of code. In a syntax-colouring editor it's easy to ignore everything but the comments, and if the top-level structure of what's happening is sketched in the comments that's helpful. How helpful depends, of course, on the style of the code; in particular, it gets less helpful as the length of functions/methods goes down, and in the limit of "ravioli code" where everything is decomposed into 3-line methods whose main task is calling other 3-line methods, it doesn't help at all and the sort of comment you need to help with skimming is an overview of how the pieces fit together. At the other extreme, if you have the sort of 1000-line function that's quite common in e.g. numerical code, these structure-sketching comments can be invaluable.
    - minimaxir 10y ago
      OP here: Agreed; the original code was a part of a tutorial (http://minimaxir.com/2015/07/facebook-scraper/ http://minimaxir.com/2015/07/facebook-scraper/), hence the more liberal comments for clarity. (after my refactor, I'll remove a few) See another one of my recent Python scripts for an example of more conservative commenting: https://github.com/minimaxir/tritonize/blob/master/tritonize.py https://github.com/minimaxir/tritonize/blob/master/tritonize...
minimaxir 10y ago
OP here: Full disclosure, I've been working on that code today (unrelated to this blog post), and the formatting is mostly done through linters. (e.g. autopep8, and abusing the Format Document button in VS Code) There are still a few PEP8 violations which the linter doesn't fix (e.g. the 79 character width) and there are still a few things that need fixing. (after I commit my 4x speedup refactor, anyways) Relevant VS Code settings: "editor.rulers": [80], "python.linting.pep8Enabled": true, "python.formatting.provider": "autopep8", "python.linting.pylintEnabled": false,
- johnwheeler 10y ago
  I like that you're not afraid to use space and how the comments stand out. My code is so dense, and now I'm tweaking it to look more like yours
- patrec 10y ago
  Wrt 79 char limit, maybe try yapf? https://donjayamanne.github.io/pythonVSCodeDocs/docs/formatting/ https://donjayamanne.github.io/pythonVSCodeDocs/docs/formatt...

dirtyaura 10y ago

It seems pretty standard to me. Curious, what is there that you especially like? I only noticed a couple things that is different from what I usually see (and write): - newline after function declarations - assigments with `= x if pred else y` style and trailing \ formatting

johnwheeler 10y ago
Mostly the liberal code spacing and the comments. I tend to omit both. I like how comments > 1 line have newlines before and after them.
- avar 10y ago
  This is obviously just some guy's mostly throwaway code, but FWIW it's got the type of comments I don't find useful at all when reading code. I.e. comments that purely duplicate what can be trivially inferred from code: # retrieve data data = json.loads(request_until_succeed(url)) Not ambiguous, but better done by just naming the function in such a way that it's obvious that it's the thing retrieving the data. And: num_processed = 0 # keep a count on how many we've processed Is another example of a comment that doesn't compliment the code, but just distracts the reader from information they could equally, more accurately & more briefly have gotten from reading the corresponding code.
  - gjm11 10y ago
    I think there's a place for the "# retrieve data" sort of comment. Suppose you're skimming rather than reading the code, either trying to get a high-level overview of what it does or looking for the particular bit of it where a particular thing happens. Then, sure, you could just read all the code; but most of us can skim-read a small quantity of text faster than a larger quantity of code. In a syntax-colouring editor it's easy to ignore everything but the comments, and if the top-level structure of what's happening is sketched in the comments that's helpful. How helpful depends, of course, on the style of the code; in particular, it gets less helpful as the length of functions/methods goes down, and in the limit of "ravioli code" where everything is decomposed into 3-line methods whose main task is calling other 3-line methods, it doesn't help at all and the sort of comment you need to help with skimming is an overview of how the pieces fit together. At the other extreme, if you have the sort of 1000-line function that's quite common in e.g. numerical code, these structure-sketching comments can be invaluable.
  - minimaxir 10y ago
    OP here: Agreed; the original code was a part of a tutorial (http://minimaxir.com/2015/07/facebook-scraper/ http://minimaxir.com/2015/07/facebook-scraper/), hence the more liberal comments for clarity. (after my refactor, I'll remove a few) See another one of my recent Python scripts for an example of more conservative commenting: https://github.com/minimaxir/tritonize/blob/master/tritonize.py https://github.com/minimaxir/tritonize/blob/master/tritonize...

minimaxir 10y ago

OP here: Full disclosure, I've been working on that code today (unrelated to this blog post), and the formatting is mostly done through linters. (e.g. autopep8, and abusing the Format Document button in VS Code) There are still a few PEP8 violations which the linter doesn't fix (e.g. the 79 character width) and there are still a few things that need fixing. (after I commit my 4x speedup refactor, anyways) Relevant VS Code settings: "editor.rulers": [80], "python.linting.pep8Enabled": true, "python.formatting.provider": "autopep8", "python.linting.pylintEnabled": false,

johnwheeler 10y ago
I like that you're not afraid to use space and how the comments stand out. My code is so dense, and now I'm tweaking it to look more like yours
patrec 10y ago
Wrt 79 char limit, maybe try yapf? https://donjayamanne.github.io/pythonVSCodeDocs/docs/formatting/ https://donjayamanne.github.io/pythonVSCodeDocs/docs/formatt...