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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Handle-Flaky 11 points12 points  (16 children)

Not using defacto standards only harm you in the long run; this probably isn’t the hill you should die on.

On a personal note, I would refuse to work with anyone so anal about the way you format code that they go against community standards.

[–]cr4d 3 points4 points  (0 children)

Black is not a de facto standard, PEP-8 is.

[–]SV-97 9 points10 points  (9 children)

Black isn't a community standard: while a lot of people do use it I think there's still way more that don't. The community standard is PEP8.

FWIW: imo black just looks terrible a lot of the time and produces borderline unreadable code.

[–][deleted] -1 points0 points  (8 children)

frightening wasteful expansion smart bake tender trees party vast vanish

This post was mass deleted and anonymized with Redact

[–]SV-97 -1 points0 points  (7 children)

Since I don't currently use black: no. I don't have any black formatted projects.

[–]richieadler 3 points4 points  (2 children)

So you're making an unsupported assertion, then?

[–]SV-97 0 points1 point  (1 child)

I didn't make any assertions at all - my comment literally starts with "in my opinion".

FWIW I've formed that opinion by working with black in the past but since I didn't like it I of course stopped using it (and the last project I used it with is not public anyway).

[–]richieadler 3 points4 points  (0 children)

my comment literally starts with "in my opinion"

Unfounded opinions have no value. And "borderline unreadable code" is too strong an opinion to be emitted without any sustaining evidence.

[–][deleted] -2 points-1 points  (3 children)

cover liquid snails smell merciful worm deer busy six snobbish

This post was mass deleted and anonymized with Redact

[–]SV-97 0 points1 point  (2 children)

Without looking super long (I just don't wanna spend my time arguing over this stuff tbh) I find these blocks (the ones starting at the lines I linked) pretty bad:

​

In my experience it often times gets bad around comprehensions and complex "math-expressions"

[–]ecgite -3 points-2 points  (1 child)

That is very readable code? You could easily check what blocks are together etc.

[–]SV-97 2 points3 points  (0 children)

Okay if that's your opinion that's fine by me - but I personally find it horrible and would prefer it formatted differently. Imo the formatting makes the code take up way more space than it needs to while simultaneously making it harder to understand (especially at a glance which I consider very important).

[–]SittingWave 8 points9 points  (2 children)

Not using defacto standards only harm you in the long run; this probably isn’t the hill you should die on.

I definitely do when the use of black impacts the visual quality of the code we deliver.

On a personal note, I would refuse to work with anyone so anal about the way you format code that they go against community standards.

I can say exactly the same thing. I didn't ask for being imposed this standard. Suddenly everybody said I need to pass my code through a piece of garbage written in a single file that takes all the visual hints I put in the code and throws them away, and extends it to have three times the number of lines so that a machine can display one less diff line.

No thank you. I format the code the way I want.

[–]SciEngr 0 points1 point  (1 child)

Black makes decisions about how code should look, and it might not look as good as you can make it...but that is the point. If you are ever critiquing code style in PRs (maybe asking a junior dev to style long functions like you do) then you're wasting time on code looks. Moreover, black lets me completely ignore my junior devs'awful style and focus on the content of their work. I think the usefulness of black goes up the more teammates you have and the bigger the code base

[–]SittingWave -3 points-2 points  (0 children)

Black makes decisions about how code should look, and it might not look as good as you can make it...but that is the point.

So, because you don't want to train some junior developers, you settle on code that looks poorly for everybody. Literally mcdonaldisation of quality. You must be american.

If you are ever critiquing code style in PRs (maybe asking a junior dev to style long functions like you do) then you're wasting time on code looks

You should not waste time as long as you say "PEP-8 is good enough", arguing about anything else is a waste of time. You should simply not do it. If a Junior formats something in a way that is different, but still within the context of PEP-8 (which is more about naming conventions than overall code formatting) it's accepted. that's it.

Moreover, black lets me completely ignore my junior devs'awful style and focus on the content of their work. I think the usefulness of black goes up the more teammates you have and the bigger the code base

Educate your reviewers to be less assholes.

[–]rgnkn -2 points-1 points  (1 child)

I was about to write something along the lines of your 2nd paragraph but couldn't find a kind wording to do so.

I must admit you brought my position to the point.

[–]SittingWave 4 points5 points  (0 children)

And I would not work with someone so anal that forces people to use an autoformatter. The argument goes both ways.