The way ocamlformat formats

ocamlformat

#10

I disagree, reading should always be favored.


#11

I could get used to all sorts of things. I have become accustomed to migraines for example. However, I see no reason to get used to something that I don’t like, unless of course it is unavoidable because it was imposed upon me by fate.

Therefore, you will have to show me there’s a benefit here. If you want me to voluntarily adopt this style, you will have to convince me to do so of my own volition, and so far, I’ve seen little that convinces me I would like to do so.


#12

We mostly fall into the punctuation-on-the-left camp. It’s hardly a settled question, but there are a lot of both styles in OCaml code out there. The argument we’ve had for putting the punctuation on the left is to make it easier to visually scan and understand the structure of the code. Note that this is consistent with the agreed-upon syntax for pattern matches and variant declarations.

I don’t really agree with that. , and ; are postfix separators (and you can add ; after the last item), whereas | in a normal pattern match is a prefix separator (you can and should add one before the first branch). So I put ; at the end of each line, including the last one, which is the most consistent with putting | before each branch of a match.


#13

I completely agree with @perry and @dbuenzli’s comments above. if you want ocamlformat to take over, you have to get community buy-in. The only way that’s going to happen is if the decisions ocamlformat makes match those made by the majority of code people in the community see and use. Imposing a new style that doesn’t exist and isn’t agreed upon is not going to work and ocamlformat will just remain an esoteric tool used by a small section of the community, as it is now. This is particularly true since we have another tool - ocp-indent - that does satisfy the community’s standards. Since ocp-indent is well accepted, it seems to me that ocamlformat should strive to match ocp-indent wherever possible, and then offer the additional benefits that full parsing offers on top of that.


#14

Some efforts are made to make ocamlformat more customizable. Some of the comments of this thread match existing issue (and even PR’s) on the github.

It will soon be possible to not start a line with a separator (https://github.com/ocaml-ppx/ocamlformat/pull/461).
It is also possible to reduce the number of spaces between parentheses (https://github.com/ocaml-ppx/ocamlformat/pull/429).

(Contributions are welcomed)


#15

ocamlformat is able to read ocp-indent config files, and they are various efforts to have both tools be compatible, including automatic tests. If you find any difference in the output of the two tools, you are welcome to report an issue on the bug tracker.


#16

I’d like to bring up that in this style, the indentation of the list of record fields is 4 rather than 2. The hypothesis is that a consistent offset between blocks of important material is more readable than otherwise.

module Model = struct
  type t =
    { symbol : string
    ; edge : float
    ; max_edge : float
    ; bsize : int
    ; bid : float
^^
  ^^^^

Shifting the fields to the left gives us:

module Model = struct
  type t =
  { symbol : string
  ; edge : float
  ; max_edge : float
  ; bsize : int
  ; bid : float
  }
^^
  ^^

It’s also an argument against these styles:

module Model =
  struct
    ...
  end

type t =
  {
    ...
  }

type u = { foo : int;
           bar : float }

Frankly, I strongly prefer this:

module Model = struct
  type t = {
    symbol : string;
    edge : float;
    max_edge : float;
    bsize : int;
    bid : float;
  }
end

The main arguments I find relevant when discussing this style are:

  • Indentation of stuff that matters should be consistently 2 for readability (the argument above).
  • Leading semicolons look like a gratuitous oddity.

#17

I strongly agree. That indentation style feels much more natural and readable to me.


#18

I have been working in Elm for a couple of years where the agreed style is like:

{ symbol : string
; edge : float

From my experience, having the first element different is quite annoying, anything to do with the first element requires unnecessary extra operations, and sorting is a pain.

In Elm this style is mostly imposed by the compiler as it can’t handle a leading or trailing comma. But in ocaml this is fine.

I also find this style easier to read:

{
   symbol : string;
   edge : float;

#19

Here are my 2 cents as a relative newcomer.
I started using ocamlformat from the very beginning, as I wanted to try the idea of “one style to rule them all”. Previously I always disagreed. Now I do agree that we need one style, but I very much disagree with the current ocamlformat style, although I still use it.

I wholeheartedly agree with the common theme in this topic.

The only way I can produce ocamlformat's style is by using ocamlformat. I write it in some other (much closer to what most people here propose) style and then run ocamlformat.


#20

I didn’t find this to be a problem in my experience with elm-format and ocamlformat. I have ocamlformat running every time I save my file and it helps me detaching myself from formatting considerations. This means that I don’t even try to produce something that looks like a reasonable formatting anymore, I let the tool do it for me.


#21

If you’re an emacs user, it’s a problem. One wants one’s formatting to be done automatically inside the editor as one types. That also detaches one from formatting considerations, btw. I don’t think about how to format my OCaml code either. Most people, I think, use such tools at this point.


#22

I am an Emacs user but I save often :wink:


#23

Let me again be direct. If you want to persuade people to use a tool that they aren’t interested in and that they think does things they don’t want, telling them things like “you’ll get used to it” and “there’s a way you can work with it that’s only modestly inconvenient” is going to drive people further way, not persuade people.

Imagine if you had a restaurant, and you tried to lure diners in with “after a few months of eating here regularly, you’ll get used to our food!” and “the chairs aren’t nearly as uncomfortable as you might initially expect, and by bringing a cushion with you when you come here, you can get things to the point where you barely notice that.” Sadly for you as the restaurateur, your customers have to want to eat there, and such talk doesn’t make them have the least interest. Maybe this wouldn’t be the worst approach if your customers were forced somehow to use your services, but as they have a choice, you’re not going to win this way.


#24

When ocp-indent has been released a few years ago, everyone was complaining because the indentation style was different from what they used to apply in their code. Exactly like everyone is complaining in this thread about ocamlformat’s style. It has been (and is still) not easy to convince people to run ocp-indent on their whole codebase to have something coherent.

ocp-indent doesn’t satisfy the community standard. It created a new standard that replaced the default emacs indentation scheme. And basically no-one is using the configuration options of ocp-indent.

So yes, pushing ocamlformat to adopt a style that is common will maybe help in the very short term. With old ocaml developers that don’t want to change their style. Newcomers are already happy with ocamlformat. But it doesn’t worth fighting on this common style too long. In the long term, people will get used to the defaults and be happy with them. Or they won’t be happy and won’t use ocamlformat. Same as what happen with ocp-indent.

refmt has the same issue btw. It is opiniated and produces horrible code sometimes. It even used to drop some {} and make the developers life troublesome. None of those issues have been blocking its adoption by the reason community.


#25

Do you have a source for that? I certainly use ocp-indent’s configuration, for otherwise I’d dislike its style. I would expect the same level of configuration from ocamlformat, without it adding or removing ( around then/else or similar changes, before I considering using it.


#26

No source except my experience looking at and modifying libs that are on opam. Sure there are some users. JSC has its style too. But I dont often see ocp-indent configuration file.


#27

And some of the most painful sticking points were changed and various configuration option added, in order to ease adoption, before it gained more mainstream usage in the community. :slight_smile:

I don’t even understand why the ocamlformat people insist on fighting that battle.


#28

Is there a battle being fought? A lot of configuration options have been added to ocamlformat from the PRs I’ve seen. There are a lot of code formatting options already listed here and a PR mentioned above by @gpetiot to change one of the biggest complaints listed here about putting separator punctuation first on a line.


#29

FWIW I use an .ocp-indent file in all my projects (personal and work) with just two tweaks:

match_clause = 4
max_indent = 2

(full, commented version here)

These two settings and the accompanying comments were copied from an example in the ocp-indent project itself.

The whole ocp-indent experience has been frictionless.