GitHub Super Linter: one linter to rule them all

Post by philsnow » Thu, Jun 18, 2020, 11:47 PM UTC

kristo wrote: post #134

philsnow wrote: post #110

Earlier quoted context omitted.

Code autoformatting is amazing and I never want to go back; even though I strenuously disagree with the particular formatting my team/company has chosen for python, I'm so relieved to never ever have a style discussion in PRs that I don't care about double quotes vs single quotes anymore. BUT I'm tired of seeing diff chunks on github where 95% of the chunk is because black/gofmt decided to change the formatting / ind…

Why don’t we just check ASTs in to git instead of text files ?

    Python 2.7.15 (default, Feb 14 2019, 16:26:56)
    [GCC 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.10.44.4)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import ast
    >>> ast.dump(ast.parse('print "foo"'))
    "Module(body=[Print(dest=None, values=[Str(s='foo')], nl=True)])"

    Python 3.7.2 (default, Feb 14 2019, 16:12:42)
    [Clang 10.0.0 (clang-1000.10.44.4)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import ast
    >>> ast.parse('print "foo"')
    Traceback (most recent call last):
      File "", line 1, in 
      File "/Users/philsnow/.pyenv/versions/3.7.2/lib/python3.7/ast.py", line 35, in parse
        return compile(source, filename, mode, PyCF_ONLY_AST)
      File "", line 1
        print "foo"
                  ^
    SyntaxError: Missing parentheses in call to 'print'. Did you mean print("foo")?

Post by acuozzo » Thu, Jun 18, 2020, 11:50 PM UTC

Post by pmiller2 » Thu, Jun 18, 2020, 11:57 PM UTC

closed wrote: post #226

pmiller2 wrote: post #181

Earlier quoted context omitted.

Rather than “writing... with a model of how black will yield the final code in mind,” it’s more like “Oh, shit, Black made a real mess of this. Can I fix this without butchering the code?”

Yeah--we're basically second-order black formatters now. Not writing code that looks nice, but writing code so a tool that writes code will make it look nice.

Post by erik_seaberg » Fri, Jun 19, 2020, 12:04 AM UTC

nilkn wrote: post #149

BurningFrog wrote: post #147

Earlier quoted context omitted.

To me, because readability is the most important aspect of programming, and it needs to be done right.

But what do you get in that regard by not using black? Maybe in 1% of cases you’ll find a better way of formatting that everyone will also agree is better. That doesn’t seem worth very much at all to me, especially when by not using it you have to do a lot of manual work across the entire team now to get the 99% that is free with black.

Post by a_t48 » Fri, Jun 19, 2020, 12:13 AM UTC

waheoo wrote: post #235

a_t48 wrote: post #208

Earlier quoted context omitted.

Consistent style is more important than each block of code being perfectly pretty. You can still argue aesthetics, but they need to be applied across the entire codebase. Never having to bother someone because their PR doesn't meet the formatting guidelines is well worth it.

People at work nit: my code all the time. I just straight up ignore them. If they ask me why, I tell them to add an autoformat to our ci or shut the hell up. Fwiw, i use an auto formatter but its got problems with certain rules so i switch them off. The reason we dont have it turned on in ci is because these rules break code.