Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Formatting code should be unnecessary

maxleiter.com

Post reply on HN
Print view View original

401–410 of 484 posts

Re: Formatting code should be unnecessary

#401

Post by yoyohello13 »

automatoney wrote: post #50

I've never understood why people care so much about the linter settings. It's so obviously bikeshedding, just make a choice, run the linter automatically and be done with it. I'm too busy doing actual software engineering to care about where exactly everything goes - I promise after a week you'll just get used to whatever format your team lands on.

Same! I have no patience for these kind of arguments about formatting. I don't care that you don't like what the formatter does, it isn't about you. I've written code in several different languages over the years and the main take away is that I can get used to reading anything. It's so important to pick a standard and follow it. As long as that standard is somewhat sane I couldn't care less what the actual standard is.

Another argument that is a pet peeve of mine is significant white-space vs curly braces. It literally doesn't matter. We often get new Python developers coming from a C# background and the amount of bitching about curly braces is so annoying. Just learn the language bro, it's not that hard.

Re: Formatting code should be unnecessary

#402

Post by mhh__ »

automatoney wrote: post #50

I've never understood why people care so much about the linter settings. It's so obviously bikeshedding, just make a choice, run the linter automatically and be done with it. I'm too busy doing actual software engineering to care about where exactly everything goes - I promise after a week you'll just get used to whatever format your team lands on.

Some styles can actively make some people less productive though e.g. I really try to avoid allman braces because I can work a lot better with denser (for a certain definition of dense code)

This, however, usually doesn't effect me if the official format for a project is one way or the other because [drumroll] I just format my tree differently and then format to the official style when I push.

Re: Formatting code should be unnecessary

#403

Post by mhh__ »

A small point on formatting that I'm getting increasingly firm about as I "age" (still not that old): Formatting is very important, but if you find yourself complaining about what a formatter does to your code, the code be bad (obviously making an exception for a big block of constants or something)

e.g. if the formatter is really shifting stuff around, your code might be too nested - if you have a compiler, let it take the strain.

Re: Formatting code should be unnecessary

#404

Post by 3pt14159 »

ParetoOptimal wrote: post #394
maest wrote: post #261

Earlier quoted context omitted.

That makes prepending an element a special case.

It makes it easier to read though because the least important parts are most easily ignored. The reader can focus on the contents of the list.

I don't really know why we even need commas for lists of things. Just use the white space.

Re: Formatting code should be unnecessary

#405

Post by maratc »

lenzm wrote: post #391
maratc wrote: post #373

Earlier quoted context omitted.

The trailing comma communicates an intent of possibly adding more things in the future. I actually use it quite a lot -- when I have that intent . In the above example, if I think I have listed all of the `important_numbers`, there is a certain point of not having the trailing comma there. Here's another terrible example from `black`: From this: my_print(f"This string has two parameters, `a` which is equal to {a} and…

Yes, it gets a trailing comma if it's on it's own line. That way when you add/remove arguments in a multi-line call it's only a one-line diff. This doesn't apply when the diff is only one line anyway. Who's to say you don't add a new argument to the function in the future, like my_print( "This string has two parameters, `a` which is equal to {a} and `b` which is equal to {b}", a=1, b=2, color_negative_red=True, )

> it gets a trailing comma if it's on it's own line.

Sorry but it doesn't make any sense to me. If your argument is "a trailing comma is a good thing," it should go into any and all function calls/list declarations/etc. Who's to say I won't add this in the future:

    my_print("a={a}, b={b}", a=1, b=2, color_negative_red=True)
So do I need to have this now?

    my_print("a={a}, b={b}", a=1, b=2,)
There's a very responsive playground at https://black.vercel.app/ and whatever it does looks strange to me, because the underlying assumptions look inconsistent one with the other (to my eye at least.) Specifically, "the length of the string should decide whether there is a trailing comma or there isn't" makes zero sense.

Re: Formatting code should be unnecessary

#406

Post by whizzter »

zahlman wrote: post #352
socalgal2 wrote: post #152

Earlier quoted context omitted.

