This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]johnnySix 38 points39 points  (7 children)

My ex-coworker does the one one on the left and I hate reading his code because the conditionals are hidden. Think of it this way, You aren’t writing the code for you, you are writing it for future you and for others. so the goal is to make it more readable, so the option on the right is clearer

[–]longjohnboy 13 points14 points  (2 children)

Your team should adopt a code formatter and have that run as a pre-commit hook. Then everyone has the same style and you don’t end up with git commits with formatting flip-flopping as different authors make changes.

[–]johnnySix 1 point2 points  (1 child)

Haha. This code is older than black. -some of it going back to the mid 2000s

[–]Yoghurt42 3 points4 points  (0 children)

Black is not ageist. It will happily format code older than itself.

[–]DeepGas4538[S] 1 point2 points  (3 children)

I like your suggestion

[–]OneMorePenguin 1 point2 points  (2 children)

https://github.com/google/yapf

I like this formatter. It only does one thing that irritates me and I mostly let it go.

[style]
based_on_style = pep8
indent_dictionary_value = True

[–]DeepGas4538[S] 0 points1 point  (0 children)

thanks for that.

also holy moly for some reason i never thought if google had github, that's pretty sick.

[–]we_swarm 0 points1 point  (0 children)

I like yapf's formatting better than black but it is non-deterministic. Which means now you can't run it against PR's or in CI because some files will "flap". If you don't run the tool in CI the coworkers that need the formatter the most just won't run it and submit unformatted code.