Comment on The lengths we have to go to

• GBU_28@lemm.ee ⁨1⁩ ⁨year⁩ ago

  With things like black, flake 8 and Isort I can code however I want, list/format however I want, and commit team compliant content. The dream is real

  source

  • CoderKat@lemm.ee ⁨1⁩ ⁨year⁩ ago

    I love such formatters and wish they were even more widespread. In many cases, I really want consistency above all and it’s so dang hard to achieve that without an opinionated formatter. If the formatters isn’t opinionated enough, it just leads to countless human enforced rules that waste time (and lead to an understandable chorus of “why can’t the formatter just do that for meeeee”).

    source
  • theneverfox@pawb.social ⁨1⁩ ⁨year⁩ ago

    Wait wait wait, what is this black magic and how have I not heard of it?

    source

    • GBU_28@lemm.ee ⁨1⁩ ⁨year⁩ ago

      So you can have a local, and a team config. So at time of commit the code rules your team has selected are enforced. So if I looked at my code, on GitHub, it would look as expected by the team.

      If I load it locally, it formats as I like.

      Check out the cicd stuff on PRs for github

      source
• RogueBanana@lemmy.zip ⁨1⁩ ⁨year⁩ ago

  Yeah but outside of that where the code is implemented or in a documentation, tabs are still easier to look through. And it does look pretty as long as there aren’t too many nested functions.

  source

  • mexicancartel@lemmy.dbzer0.com ⁨1⁩ ⁨year⁩ ago

    Even with nested functions tabs are neat.

    Does you app have too many nested functions?

    Use tab width = 2

    Do your app have too less nested functions?

    Use tab width = 8

    Is your app having average number of nested fns?

    Use tab width = 4(mostly default)

    And all theese can happen without modifying a single byte in the source file, unlike spaces!

    source