Hacker News Reader

Comment by sago | Hacker News Reader

So set up at 120, and then look at someone's code that's used 128 consistently. And then reformat for those few lines that went that long. See the point?

You can't standardise based on what you are fond of. That's the point of a standard. When such a large proportion of people, and the standard library, and most shells, use 80, then using 120 will inconvenience them. If you load my 80col code into your 120 col editor, it will not inconvenience you at all, barring an occasional extra line break.

View on HN

>So set up at 120, and then look at someone's code that's used 128 consistently. And then reformat for those few lines that went that long. See the point?

No.

>You can't standardise based on what you are fond of.

Sure you can. That's why company and team-wide standards are for.

Nobody has to be forced to use some BS 70's throwback rules just because they are in PEP8.

I get that. But a large section of the Python community has standardized on 120, and I'm adding to it in hopes of hitting critical mass.

In your average code, what proportion of lines of code are > 80 cols?

    >>py34 lns.py
    total lines: 2099
    0.063% over 80

Not many apparently, and a significant portion of them are hard coded URLs/strings in scripts. I guess I stand corrected, 120 isn't that useful...

    import os

    from pathlib import Path

    def walklines(glob='**/*.py'):
        for filename in Path(os.getcwd()).glob(glob):
            with open(str(filename)) as file:
                for line in file.readlines():
                    yield line

    if __name__ == '__main__':
        alllines = [line for line in walklines()
                    if line]

        totallines = len(alllines)

        cutoff = 80

        total_long_lines = len([line for line in alllines
                                if len(line) > cutoff])

        prcnt_long = total_long_lines / totallines

        print('total lines: {}'.format(totallines))
        print('{:.3f}% over {}'.format(prcnt_long, cutoff))

One thing I find that makes a big difference is using the PEP8 indentation rules for writing lines of the form

    variable = some_function((some nested expression that is very long
                              and needs to wrap))

    variable = some_function((
        some nested expression that is very long but may not need to wrap
        but if it does there's tons more room for it))

I.e. you don't have to differentiate between 'syntax indents' and 'expression indents', every thing is just an indent of the same size. Which has the advantage that almost every editor can indent it correctly, and it works with both space and tab indents, whereas you're at the mercy of your Python editing mode whether the 'indent to sibling' works for everyone (and if not, the programmer has to sit tapping space to line it up right). Both approaches are in PEP8, but i find that simple change removes 99% of all >80 line cases for me.

The only caveat, also covered in PEP 8 is for function definitions.

    def some_descriptive_function_name(one_parameter,
                                       another_parameter):
        some_functionality()

becomes

    def some_descriptive_function_name(
            one_parameter, another_parameter):
        some_functionality()

i.e. the parameter lines are double indented.

Double indentation looks rather ugly though. I like the "K&R" style much better (as shown in comment from bpicolo):

    def some_descriptive_function_name(
        one_parameter,
        another_parameter,
    ):
        some_functionality()

Anyway, either one is superior to 'indent to sibling', where the lines are now tightly coupled to each other.

We each have different tastes, yes.

But, coding standards aren't about tastes, they are about coordinating large numbers of programmers to write code in consistent ways. PEP 8 gives the 'double indentation' as standard, rather than the 'K&R' style.

You're free to write however you want to, and if you're the tech director of a company, you can tell everyone else to follow your aesthetics. But you'll be doing a lot of work with code written according to PEP8. In my experience, learning and disciplining your team to use the standard is better than having a house-style. But YMMV, of course.

PEP8 isn't my 'ideal' aesthetic for Python either, but I'd need a far better reason than 'I think that looks ugly' for not using it.

I also agree 'indent to sibling' is poor, and not very universally tool-supported, even though it is part of the PEP8 style.

I don't see the problem. There are aspects of PEP8 which I don't like, so I don't follow them. Why would you need to convince others of your coding preferences?

Reply on news.ycombinator.com