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

391–400 of 484 posts

Re: Formatting code should be unnecessary

#391

Post by lenzm »

maratc wrote: post #373
iainmerrick wrote: post #335

Earlier quoted context omitted.

It works the way you want if you add a trailing comma: important_numbers = { "x": 3, "y": 42, # Answer to the Ultimate Question! "z": 2, } You might complain that that seems a bit obscure, but it only took me 10 or 20 seconds to discover it after pasting the original code snippet into an editor. The trailing comma is an improvement as it makes the diff clearer on future edits. Edit to add: occurs to me that I oversim…

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,
    )

Re: Formatting code should be unnecessary

#392

Post by ParetoOptimal »

austin-cheney wrote: post #271
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…

Yes, everyone has personal opinions about code vanity. When this becomes a holy war I really start to question the maturity of people on the project. I find that people worry about trivial nonsense to mask their inability to address more valid concerns. All that really matters is consistency. Let a team make some decisions and then just move forward.

> All that really matters is consistency. Let a team make some decisions and then just move forward.

Not so! Amount of tokens correlates to perceived code complexity to some. One example is how some people can't unsee or look past lisps parenthesis.

Another example is how some people get used to longDescriptiveVariableNames but others find that overwhelming (me for instance) when you have something like:

    userSignup = do
        let fullName = userFirstNameInput + userLastNameInput
            userName = take 1 userFirstNameInput + take 10 userLastNameInput
        saveToDB userName
Above isn't bad, but imagine variables named that verbosely used over and over, esp in same line.

Compare it to:

    userSignup = do
        let fullName = firstName + lastName
            userName = take 1 firstName + take 10 lastName
        saveToDB userName
The second example loses some information, but I'd argue it doesn't matter too much given the context one would typically have in a function named `userSignup`.

I've had codebases where consistency required naming all variables like `firstNameInputField` rather than just `firstName` and it made functions unreadable because it made the unimportant parts seem more important than they were simply by taking up more space.

Re: Formatting code should be unnecessary

#394

Post by ParetoOptimal »

maest wrote: post #261
rapind wrote: post #256

Earlier quoted context omitted.

Let this sink in though: [ 'apple' , 'banana' , 'orange' ]

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.

Re: Formatting code should be unnecessary

#395

Post by rglynn »

giorgioz wrote: post #393

In Javascript there is Prettier which auto-formats the code on saving: https://prettier.io/ So essentially you stop caring about adding new lines or tabs, just press save and the code gets indented/formatted correctly.

I think the point is that:

A. not everyone on your team is using prettier

B. not everyone is using the same config/agrees on what it should be

Re: Formatting code should be unnecessary

#396

Post by MaxLeiter »

rglynn wrote: post #395
giorgioz wrote: post #393

In Javascript there is Prettier which auto-formats the code on saving: https://prettier.io/ So essentially you stop caring about adding new lines or tabs, just press save and the code gets indented/formatted correctly.

I think the point is that: A. not everyone on your team is using prettier B. not everyone is using the same config/agrees on what it should be

Yeah something I should have covered more is a lot of my frustration comes from the _tooling_ around formatting. Prettier is quite slow, people may not have it setup right, etc.

Re: Formatting code should be unnecessary

#397

Post by linhns »

numtel wrote: post #193

With how much LLMs do nowadays, I'm waiting for the time when specifying types is unnecessary. Like, it if can write code, shouldn't we also be able to have an AI type checker?

It writes better when correct type is specified beforehand. So chicken and egg problem you have.

Re: Formatting code should be unnecessary

#398

Post by gr__or »

theamk wrote: post #379
gr__or wrote: post #351

Earlier quoted context omitted.

Even that is not without its cost. Most of these tools are written in different languages, which all have to maintain their own parsers, which have to keep up with language changes. And there are abilities we lose completely by making text the source of truth, like a reliable version control for "this function moved to a new file".

At least the parsers are optional now - you can still grep, diff, etc.. even if your tools have no idea about language's semantics. But if you store ASTs, you _have_ to have the support of each of the language for each of the tools (because each language has its own AST). This basically means a major chicken-and-egg problem - a new language won't be compatible with any of the tools, so the adoption will be very low u…

The complexity of a parser is orders of magnitude higher than that of an AST schema.

I'm also not saying we can have all these good things, but they are not free, and the costs are more spread out and thus less obviously noticeable than the ones projectional code imposes.

Re: Formatting code should be unnecessary

#399

Post by stevedekorte »

Io (http://iolanguage.org) can work this way, as the message tree (maybe including comments - I don't recall) is what the interpreter used to evaluate the code and is accessible at runtime. However, it didn't store the choice of terminator (newline vs return) or indentation info (though it would be easy to add), so the pretty print of the message tree might look different depending on the source conventions.

Re: Formatting code should be unnecessary

#400

Post by bluGill »

mvieira38 wrote: post #327
kristopolous wrote: post #240

Earlier quoted context omitted.

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…

> This is most noticeable in open source contributions. Sometimes I'll get a pull request with like 2 lines of change and 120 lines of some reformating tool. This wouldn't happen nearly as much if you had a defined set of formatting rules plugged into CI instead of chaos

If the rule is not enforced in ci it isn't a rule. I've made that a mantra for a long time now and it helps. For a while I did verify formatting in ci but eventually we decided that formatiing wasn't as important as getting builds done fast. We still run other test and linters in ci and if they break fix the build but formatting isn't really that imbortant so we don't care. Yes our formatting is somewhat a mess but it isn't really that bad even after a decade of agreeing not to care.
Post reply on HN