Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[all] Ocamlformat pre-commit hook #785

Merged
merged 6 commits into from
Mar 27, 2024
Merged

Conversation

Roman-Manevich
Copy link
Collaborator

I think it is a good idea to have a standard style throughout our OCaml code base.
Also, using ocamlformat would reduce the number of cosmetic code differences, making reviewing the code simpler and faster.
If testing is taking too long for you, you can commit while skipping testing like so: SKIP=make-test git commit -m "foo"
However, it is recommended that you do perform testing on every commit (unless you're squashing commit in which case, it is okay to test just once at the last commit in the sequence).

@Roman-Manevich Roman-Manevich changed the title Added ocamlformat hook to pre-commit [all] Ocamlformat pre-commit hook Feb 12, 2024
@HadrienRenaud
Copy link
Collaborator

Hi @Roman-Manevich,

While I think this is a good idea, I think this PR misses a few points:

  1. Version specification: how ocamlformat formats code is dependent on its version. The fix suggested in its documentation is to write a .ocamlformat file at the root of the directory and write the version in it.
  2. Incremental adoption: for the moment, IIRC, only the files in asllib are formatted regularly. Probably specifying a .ocamlformat-ignore file with all the folders apart from asllib would be good as a first solution.
  3. Specific options in some files: asllib/Typing.ml, asllib/Interpreter.ml, and asllib/types.ml need 73-character-wide lines for inclusion into latex documents. Again, having a asllib/.ocamlformat with margin = 73 should fix the problem

@HadrienRenaud HadrienRenaud force-pushed the pre-commit-ocamlformat branch 5 times, most recently from dcb8ad3 to 70e1309 Compare March 15, 2024 10:38
@HadrienRenaud
Copy link
Collaborator

Hi @Roman-Manevich, could you check that reference docs are still building correctly, and that the layout is good enough?

More generally, could you review the PR?

@Roman-Manevich
Copy link
Collaborator Author

HI @HadrienRenaud. Sure, I'll review and make sure things work, but it may have to wait to next week.

@HadrienRenaud HadrienRenaud force-pushed the pre-commit-ocamlformat branch 2 times, most recently from 9d2999d to 20202c6 Compare March 21, 2024 17:22
.pre-commit-config.yaml Show resolved Hide resolved
@@ -0,0 +1 @@
disable = true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really like the idea of the -ignore files because it meant that any new file will be checked, should we do this for litmus, tools and jingle and internal as well?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can! It is just not my decision to take so I did not do it this way

Copy link
Member

@relokin relokin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but I have a high level question.

It will be a bit annoying if our editors can't be configured to follow the same style. Essentially ocamlformat will be fighting the developers. Is there a way to configure popular editors to follow this style? I've seen people using vim, emacs and VS Code.

@HadrienRenaud
Copy link
Collaborator

It will be a bit annoying if our editors can't be configured to follow the same style. Essentially ocamlformat will be fighting the developers. Is there a way to configure popular editors to follow this style? I've seen people using vim, emacs and VS Code.

I don't know. The way I use ocamlformat is the following:

  1. Write code, not caring about any style.
  2. Run ocamlformat before committing or when I've finished my function/whatever.
  3. Repeat
  4. Run ocamlformat (i.e. dune fmt) just before commiting and running make test

That being said, there are a lot of editors which accept an external reformatter:

  1. VSCode official ocaml extension supports ocamlformat natively (once it is installed)
  2. If you're running emacs or vim, probably running dune fmt is just a few keystrokes away ...

@relokin
Copy link
Member

relokin commented Mar 21, 2024

It will be a bit annoying if our editors can't be configured to follow the same style. Essentially ocamlformat will be fighting the developers. Is there a way to configure popular editors to follow this style? I've seen people using vim, emacs and VS Code.

I don't know. The way I use ocamlformat is the following:

1. Write code, not caring about any style.

2. Run ocamlformat before committing or when I've finished my function/whatever.

3. Repeat

4. Run ocamlformat (i.e. `dune fmt`) just before commiting and running `make test`

That being said, there are a lot of editors which accept an external reformatter:

1. VSCode [official ocaml extension](https://marketplace.visualstudio.com/items?itemName=ocamllabs.ocaml-platform) supports `ocamlformat` natively (once it is installed)

2. If you're running emacs or vim, probably running `dune fmt` is just a few keystrokes away ...

Thanks @HadrienRenaud. That makes sense. I would vote for enabling it for other folders too. Not a blocker though if peolpe want to try it in a limited set of folders first.

relokin
relokin previously approved these changes Mar 21, 2024
@maranget
Copy link
Member

Well I am not very keen on imposing some format on OCaml code.

We each code in slightly different styles and I see no strong benefit in uniformity here. Provided of course that we refrain from changing complete files for no other reason than style.

As an example. Hadrien tends to put the in keyword in a line of its own. I'd rather have in at the end of the last line of the bound expression. I see no compelling reason for Hadrien to adopt my style or for me to adopt Hadrien's style.

@relokin
Copy link
Member

relokin commented Mar 26, 2024

Well I am not very keen on imposing some format on OCaml code.

We each code in slightly different styles and I see no strong benefit in uniformity here. Provided of course that we refrain from changing complete files for no other reason than style.

As an example. Hadrien tends to put the in keyword in a line of its own. I'd rather have in at the end of the last line of the bound expression. I see no compelling reason for Hadrien to adopt my style or for me to adopt Hadrien's style.

I think this PR needs to be accepted by everyone, and for this reason I'm removing my approval.

Having said that imo, I am not attached to any particular style. I find it useful when there is a uniform style though whatever that is. It doesn't matter if a block of code is indented 4, 8 spaces or a tab, but it helps a lot identifying the block when it's indented with the same spacing.

For example, in this code:

let foo a =
  let b = a + 1 in
  let c = b * 2 in
  b - c

I would find it confusing if someone wrote:

let foo a =
  let b = a + 1 in
let c = b * 2 in
  b - c

and I don't know if this is ever intentional.

But let me be clear I don't care if a style enforces this:

let foo a =
  let b = a + 1 in
  let c = b * 2 in
  b - c

over this:

let foo a =
     let b = a + 1 in
     let c = b * 2 in
     b - c

or this

let foo a =
  let b = a + 1 in
  let c = b * 2
  in b - c

@relokin relokin dismissed their stale review March 26, 2024 11:54

No concensus

@HadrienRenaud
Copy link
Collaborator

Given @maranget answer, I see two possible outcomes for this PR:

  1. Dropping it entirely
  2. Restricting it to asllib, with or without reformatting dune files.

Given that code in asllib has to be properly formatted because it is quoted in reference documents, I would be tempted to go for option 2.
What do you think @maranget?

@maranget
Copy link
Member

Option 2 looks reasonable.

@HadrienRenaud HadrienRenaud force-pushed the pre-commit-ocamlformat branch 2 times, most recently from f83a1c0 to edde8aa Compare March 27, 2024 12:06
@HadrienRenaud
Copy link
Collaborator

This PR now implements option 2, with minimal noise.

Unless anybody has a different opinion, I'll merge as soon as #814 is merged.

@HadrienRenaud
Copy link
Collaborator

Thanks all it looks like it works as expected, I'm merging

@HadrienRenaud HadrienRenaud merged commit 0b8054e into master Mar 27, 2024
3 checks passed
@HadrienRenaud HadrienRenaud deleted the pre-commit-ocamlformat branch March 27, 2024 15:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants