>
> The 80 characters per line, is definitely crazy
When I started programming in python (and that was about 10 years ago) I
thought the same. More so, when we have four spaces per indent. But then,
now I am completely comfortable with 80 characters per line. There are ways
to get your code to look more beautiful (and readable of course) with 80
characters. And believe me, sometimes I have stuff that is easily 200 lines
long if not formatted but I do get around by changing a few things here and
there. At my work, we follow the 80 chars limit though it is not strictly
forced and sometimes I see code more than 120 characters per line. There is
a big debate going on in all sorts of camps, Google, for example, uses four
spaces per indent (the last I know) and there was a huge cry for 2 spaces
per indent, but I think I did not happen so far.
There is a rationale going around that says that 80 characters per line
were good in the old days when we did not have displays capable of handling
more but that is not the case these days so why not go over 80. Well, this
is not the only reason that code should be wrapped in 80 characters. The
real reason is - Any line, to be read without causing a much cognitive
burden on the reader, should not be more than 75 characters long according
to some studies. This is more about written languages like English, but
then the same applies. I would argue more, in a programming language.
People (and for that matter even you ) read your code and they have to
figure out what that piece of code is trying to achieve. If a line is too
long, the visual noise compromises readability.
The first Zen of python is - "Beautiful is better than ugly". When Guido
implemented scopes using indented space instead of curly braces (or other
braces for that matter) and line endings without ";", it was meant for
making code beautiful and readable. That is the philosophy of python and
that's what makes it beautiful.
So, how do you make your code look good and readable within 80 characters
per line guidelines? Here are a few things you can do:
1. Break early with the function:
# When faced with thisdef
a_very_big_fucntion_name(some_big_argument_name, another_big_argument,
and_yet_another_huge_argument_name, this_seems_to_end_nowehere,
what_should_I_do_with_these_arguments):
pass
# Do thisdef a_very_big_fucntion_name(
some_big_argument_name,
another_big_argument,
and_yet_another_huge_argument_name,
this_seems_to_end_nowehere,
what_should_I_do_with_these_arguments,
):
pass
2. Use () whenever needed:
# *Instead of this*
condition = some_condition_that_is_very_long == long_condition and
another_very_long_condition == another_long_condition or
yet_another_long_condition != short_condition
# *Do this*
condition = (
some_condition_that_is_very_long == long_condition and
another_very_long_condition == another_long_condition or
yet_another_long_condition != short_condition
)
3. Inside strings too:
# Instead of this
raise ValueError("Some error that is so huge that it cannot be wrapped
up in 80 characters. You have to show full error message otherwise it
is not worth reporting at all. What to do now!")
# Do this
msg = ("Some error that is so huge that it cannot be wrapped "
"up in 80 characters. You have to show full error message"
" otherwise it is not worth reporting at all. What to do now!")
raise ValueError(msg)
Of course, there are many other things like naming your variables shorted
when possible, breaking logic in two lines etc.
A lot of hard core programmers that I´ve woked with, don´t give a f***
> about pep-8
That is true but sad. If you care about your code, if you respect beauty
and aesthetics (and we should being in the entertainment industry), if you
want other people to understand your code, if you consider that programming
is an art, and if you think that good graphic design evokes right kind of
emotions and has good bearing over the audience, then you should follow
some graphic design principles even in your code. A lot of thought has gone
into PEP-8 and there is a reason for its existence - To make code look good
and resolve to clarity in the face of ambiguity. The whole idea behind
high-level languages was to make code readable and understandable so that
we can benefit from it, otherwise, we would have been writing machine and
assembly till date. PEP-8 is a guiding principle and you should force
yourself to follow it, your code will definitely become beautiful.
On Sun, Sep 25, 2016 at 7:13 PM, Marcus Ottosson <[email protected]>
wrote:
> About style, that is all fine. But if you're in a team, maybe try to think
> less about what you prefer, and consider the preference of those reading,
> and potentially maintaining your code.
>
> Even amazing programmers will appreciate having their preference
> considered.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/python_inside_maya/CAFRtmOCH5a4hW7QY8wZAS8PQngbJu
> r%3DpEYCrGfPHP5gFtCwiig%40mail.gmail.com
> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCH5a4hW7QY8wZAS8PQngbJur%3DpEYCrGfPHP5gFtCwiig%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
--
You received this message because you are subscribed to the Google Groups
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMSqtvhK%2B6Z1s6omNQf%2BxXSBUdF0f3V-1EZLxVsi%2B9DU_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
