Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming

Rust Programming Language Announces New Team to Evolve Official Coding Style (rust-lang.org) 66

Posted by EditorDavid from the Rust-never-sleeps dept.
"The Rust programming language is getting so popular that the team behind it is creating a team that's dedicated to defining the default Rust coding style," reports ZDNet: Each language has style guides and, if they're popular enough, may have multiple style guides from major users, like Google, which has its guide for C++ — the language Chrome is written in. Python's Guido van Rossum's posted his styling conventions here.

Rust, which reached version 1.0 in 2015, has a style guide in the "rustfmt" or 'Rust formatting tool' published on GitHub. The tool automatically formats Rust code to let developers focus on output and aims to reduce the steep learning curve confronting new Rust developers. The guide instructs developers to "Use spaces, not tabs" and says "each level of indentation must be 4 spaces", for example....

But the team responsible for writing the style guide between 2016 and 2018 has "by design" come to end, so now it's now been decided to create the Rust style team, consisting of Josh Triplett, Caleb Cartwright, Michal Goulet, and Jane Lusby. The crew will first tackle a "backlog of new language constructs that lack formatting guidance" and move on to "defining and implementing the mechanisms to evolve the default Rust style, and then begin introducing style improvements."

The work includes minor language changes, big structural changes, and backwards compatibility and the style team wants to craft the tool to make it current for easier coding in Rust, and help adoption.
New constructs "by default, get ignored and not formatted by rustfmt," according to a blog post by the Rust style team, "and subsequently need formatting added. Some of this work has fallen to the rustfmt team in recent years, but the rustfmt team would prefer to implement style determinations made by another team rather than making such determinations itself."

The post also notes that the backwards compatibility maintained by rustfmt "also prevents evolving the Rust style to take community desires into account and improve formatting over time." rustfmt provides various configuration options to change its default formatting, and many of those options represent changes that many people in the community would like enabled by default... but [rustfmt] cannot make this the default without causing continuous integration failures in existing projects. We need a way to evolve the default Rust style compatibly, similar in spirit to the mechanisms we use for Rust editions: allowing existing style to continue working, and allowing people to opt into new style.

To solve both of these problems, RFC 3309 has revived the Rust style team, with three goals:

- Making determinations about styling for new Rust constructs
- Evolving the existing Rust style
- Defining mechanisms to evolve the Rust style while taking backwards compatibility into account

We don't plan to make any earth-shattering style changes; the look and feel of Rust will remain largely the same. Evolutions to the default Rust style will largely consist of established rustfmt options people already widely enable, or would enable if they were stable. We expect that the initial work of the style team will focus on clearing a backlog of new language constructs that lack formatting guidance. Afterwards, we will look towards defining and implementing the mechanisms to evolve the default Rust style, and then begin introducing style improvements.
This discussion has been archived. No new comments can be posted.

Rust Programming Language Announces New Team to Evolve Official Coding Style More

Rust Programming Language Announces New Team to Evolve Official Coding Style