some settings have advantages. For example, trailing commas on tables [ 'apple', 'banana', 'orange', ] has an advantage over [ 'apple', 'banana', 'orange' ] Because adding a new line at the end of the table (1) requires editing 1 line, instead of 2 (2) makes the diffs in code review smaller and easier to read and review. So a bad choice makes my life harder. The same applies to local variable declarations. Sorted lis…

> Also, my OCD hates inconsistency Mine hates trailing commas :) More seriously, I don't like having lists like that in the code in the first place. I don't want multiple lines taken up for just constant values, and if it turns out to require maintenance then the data should be in a config file instead anyway.

Rule of 3, write/change it once or twice (or seldomly enough with no possible negative impact) and it doesn't need any complexity. More than so.. yeah probably goes into a config.

Re: Formatting code should be unnecessary

#407

Post by thfuran »

maratc wrote: post #405
lenzm wrote: post #391

Earlier quoted context omitted.

Yes, it gets a trailing comma if it's on it's own line. That way when you add/remove arguments in a multi-line call it's only a one-line diff. This doesn't apply when the diff is only one line anyway. Who's to say you don't add a new argument to the function in the future, like my_print( "This string has two parameters, `a` which is equal to {a} and `b` which is equal to {b}", a=1, b=2, color_negative_red=True, )

> it gets a trailing comma if it's on it's own line. Sorry but it doesn't make any sense to me. If your argument is "a trailing comma is a good thing," it should go into any and all function calls/list declarations/etc. Who's to say I won't add this in the future: my_print("a={a}, b={b}", a=1, b=2, color_negative_red=True) So do I need to have this now? my_print("a={a}, b={b}", a=1, b=2,) There's a very responsive pl…

>Sorry but it doesn't make any sense to me. If your argument is "a trailing comma is a good thing," it should go into any and all function calls/list declarations/et

No, the argument is quite specifically that a one line diff to add a new argument/element to the end of a list is preferable to a two line diff to do the same thing. The presence of the trailing comma is necessary to achieve that only when elements are on their own line.

Re: Formatting code should be unnecessary

#408

Post by craftkiller »

kristopolous wrote: post #240
AdieuToLogic wrote: post #107

Earlier quoted context omitted.

> I've never understood why people care so much about the linter settings. Source code formatting programs are not the same as lint[0] programs. The former rewrites source code files such that the output is conformant with a set of layout rules without altering existing logic. The latter is a category of idempotent source code analysis programs typically used to identify potential implementation errors within otherwi…

Formatters, if you want to be specific, are even worse. They slyly add git noise and pollute your audit trails by just going through and moving shit around whenever you save a file. And sometimes, they actually insert bugs - string formatting errors are my favorite example. It's for people who think good code is a about adhering to aesthetic ideologies instead of making things documented and accountable. This is most…

> Sometimes I'll get a pull request with like 2 lines of change and 120 lines of some reformating tool.

The reformatting tools should be CI-enforced so you'll only end up with sudden massive changes like this once when you start using auto-formatters.

Regardless, tell your teammates to separate out formatting changes vs logic changes into separate commits (preferably separate PRs). Since they're auto-formatters it wouldn't even be any additional work, just:

  git fetch origin
  git checkout origin/main
  git checkout -b formatting
  ./run_the_autoformatter.bash
  git commit -a -m "Ran the auto-formatter, which should have been enforced by the CI."
  git push -u origin formatting

Re: Formatting code should be unnecessary

#410

Post by justincredible »

dghf wrote: post #306
aleph_minus_one wrote: post #287

Earlier quoted context omitted.

> Because adding a new line at the end of the table (1) requires editing 1 line, instead of 2 (2) makes the diffs in code review smaller and easier to read and review. This judgement is rather based on a strong personal opinion (which I don't claim to be wrong, but also not as god-given) on what is one , and what are two changes in the code: - If you consider adding an additional item to the end of the list to be one…

> 2. 'orange' has been turned from the last element of the list to a non-last element of the list Then why not consider it four changes? 3. 'banana' has been turned from the last-but-one element of the list to the last-but-two element of the list 4. 'apple' has been turned from the last-but-two element of the list to the last-but-three element of the list

[dead]
Post reply on HN