This makes me thinking, since world of coding has already reached the point of using zero-configuration fully automated code formatting tools on save/commit, why not make the final logical step — enforce coding style by language syntax, and be done with almost all extra burden of coding conventions.

Right now almost every company and even separate teams develop their own coding conventions document and configure their tools and infrastructure for it. But if all programmers agree that "coding style does not matter as long as it's consistent" and every one is willing to accept a project's coding style when joining that project, why not pick one style for all and put it into programming languages themselves. I imagine a lot of paperwork and human time would be saved.

We absolutely want one, but we've been actually developing the conventions first. You have to know what you want to format to!

Please tell me those discussions are on the mailing list.

I was on the rust mailing list for a little while about a year ago. Around that time there was discussion of this exact subject. Most of the discussion was around exactly how to break parameters beyond a certain length and so forth, but it was there.

They're actually RFCs. And the results are in a repository. I'm on mobile or I'd link you. But they generally codify already-existing style, rather than mandating it, although sometimes we just need a decision to tear down a bikeshed...

Ugh. I hate gofmt. It's a good idea in principle, but even with "go" there are times when you want things spaced out to align columns, or hide a distracting error handling case on one line (instead of making it take 3 lines of precious vertical screen real estate).

I find gofmt to be too opinionated about certain things and I will never use it for my go programs.

Why is it a good idea in principle then? Automatic reformatting of the source code always seemed like a bad idea to me for precisely the sort of reason you describe.

It focuses developers' attention on the things that really matter - what the code does, and how it does it - by removing how it looks from the equation.

The point of an automatic formatter isn't to make the code look pretty. It's to make the code non-ugly, with as little effort as possible. Obviously, there will be cases where the formatter screws up and writes out something pretty ugly. The point is to train yourself to ignore these, because honestly time spent looking at, angsting over, and fixing bad formatting is about the worst possible use of your development time. Instead you could be thinking about solving a problem that hasn't been solved before, or making the product easier for a user to use, or refactoring semantic issues in the code that trip up developers.

Well it builds canonical standards without community strife, which removes one point of contention.

That seems good in theory.

It's good enough when you can configure it and apply it selectively. If I want to clean up a function in my code base, I can e.g. select it and run "perltidy" over it, which has a configuration dot file for the company code standard (or CPAN guidelines etc.).

Or just clean up some nags so that version control behaves better. But if the only option is not running it at all or having all the code automatically fit to whatever the people On High have deemed to be visually pleasing? Yeah...

It's irksome when the auto formatter does something ugly. Though, I think the issue is far worse with Perl tidy. With, gofmt my view is more "I don't like this bit but fuck it." Probably because, Go has much simpler syntax.

Both languages (being bastard children of C) often run into exactly the same problems, where the syntax doesn't differ greatly. If you e.g. are accustomed to having indentation without tabs, margins within function calls or prefer non-tabular variable declarations, you can have that in C, Perl, Pike, Java, etc..

I absolutely love go fmt. It's got me spamming ctrl+s in sublime text so much. Everything is clean and uniform.

gofmt is a huge win for Go. Bye bye bikeshedding. I'd love to see that for Rust too.

I haven’t tried Go yet, but gofmt seems like something that every new language should strongly consider.

FWIW, C++ already has it with clang-format

clang-format is amazing. I think it can format more languages than just C++ too. For example js, I think?

Yes; there are also efforts for Java, AFAIK

Splendid!

There has been talk of it, and one of the core team members had a prototype. It's most definitely something to look at this year.

indent(1) has been around for ages. Where does this sudden need for universal style goose stepping come from?

1) A lot more code isn't read in vim or emacs nowadays. We don't have the equivalent of indent on the github web ui

2) Everyone and their mother is doing code reviews now, and a lot of code reviews get (very visibly) bogged down by style disputes.

3) indent and his modern friends (eg clang-format) generally only answer trivial whitespace questions, and not even things like method capitalization. gofmt is the obvious extension of indent.

Whether it's called indent, gofmt or Visual Source Formatter 2051 doesn't really change its availability. Nor does it really matter a lot how much of the source is munged -- every forced change is probably annoying to someone.

The main issue for me is that your code reviwer isn't looking at the code from my company. So why should I give a damn what they think about how spaces around the parens of a function call should look like in the code I'm editing?

I'm not convinced that this should leave the bounds of a project. Within that, sure! Let's put a .rustformat right next to .gitignore, and whatever your source discombobulation utility is called just takes its hint from there. Certainly nothing wrong with a language having a good indenter, doc tool and linter in the core distribution. But one language, one style, one tab width!?!

This is especially annoying when you've got a pretty unified style across all other algol-/C-ish languages, yet can't keep this in your newest one. For the sole reason of pleasing some community that'll never see one line of your code.

> This is especially annoying when you've got a pretty unified style across all other algol-/C-ish languages, yet can't keep this in your newest one. For the sole reason of pleasing some community that'll never see one line of your code.

It's rarely a good idea to reproduce the same patterns in two different languages (except for things that are common anyway, like indentation etc.).

And the main argument for a language-global code style is that you don't need to teach new commers (to your company/project) which code style you follow, you don't need to have long discussions about whether the article #36 is being respected in that last commit, if the code style version you had is up to date, etc.

One great example: Python and PEP8. It's the standard, everybody accepted it. That means that all libs use it AND (almost) all companies use it internally, which makes friction between different modules from different sources minimal.

I think you're kind of missing the point.

The point isn't to have a "house" style, it's to have an "everything" style.

Making it optional or configurable defeats the purpose.

That depends on your purpose and the problem you are trying to solve. If the problem is style bikeshedding, that can easily be solved through autoformatting and configurations for the standard for that project, company, etc. Write however you want, run it through the auto-formatter with the right config before commit (or add it to commit hooks). Problem solved.

If you want to solve the problem that people are writing in different styles and there should be one true style for a language, why? You're bound to get something wrong in your style initially, and it will be annoying from then on, and hard to change. It actually seems the antithesis to how Rust was developed, which was to keep trying things to see what worked.

You then bikeshed what should go in the configuration file, which is almost as bad.

And gofmt is generally less bound to the style than, say, PEP8 since everyone could trivially mechanically update their source to the new standard.

Indeed, I am missing said point. Version control snafus aren't really an issue outside of my project, so it all comes to the endless repetition of "bikeshedding".

All kept equal by hatchet, ax and saw…

indent(1) is not idempotent, at least not in the configuration I tested, which makes it practically useless as an editor save hook or an SCM pre-commit hook.

Of all the C pretty-printers I tried (about a year ago), clang-format came closest but none were idempotent on the codebase I threw at it.

go fmt is idempotent, which means I use it in an editor save hook. I got used to the convenience, so now I miss an automatic formatter when writing other languages.

Are you sure you're not exaggerating the benefits of an automatic formatting tool? I'm thinking that a large number of libraries, usage by multiple high-profile companies, a killer app, etc. would be better for Rust at this point.

gofmt is nice.

gofix: way more useful!