Should we build a code formatter as a community?

#1

I’m liking a lot rescript. It’s a wonderful effort to make reasonml simpler, and I’m really satisfied with the ecosystem and the seamless introduction of the language into a js / ts codebase.

However, the thing that makes my code really hard to read is the current formatting situation that we have. I find this really hard to read and edit:

  getCategory(id)
  ->thenResolve(category => {
    category["path_from_root"]->Array.get(0)->Option.map(category => category["name"])
  })
  ->catch(_ => resolve(None))

Compared to this:

getCategory(id)
  ->thenResolve(category => {
    category["path_from_root"]
      ->Array.get(0)
      ->Option.map(category => category["name"])
  })

Note that I’m a vim user, so moving and editing parts of the pipelines is easier when they are split in lines. There are more examples with jsx that the same applies.

It’s been months since there’s no improvements in this area, and I get it, the current team is busy with other things. Therefore, is it worth it to build a rescript formatting tool, or is the rescript format api coming with more customizations?

2 Likes
#2

There is an open issue for this: Smart linebreak printer for pipe chains · Issue #257 · rescript-lang/syntax · GitHub
I think it is more productive to submit a PR, instead of creating a separate formatter.

6 Likes
#3

Hum, I just read about how to do a pretty printer. Apparently is far more difficult than I thought :smiley:

Really interesting reads for anyone interested:

http://journal.stuffwithstuff.com/2015/09/08/the-hardest-program-ive-ever-written/

2 Likes
#4

However, the thing that makes my code really hard to read is the current formatting situation that we have.

I agree, I’ve been trying to use the default formatter this last week but these long lines are making my code pretty difficult to read, I’m ready to disable it

It happens with JSX elements too, which I almost never want on the same line

  <div className={Css.pageModal}>
    <NavBar> <NavBar.Back /> <NavBar.Title> {React.string("Create Game")} </NavBar.Title> </NavBar>
    <div className={contentClass}>

vs

  <div className={Css.pageModal}>
    <NavBar> 
      <NavBar.Back /> 
      <NavBar.Title> 
        {React.string("Create Game")} 
      </NavBar.Title> 
    </NavBar>
    
    <div className={contentClass}>

I wish at a minimum there were config options, similar to eslintrc, to where we can disable certain parts of the formatter.

#5

This is an example where someone from the community could first gauge interest and do some experimentation. See if there are gotchas, ux/dx or implementation issues. Prepare enough examples and present them to the community for feedback.
An area with no scarcity of opinions normally.

2 Likes
#6

At least there should be a code standard - a must for any enterprise or bigger project.

Variable, module and function naming is sadly not possible to inspect statically, but there should be a standard for that too. OCaml has conventions for this, like string_of_int C-style, UPPERCASE for module signatures, CamelCase for modules, using t for the base type in a module, etc.