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

Enable ocaml code formatting with dune fmt #207

Merged
merged 7 commits into from
Nov 28, 2024

Conversation

yfyf
Copy link
Collaborator

@yfyf yfyf commented Nov 22, 2024

This is a preview of automatic code formatting using ocamlformat / dune fmt

I tried to tweak it (see .ocamlformat), but a couple of issues I see with all 3 ocamlformat profiles (and that I am not sure are configurable):

  • short record value definitions (let a = { ... }) get squashed into a single line, which is not good for readability (therefore currently margin = 80, to prevent this as much as possible)
  • similar situation with pipe operators (|>)
  • dune files are formatted weirdly too (sometimes it breaks libraries into separate lines, sometimes it doesn't?), did not try to tweak that

In general, ocamlformat is meant to produce a canonical format regardless of how the input source is formatted, so it does not preserve any manual breaks/whitepsace.

@knuton @guyonvarch please check it out and see what you think.

You can experiment with the options here: https://gpetiot.github.io/ocamlformat-preview/

Some OBus_value.C.(value |> cast_single basic_string)
with
_ -> None
try Some OBus_value.C.(value |> cast_single basic_string) with _ -> None
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Not a fan of these single-line try .. with ...'s, not sure if it can be turned off.

return @@ Error (MissingRequestedInputs mandatory_inputs)
| Passphrase p, [ "Passphrase" ] ->
return
@@ Ok [ ("Passphrase", p |> OBus_value.C.(make_single basic_string)) ]
Copy link
Collaborator Author

@yfyf yfyf Nov 22, 2024

Choose a reason for hiding this comment

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

the way it breaks the line after return here is odd to me

Copy link
Member

Choose a reason for hiding this comment

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

Me too

; ipv6; ethernet; proxy; nameservers; security
})
pure
(fun
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

wat

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I guess the issue here is not the formatting, but the fun with 10+ arguments.

@yfyf yfyf added the reviewable Ready for initial or iterative review label Nov 22, 2024
@guyonvarch
Copy link
Member

I prefer lists with the ocamlformat profile, see network_details_page.ml:

let not_connected_form service =
  let requires_passphrase = service.security <> [None] in
  form
    ~a:
      [ a_action ("/network/" ^ service.id ^ "/connect")
      ; a_method `Post
      ; Unsafe.string_attrib "is" "disable-after-submit"
      ]
    (Option.to_list
       (maybe_elem requires_passphrase
          (label
             ~a:[a_class ["d-Label"]]
             [ txt "Password"
             ; input
                 ~a:
                   [ a_input_type `Password
                   ; a_class ["d-Input"; "d-Network__Input"]
                   ; a_name "passphrase"
                   ; Unsafe.string_attrib "is" "show-password"
                   ]
                 ()
             ]
          )
       )
    @ [ p
          [ input
              ~a:[a_input_type `Submit; a_class ["d-Button"]; a_value "Connect"]
              ()
          ]
      ]
    )

@yfyf
Copy link
Collaborator Author

yfyf commented Nov 25, 2024

I prefer lists with the ocamlformat profile

I see the visual appeal, but I find that it is more cumbersome to edit, because with conventional swapping list/collection members is simply swapping lines. With ocamlformat you cannot swap the first line with others, because the opening bracket [ gets moved. But it's a minor thing, if you feel strongly about it, I wouldn't mind ocamlformat.

@guyonvarch
Copy link
Member

I see the visual appeal, but I find that it is more cumbersome to edit, because with conventional swapping list/collection members is simply swapping lines. With ocamlformat you cannot swap the first line with others, because the opening bracket [ gets moved. But it's a minor thing, if you feel strongly about it, I wouldn't mind ocamlformat.

That’s right. But I find it so hard to see blocks with the conventional option, that I still prefer to struggle a bit when swapping the 1st element.

Did you notice other important differences between conventional and ocamlformat?

@yfyf yfyf force-pushed the ocaml-maintenance branch from c8d9fcd to 2c5996e Compare November 25, 2024 15:19
@yfyf
Copy link
Collaborator Author

yfyf commented Nov 25, 2024

@guyonvarch I pushed the code formatted with ocamlformat, see 2c5996e for the differences.

@guyonvarch
Copy link
Member

Use space around elements?

space-around-arrays = true
space-around-lists = true
space-around-records = true
space-around-variants = true

@yfyf
Copy link
Collaborator Author

yfyf commented Nov 26, 2024

Use space around elements?

Don't have a strong opinion about it, but would opt for less customization of the default profile settings to avoid causing unexpected formatting.

@yfyf
Copy link
Collaborator Author

yfyf commented Nov 26, 2024

@guyonvarch anything else that sticks out / looks annoying? The current config is decent enough for me and I think consistency is more important than a specific style.

@knuton we have converged towards something, please take another look.

@guyonvarch
Copy link
Member

Using field-space = loose in 5b92642, this is looking good!

@guyonvarch
Copy link
Member

And apart from removing the margin option, the options that you set up all make sense, and it does not look good removing those.

@guyonvarch
Copy link
Member

We’ll need a CI check to enforce the formatting afterward. And also consider formating in dev-server.

@yfyf
Copy link
Collaborator Author

yfyf commented Nov 26, 2024

Using field-space = loose in 5b92642, this is looking good!

Cherry-picked

Copy link
Member

@knuton knuton left a comment

Choose a reason for hiding this comment

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

Looks pretty good, one thing I have an issue with is operator pipelines. Maybe there is a decent enough fix for that.

Comment on lines +47 to +48
| Passphrase of string
(** The passphrase for authentication. For example a WEP key, a PSK passphrase or a passphrase for EAP authentication methods.*)
Copy link
Member

Choose a reason for hiding this comment

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

Maybe putting comments above would yield less weird formatting?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Putting it above actually yields a warning: Warning 50 [unexpected-docstring]: unattached documentation comment

Comment on lines 32 to 26
from_string body
|> get_dict
|> List.assoc "address"
|> get_string
|> fun address -> return {address}
from_string body |> get_dict |> List.assoc "address" |> get_string
|> fun address -> return { address }
Copy link
Member

Choose a reason for hiding this comment

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

This seems quite unfortunate to me, pipelines are sometimes on multiple lines, sometimes not, and overall harder for me to read.

Have you considered break-infix = wrap-or-vertical?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That definitely helps, added in fc2b21b

Comment on lines +65 to +66
( ""
, (* path to Curl executable (uses PATH if empty string) *)
Copy link
Member

Choose a reason for hiding this comment

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

Should probably move this before the comma so it stays close to the string literal it refers to.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, will do some manual fixes once we settle on the final formatting rules.

@yfyf
Copy link
Collaborator Author

yfyf commented Nov 26, 2024

We’ll need a CI check to enforce the formatting afterward.

Added a simple check in d672360

And also consider formating in dev-server.

My personal preference would be not to have anything interrupting development due to incorrect formatting, so I would vote for not adding it there.

@knuton
Copy link
Member

knuton commented Nov 27, 2024

My personal preference would be not to have anything interrupting development due to incorrect formatting, so I would vote for not adding it there.

What we normally have is not a check that fails, but an option to auto-format as part of the dev loop AUTO_FORMAT=1 bin/dev-server. Some in the team use editor integration, some let the dev server do it.

@yfyf
Copy link
Collaborator Author

yfyf commented Nov 27, 2024

What we normally have is not a check that fails, but an option to auto-format as part of the dev loop AUTO_FORMAT=1 bin/dev-server. Some in the team use editor integration, some let the dev server do it.

Added in 3c8004e. It will cause a double reload/restart (due to the written changes), but I guess that's OK?

If this was the last thing, I can squash the commits, deal with .git-blame-ignore-revs and manicure the comment / multi-line string formatting.

@knuton
Copy link
Member

knuton commented Nov 27, 2024

If this was the last thing, I can squash the commits, deal with .git-blame-ignore-revs and manicure the comment / multi-line string formatting.

I think so, but do we need to get #209 through first? Or how would we resolve conflicts?

@yfyf
Copy link
Collaborator Author

yfyf commented Nov 27, 2024

I think so, but do we need to get #209 through first?

Yes, that would certainly be preferable!

@knuton
Copy link
Member

knuton commented Nov 28, 2024

#209 is merged

@yfyf yfyf force-pushed the ocaml-maintenance branch from 3c8004e to 9535b67 Compare November 28, 2024 12:24
@yfyf yfyf marked this pull request as ready for review November 28, 2024 12:25
@yfyf
Copy link
Collaborator Author

yfyf commented Nov 28, 2024

squashed and rebased on top of main, ready for merging.

@knuton knuton merged commit a63df50 into dividat:main Nov 28, 2024
14 checks passed
@knuton knuton removed the reviewable Ready for initial or iterative review label Nov 28, 2024
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.

3 participants