Comments Filter:

  • .... there shouldn't be an "official" coding style. If you want to make people write code in a specific layout then enforce it in the language parser like Python with its whitespace, otherwise butt out and let people make their own choices.

    • Re:In a freeform language... (Score:5, Insightful)

      by sg_oneill ( 159032 ) on Saturday October 08, 2022 @12:20PM (#62949267)

      Ok guy whos never worked in a team before.

      Style guides are good things. Theres nothing more incomprehensible than code maintained by 4-5 people each with their own whackadoodle idea of how to format code.

      • Source code formatting is very low on my list of factors for maintainable and reliable code. Put whatever you want in the .editorconfig file to end the bike-shedding, and start writing code.

      • Style guides are good things. Zero-exception enforcement is terrible.

        The point of a coding style is to promote easier understanding of the code for humans while making it easier to spot errors. There are times where "special case" formatting makes the code much easier to understand and requiring it to be formatted in a way that makes it harder to understand is stupid.

        Also, if your language requires compliance to an official style guide, it's garbage.

        • Re: (Score:2)

          by tap ( 18562 )

          But auto formatters are always zero exception. Make a readable table, with one item per row and columns that line up, and then the auto-formatter will come pack everything to the line length limit and wrap it where ever. Becomes unreadable.

          I think the reason some people need zero-exception strict style guides is that they can't actually write code in any kind of style themselves. Don't even know what the space bar, tab key, and enter key are for. The must have an auto formatter do this for them. It's l

          • That is why good formatting tools allow you to add a flag to skip sections of the code. With the ubiquitous use of widescreen displays, I always turn off line length in all code formatting tools I use anyway.

            • Re: (Score:1)

              by Anonymous Coward

              With the ubiquitous use of widescreen displays, I always turn off line length in all code formatting tools I use anyway.

              That's you being short-sighted. They're not ubiquitous, and even if they were, assuming all of them are in use in landscape mode is just as silly and restricting on those of us preferring more vertical than horizontal space.

              I for one have one 5:4, three 4:3, and no widescreens in use. But even if, my default xterm size would still be 80 columns, possibly switchable to 132.

              The reasons to stick with 80 columns have little to do with the display: Very long lines aren't easy to read, the optimum seems to be a

        • Re: (Score:2)

          by flux ( 5274 )

          You can mark sections of code that avoid autoformatting. And it's certainly useful at times, when e.g. a table layout for constants work out great.

      • Style guides are good things.

        I don't entirely agree. Automatic style enforcement is a good thing. They are great at squelching the vast amounts of tedious bikeshedding that goes on arguing about style minutiae on every single PR.

        Theres nothing more incomprehensible than code maintained by 4-5 people each with their own whackadoodle idea of how to format code.

        For me only if it's truly whackadoodle. GNU style guide, lookin' at you...

        As a certified old fart by the standards of IT, I've worked in enough differ

        • As a certified old fart by the standards of IT, I've worked in enough differently formatted codebases that I just forgot to care any more.

          This is pretty much me as well. Where I work we have an "official" corporate style guide which I follow for new projects, but we also do a lot of sustainment work on stuff that came from acquired companies that did things their own way, and no one's going to go back through and change thousands of lines in an established avionics firmware package that was tested and sig

          • Where I work we have an "official" corporate style guide which I follow for new projects, but we also do a lot of sustainment work on stuff that came from acquired companies that did things their own way, and no one's going to go back through and change thousands of lines in an established avionics firmware package that was tested and signed off years ago just to make it jive with the style guide.

            I too work on a codebase that's been amalgamated from a bunch of in house teams, predating the current guides pl

        • Agreed. I guess I forgot to care any more too. I have worked in projects with different colleagues doing different styles - its OK - I can tell at an instant who wrote the code, and an an effective filter for all the Hungarian crap people insist on. If indents get to messed up, my editor has a quick reformat function.

          Where I've worked with project with extensive style guides, apart from what is enforced by a style linter, just leads to continual argy-bargy in code reviews. So tedious. Who can remember all

      • Re: (Score:3)

        by dargaud ( 518470 )
        I have an editor that formats everything to my preference at the strike of a key. And can revert back when I commit. I absolutely hate the favorite format of my best colleague: he puts basically 5 empty lines for every line of code (one code, one or 2 just brackets, one or 2 for comments). I HATE being forced to page-up page-down continuously to read the code, I need it more compact so more of it is in sight.

      • I was working into teams probably before you were born feotus. I'm simply saying the language authors should stay out of it.

        • No, they shouldn't stay out of it.

          Almost every project in the real world has a coding style standard, and you're stuck adjusting to that no matter what.

          Every time you switch jobs or even projects within one company, now you've got to adapt to a different set of rules even if you're using the same language. That's a royal pain in the ass. It's better to just have one universal coding standard. An added advantage is that only one small team of language developers have to waste time haggling over exactly what

          • Re: (Score:2)

            by Viol8 ( 599362 )

            There's no point having freeform languages if you have One True Coding Style. Also certain coding styles such as mil spec ones can be rather awkward and wouldn't be popular in commercial enviroments.

            • There's no point having freeform languages if you have One True Coding Style

              Why not? Take the example of Go, one of the most recent popular languages. It has one true coding style, and that gets enforced by the formatter utility, not the compiler. It was created by industry bigwigs with decades of experience. What makes you think that they are wrong and you are right?

              Also certain coding styles such as mil spec ones can be rather awkward and wouldn't be popular in commercial enviroments.

              At least the military gave up on creating new programming languages out of whole cloth and then foisting them on everyone, but they obviously have more work to do.

      • Sure, people who work together closely should use a common coding style. But the style shouldn't be enforced by the language; it should be the choice of the team, company or project, based on their own culture, history, the tool sets they use, general company-wide rules and so on. There are many factors that drive the choice of a particular coding style for a particular project, and the language team has access to none of them.

        In the end, all the language team should do is suggest some guidelines, while ma

    • Re: (Score:3)

      by tlhIngan ( 30335 )

      .... there shouldn't be an "official" coding style. If you want to make people write code in a specific layout then enforce it in the language parser like Python with its whitespace, otherwise butt out and let people make their own choices.

      Why not? Why not have an official style used internally by the team to ensure consistency?

      And then use the official style in the documentation when showing examples, as well, so all the examples have a uniform look.

      Just because the language lets you put brackets and brace

    • Styleguides are like roads, bridges, and sidewalks (Score:4, Interesting)

      by Somervillain ( 4719341 ) on Saturday October 08, 2022 @07:18PM (#62949935)
      Styleguides enforce naming conventions and even some basic best practices that a linter can't. Culture matters more than technology. Java is the dominant business language for at least 20 years now despite being challenged by many superior languages and platforms during it's era. IMO, what separated Java from it's competitors was its culture.

      Nearly all Java written in the last 25 years looks the same because in 1997 Sun created a coding standard that is universally enforced. All methods and variables use camelCase. All constants are in UPPER_CASE. Only one variable declaration is allowed per line. It annoyed me when I started learning it, but I grew to appreciate it when I inherited code from someone I have never met who left the company.

      I get code from people across the globe who I have never met and often no longer are employed at my employers. I can read it effortlessly.

      JavaScript? not so much...Python?...oh, hell, no!!!! I've seen some Python that is sensible and some that looks like it was coded by drunk monkeys. If there is a coding culture in Python, apparently no place I've ever worked at has hired developers who know what that is.

      People hate on Java because it can be verbose and it is constricting, but that constriction means you spend more time thinking about business and less about trying to figure out what your coworkers are doing. Coding conventions and general culture are like sidewalks, bridges, and roads. They make everything easier and more efficient. You technically don't need them, but you'll get a lot more done a lot faster and more safely with them. If Rust wants to be a serious language for people who actually make money, they need a strong culture more than strong technology. No one cares if your code runs 5% faster if it costs 5x as much to write and is delayed 5x as often and has 5x as many bugs introduced by developers not communicating well with one another.

      • Being verbose while trying to figure out web standards in a language that changes to accommodate web standards? Every time a new library is thought up your old logic blows up. I'm not a java person though....to me java is actually all style and politics. But then you don't write device drivers with it either.....

  • Hopefully we can finally be treated like adults and have tabs be the default.

    Clinging to the argument of universal formatting is weak. We have good tools and deserve a world that can better cater to the end user-preferences. gofmt has done the world a service by demonstrating how practical and scalable this choice was.

    Also, accessibility matters [reddit.com].

    • I almost want to sponsor a study to see how much more energy and cumulative storage is required for spaces vs. tabs. Those extra bytes aren't free!

      (I've never encountered, in more than twenty years of software development, a serious issue arising because code "wasn't readable due to formatting". Maybe I'm spoiled by working with people who can understand code regardless of an odd space here or there? Or perhaps because we relied on static checkers and actually read warnings, and had robust unit and integra

      • I've never encountered, in more than twenty years of software development, a serious issue arising because code "wasn't readable due to formatting".

        Indeed, a good programmer will be amendable to variation, but there is research that has quantified the level to which this slows down a developer and it's not nothing, increasing inverse to experience (sorry I don't have enough time to dig it up right now). Further, it's important to consider that in today's world, developers work on more codebases and their positions are more fluid than ever before. The person that wrote a project may not even be on the team a year later, and no one knows the skill level

      • By all means do the math, but from a practical standpoint it just doesn't matter. You can always just convert (which can probably be distilled to a single command or click in your IDE) and then convert back again, so you can work with whatever your preference is.

        I prefer to use all spaces and no tabs, unless I'm using a word processor or other DTP software and I am defining my own tabs for columnar purposes. Then the tab key does what I actually want it to every time, and I can also have half-indents if I w

    • Re:tabs by default (Score:5, Insightful)

      by narcc ( 412956 ) on Saturday October 08, 2022 @12:52PM (#62949323) Journal

      Hopefully we can finally be treated like adults and have tabs be the default.

      That link is very sobering. Unfortunately, the summary makes it clear that tabs are out.

      From your link, for the benefit of others who won't bother to click:

      Nobody talks about the real reason to use Tabs over Spaces
      i've been slightly dismayed, that in every tabs-vs-spaces debate i can find on the web, nobody is talking about the accessibility consequences for the visually impaired

      let me illustrate with a quick story, why i irrevocably turned from a spaces to tabs guy

              i recently worked at a company that used tabs

              i created a new repository, and thought i was being hip and modern, so i started to evangelize spaces for the 'consistency across environments'

              i get approached by not one, but TWO coworkers who unfortunately are highly visually impaired,
              and each has a different visual impairment

                      one of them uses tab-width 1 because he uses such a gigantic font-size

                      the other uses tab-width 8 and a really wide monitor

                      these guys have serious problems using codebases with spaces, they have to convert, do their work, and then unconvert before committing

                      these guys are not just being fussy — it's almost surprising they can code at all, it's kind of sad to watch but also inspiring

              at that moment, i instantaneously conceded — there's just no counter-argument that even comes close to outweighing the accessibility needs of valued coworkers

      [...]

      is there really any reason, in favor of spaces, that counter balances the negative consequences for the visually impaired?

      cheers friends,

      Chase

    • I too bemoan the overtaking of software by the space cadets.

      Lost in this debate as always, as each camp attempts to place blame on the other, is where the blame really ought to be: The editor.

      I get the universal formatting argument. My tab expansion may not be yours. The other side doesn't get the ease of editing argument--the cursor tapping through all your spaces is annoying.

      The solution is simple: When loading the file, the editor should analyze the indentation and check to see that it follows a patt

      • I propose a similar, yet different solution: auto-format to your preference on pull / clone / checkout ( IDE formatter ) and auto-format to the guidelines on commit ( commit hooks ?).

        Best of both worlds.

        • Yes! A source control script might be an even better option, since AFAIK you could deliver this feature to almost everybody with just a few source control systems, whereas there are a lot more editors. If you patch svn, git, and good ol' cvs, you cover what... 95% or more of developers? Sure there is probably a long tail of version control systems too, but if you got a feature like that in to the top 3 the rest would catch up. Additionally they tend to be F/OSS whereas MS's development environment is cl

  • Rust only has two major issues: Its conceptual design, and its implementation.

  • I like how "some people from an esoteric language have decided to extend an existing style guide to cover new language features" is considered as newsworthy here.

    Can I also submit an article whenever I plan to cut my toenails or swipe my terrace?

    • Can I also submit an article whenever I plan to cut my toenails or swipe my terrace?

      Sure, if your toenails are being used in the Linux kernel.

    • Re: (Score:2)

      by HiThere ( 15173 )

      Rust isn't that esoteric. I've tried it twice. The first time I bounced (poor language documentation), Recently I tried again, and this time I managed it. Well, in the sense that I could actually do what I tried to do. But the libraries I need still aren't present. I'd do better with go, though I hate their development environment. Eventaully, though, I narrowed things down to Python or Java, because of the ability to have the same program run on different systems. Currently I'm trying Java, even th

  • Fine, but don't put too much effort into it. Let organizations define their own style rules, and automate them using standard tools.

    Different groups have different ideas, and sometimes genuinely different needs.

  • They chose to codify using spaces versus tabs for indenting, which just reeks of amateur hour. It's what drives me crazy about Python, where it's even worse when people do that because of the silly way Python treats whitespace as flow control. Merging different codebases is a nightmare. With tabs, no one cares that your editor is setup for 4 spaces per tab and theirs is set up for 2, it all just looks like everyone thinks it should and it works. Spaces are inflexible, and there's no good argument I can make

    • Amateur hour to enforce spaces? In all my 20yr professional life as a developer I've only ever seen enforced spaces. I don't think "amateur" is the word you're aiming for.

  • The ewhac 2021 C Coding Style Guide. [ewhac.org] Adopt no substitutes.

    I've been fiddling with Rust off and on for the last year, and I'm still trying to work out how I want the code to look. Naturally, my preferences are informed by my preferences in C coding style, but one principle, I think, stands above all others:

    Don't make me hunt for important things.

    Rust's syntax is very fiddly and has lots of details, most of which are significant. It will be a challenge to work out a style that lets all of those det

    • Re: (Score:2)

      by gweihir ( 88907 )

      Don't make me hunt for important things.

      One of the fundamental principles: Make everything important obvious. If it is not by itself, add something to make it as obvious as it should be. That is, for example, why an emergency shut-off is a big red button easily visible and usually breaking the aesthetics.

      Rust's syntax is very fiddly and has lots of details, most of which are significant.

      That does not sound good. In fact is sounds like an accident waiting to happen, especially in this combination. Second-system-effect?

  • If it's being defined by a committee, then it isn't really "evolving", is it? Wouldn't that be more of a ground-up, organic sort of process?

  • Because that one is wayyy more important than some technical details, right?

    Seriously, all this shows is how immature that language is.

  • Unenforced code style boosts creativity and personal expression (art).

  • I know this is just a guide, but, if you want to recommend or enforce a style, make it part of the language definition; that's not difficult.

    As several people have already said, you can always run a program you don't like through a formatter to achieve any desired format, and there are probably programs to rename non-global variables to conform to your chosen convention.

    As also said, this is all bike-shedding; the real thing that needs control, and is hard, is stopping bad programmers writing bad code. Som

  • Anyone that sits down and thinks "the best use of project time is to write a document telling everyone else to type their code the way I like it" should be removed from the project and never, ever, allowed back in.

    We're not punching Fortran into cards anymore; our team can use the style that we like and you can stuff yours where the sun never shines (Belfast).

  • I have seen arguments, I literately asked my professor, but never gotten a real reason.

    Tabs, by definition are literally the exact thing you want for indentation, they are indentation by definition. A system and program independent universally recognized indentation. Any uses of spaces is literally just hacked together sort of tab emulation. At the end of the day it looks identical, but is just harder to work with, transfer files between people, needs way more back end coding to work right, and literally bl

    • In my experience, the main reason is that tabs are interpreted inconsistently across different tools. What looks good to me will look terrible to someone else.

      • I see.
        While your code might look stupid to you on your peer's computer, Would it not look good to him?
        Or is it that 4 spaces looks better in notepad or Microsoft Office than 1 tab?

        • The problem is that tabs are historically 8 spaces but people want to use them to mean 4 spaces sometimes and this only causes problems.

          If you use tabs and want them to work reliably they have to be 8 spaces, and 4 spaces seems to be the optimal indent level for code.

    • Re: (Score:2)

      by kackle ( 910159 )
      I don't care what people use and am not up to debating, but I will use spaces unless forced otherwise. It is mostly preference: I write mostly firmware and code comes from and goes to all kinds of platforms in my career. And I use multiple development machines (some not mine!), often with very old editors*. So, for legibility, I prefer that a space is always and everywhere a space--I don't have time to fiddle with multiple, ephemeral editors' settings. Tabs seem too variable for such an exacting science

Slashdot Top Deals

As long as we're going to reinvent the wheel again, we might as well try making it round this time. - Mike Dennison

Close