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

301–310 of 484 posts

Re: Formatting code should be unnecessary

#301

Post by VBprogrammer »

Cthulhu_ wrote: post #202
VBprogrammer wrote: post #104

Earlier quoted context omitted.

Those kind of tables improve readability right until someone hits a length constraint and had to either touch every line in order to fix the alignment, causing weird conflicts in VCS, or ignore the alignment and it's slow decay into a mess begins.

It's not an either/or though. Tables are readable and this looks very much like tabular data. Length constraints should not be fixed if you have code like this, and it won't be "a slow decay into a mess" if escaping the line length rules is limited to data tables like these.

By length constraint I meant that one of the fields grows longer than originally planned rather than bypassing the linter.

Re: Formatting code should be unnecessary

#302

Post by maccard »

setr wrote: post #279
citizenkeen wrote: post #278

Earlier quoted context omitted.

Saying this is clearly superior means you don’t keep your lists sorted. A sorted list is as likely to add something to the beginning as the end, where this solution has the same problem.

The only correct syntax/format [ , a , b , c ] If only there existed a language designer intelligent enough to support it

You want yaml

    key:
      - a
      - b
      - c

Re: Formatting code should be unnecessary

#303

Post by thfuran »

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…

You have it entirely backwards. Enforcing a consistent format is useful precisely because it avoids pointless git noise from different people changing formatting differently as they go.

Re: Formatting code should be unnecessary

#304

Post by maleldil »

layer8 wrote: post #222
forrestthewoods wrote: post #62

Earlier quoted context omitted.

Define high? I think 120 is pretty reasonable. Maybe even as high as 140. Log statements however I think have an effectively unbounded length. Nothing I hate more than a stupid linter turning a sprinkling of logs into 7 line monsters. cargo fmt is especially bad about this. It’s so bad.

100 is the sweet spot, IMO. I like splitting long text as in log statements into appropriate source lines, just like you would a Markdown paragraph. As in: logger.info( "I like splitting long text as in log statements " + "into ” + suitablelAdjective + " source lines, " + "just like you would a Markdown paragraph. " + "As in: " + quine); I agree that many formatters are bad about this, like introducing an indent for…

Nitpick: this looks like Python. You don't need + to concatenate string literal. This is the type of thing a linter can catch.

Re: Formatting code should be unnecessary

#305

Post by zokier »

jillesvangurp wrote: post #288

There was a movement towards working with syntax trees directly and treating source code as a generated serialization of those syntax trees about 20-25 years ago. This probably started with refactoring as it was pioneered in the nineties. Things like Visual Age actually stored code in a database instead of on the file system. Later intentional programming (Charles Simonyi was pushing that) tried to also do things wit…

Meh.

> That stuff becomes a lot easier when the code representation isn't a bunch of files but the syntax tree

You are just mixing abstraction layers here. That syntax tree still needs to be stored in file(s) somehow, and nothing prevents having syntax tree aware (or smarter) tooling operating on human readable files. Basically deserializing AST and parsing source code are the same thing. The storage format really isn't that significant factor here.

So what is needed is better tools rather than fiddling with storage format. Microsofts Roslyn is obvious example, but plenty of modern compilers are moving in the direction of exposing APIs to interact with the codebase.

Re: Formatting code should be unnecessary

#306

Post by dghf »

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…

> 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

Re: Formatting code should be unnecessary

#307

Post by komali2 »

genericspammer wrote: post #225
account42 wrote: post #167

Earlier quoted context omitted.

So fix your setup? Why should others with wider screens leave space on their screen empty for your sake? Especially 80 characters is a ridiculously low limit that encourages people to name their variables and functions some abbreviated shit like mbstowcs instead of something more descriptive.

Do you guys never read code as side by side diffs in the browser?

Never mind in a browser, this is how I review a ton of code, either in magit or lazygit or in multiple terminals.

Re: Formatting code should be unnecessary

#308

Post by schneems »

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.

I learned to love rustfmt but there’s one thing that bothers me: There’s a few times where there are two ways to do something like a one line closure can omit the curly brackets, but multi line closures cannot. Rustfmt prefers to remove those brackets when it can, but I prefer to keep them, which makes editing the code faster since I don’t have a syntax error if I suddenly need a second line.

I can still live with it. And I like the clean, minimal version when I don’t have to edit. Just adding that “style” can have impact beyond how it looks involving ease of editing. And it stinks when your preferences clash with the community.

Re: Formatting code should be unnecessary

#309

Post by conartist6 »

IshKebab wrote: post #269
Jean-Papoulos wrote: post #128

So I need to run a tool to even be able to read the code. No thank you, if anything goes wrong your file is now garbage.

Doesn't seem like a real risk - these files are all version controlled. The bigger problem is you now need custom tooling for your IDE, version control, diff & merge, code review, code hosting, etc. etc.

You're spot-on. HTML and XML are similar textual embedding formats for documents which can contain arbitrary text. Neither is particularly good when the documents are syntax trees though. CSTML takes the design ideas that obviously work and adapts them to be natural for syntax trees, like this: https://gist.github.com/conartist6/75dc969b685bbf69c9fa9800c.... The trees always store inside themselves the complete source code as the parser saw it, so there's little fear of not being able to recover the original, and they're quite human-readable unlike, say, docx files. My team and I are working on building out the VCS, diff and merge, review, hosting, grepping, blogging and other kinds of solutions necessary to make our format able to take over as a de-facto standard.

Re: Formatting code should be unnecessary

#310

Post by Bender »

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.

I can see why people prefer particular styles so it's easier to read but on that note with Perl it was just perltidy flags. I can run perltidy on any code anyone here writes and it's easy for me to read, then I can pass it back to whomever and they can run perltidy with their favorite flags and it's easy for them to read. It probably doesn't quite work this way with all languages. I would imagine python being less flexible in this regard.
Post reply on HN