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

291–300 of 484 posts

Re: Formatting code should be unnecessary

#291

Post by eviks »

pasc1878 wrote: post #270
eviks wrote: post #58

Earlier quoted context omitted.

> If initial space width was configurable in their editor of choice, would those who prefer tabs have any other arguments? Yes, of course, because tab width is * dynamically* flexible, so initial space width isn't enough

Yes because if you want to deindent with tabs it is just delete one character whilst spaces requires you top delete x characters where x is the number of spaces you indent by.

For "clean-fixed-width" unambiguous indent (eg, at the beginning of lines) you can make delete also delete X=indent_width spaces.

But for "dirty-width" indents, eg, after some text that can vary in size (proportional fonts or some special chars even in fixed fonts) you can't align with spaces while a tab width can be auto-adjusted to match the other line

Re: Formatting code should be unnecessary

#292

Post by carlosjobim »

skinner927 wrote: post #75
forrestthewoods wrote: post #61

Earlier quoted context omitted.

I’ll go a step further. I’ve never understood why people care so much about the linter. Just let people write code and don’t worry about the linter. I don’t need to fight a linter which makes my code worse when I could just write it in a way that doesn’t suck. I promise it’ll be fine. I’m too busy doing actual software engineering to care if code is not perfectly formatted to some arbitrary style specification. I fee…

The point of linters is so the code looks the same regardless of who wrote it. This way it’s easier to read. Some people have horrible style and linters really help. I find linters make me faster. Sometimes I’m feeling lazy and I just want to pump out a bunch of lines of ugly code with mappings poorly formatted, bad indents, and just have it all synched up when I save.

I see no reason to accommodate to worthless programmers who aren't able to read or format the code that's sent to them. They can lint it themselves if they want.

Re: Formatting code should be unnecessary

#294

Post by Skeime »

aleph_minus_one wrote: post #287
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…

> 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…

But the second interpretation only makes sense if the last item somehow deserves special treatment (over, say, the second-to-last item). Otherwise, you should similarly argue that the previous second-to-last item should also show up in the changes as it has now turned into the third-to-last item. (So maybe every item in the list should be preceded by as many spaces as are items before it and succeeded by as many commas as are items following it. Then, every change to the list will be a diff of the entire list.)

    first item,,,
     second item,,
      third item,
       fourth item
In my experience, special treatment for the last item is rarely warranted, so a trailing comma is a good default. If you want the last item to be special, put a comment on that line, saying that it should remain last. (Or better yet, find a better representation of your data that does not require this at all.)

Re: Formatting code should be unnecessary

#295

Post by delusional »

balamatom wrote: post #266
delusional wrote: post #227

Earlier quoted context omitted.

> So fix your setup? Why should others with wider screens leave space on their screen empty for your sake? What a terrible attitude to have when working with other people. "Oh, I'm the only one who writes Python? Fix your setup. why should I, who know python, not write it for your sake?" "Oh, I'm the only one who speaks German? Fix your setup. Why should I, who know German, not speak it for your sake?" How about doin…

What do you do about the "oh, I'm the only one who cares about [???] ? should I just fucking kill myself then?" Many such cases. >How about doing it because your colleagues, who you presumably like collaborating with to reach a goal, asks you to? If a someone wants me to do a certain thing in a certain way, they simply have to state it in terms of: - some benefit they want to achieve - some drawback they want to avoi…

> If, however, someone insists on certain approaches while never going deeper in their explanations than arbitrary non-falsifiable qualifiers such as "best practice", "modern", "clean"

You're moving the goalposts of this discussion. The guy I was responding to said "fix your setup" to another person saying "Your table wrapped for me. The short line equivalent looks best on my screen." That's a stated preference based on a benefit he'd like to achieve.

We are not discussing "best practice" type arguments here.

Re: Formatting code should be unnecessary

#296

Post by [deleted] »

aleph_minus_one wrote: post #287
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…

> 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…

[deleted]

Re: Formatting code should be unnecessary

#297

Post by stared »

There are multiple ways to write exactly the same program. Linters are able to reduce this number by moving to some canonical version.

With modern tools it it is easy to add formatting on saving or on commit. So I don't understand what's the fuss about.

At the same time, for the most important tool in software engineering, Git, it matters which lines are changes. And it is better to only see actual logic changes, not swamped in tabs vs space or other parts that are just formatting.

That said, I would love to see more of this splitting between actual internal representation and view. Don't like anything in style guide (or even syntax alike curly brackets vs indentions) - just change view, alike folding.

Re: Formatting code should be unnecessary

#298

Post by cluckindan »

fridental wrote: post #293

Typing keywords letter by letter is unnecessary too. Think about ZX Spectrum keyboard allowing you to type BASIC keywords with just one key press.

Or think about the M (aka MUMPS) language, which allows you to type just the first letter(s) of a keyword and considers it valid syntax.

Imagine Java if you could…

    na com.mycompany.myapp;
    
    pu cl MyClass {
      pro sta i = 42;
    
      pri fi ch[] MAGIC = ['a', 'b'];

      pu sta v main(String[] args) {
        OtherClass otherClass = n OtherClass();
        f (i i = 0; i

Re: Formatting code should be unnecessary

#299

Post by galangalalgol »

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…

Avoiding that situation is what I like about formatters. As long as the language has an obvious standard like rust or go.

Re: Formatting code should be unnecessary

#300

Post by mindwok »

carlosjobim wrote: post #292
skinner927 wrote: post #75

Earlier quoted context omitted.

The point of linters is so the code looks the same regardless of who wrote it. This way it’s easier to read. Some people have horrible style and linters really help. I find linters make me faster. Sometimes I’m feeling lazy and I just want to pump out a bunch of lines of ugly code with mappings poorly formatted, bad indents, and just have it all synched up when I save.

I see no reason to accommodate to worthless programmers who aren't able to read or format the code that's sent to them. They can lint it themselves if they want.

It's not about accomodating people, it's about consistency in codebases when many people with different preferences or styles are working on it. You just eliminate the cognitive overhead so people can develop intuition about how the code works and flows.
Post reply on HN