clarinet format feedback

[tippenein]

The clarity formatter has been released in beta and we're looking for feedback. We're open to your ideas and bug reports. The LSP integration is coming next, but for now you can use the cli with clarinet fmt

[obycode]

This is great! I'm loving it, but just have a few issues I've noticed so far.

• The formatter drops the comment on this constant:

(define-constant WAITING_PERIOD u144) ;; 24 hours in blocks

• If I use the ;;; style for documentation comments, the formatter changes it to ;; ;

• I'm not sure I fully understand how it is deciding if two or more closing )s should be on the same line, or separate lines. This definitely seems like a personal preference thing, so I think I'd be okay with either option, but it seems inconsistent currently.

  • My personal preference would be that if they opened on the same line, they should close on the same line, otherwise, they should close on a separate line

[tippenein]

1 & 2. That's an oversight on my part. Should be an easy fix 👍
3. Yes, undoubtedly. The issue comes up when lines are width wrapped and we can't reliably tell where something started. We lose determinism of the output if we analyze the input start_line spans. We could do multiple passes (width wrap format, re-parse, back into format) but ideally we can come up with something more consistent which is still performant.

[hugocaillard]

I think multiple passes might be fine. You might even need "specialized" passes. Eventually with one dedicated to closing parenthesis that could be super performant

[pradel]

After running clarinet format on the Sigle contract, I have the following feedback. Note that you can see the diffs made by clarinet format on this pr (https://github.com/sigle/sigle/pull/1125/files)

• Bug: define-constant removes the ' in front of the contract principal
  

• Bug: define-data-var removes the value
  

• Bug: define-trait format not working Clarinet format with define-trait has unreadable output #1685

• Bug: seems like it kinda merged multiple functions on the same line
  

• Preference: after a define-map should have an empty line before the next define-public (line 29 that was removed)
  

• Preference: I added some line breaks to split the code and make it easier to understand but format is removing all of them

[hugocaillard]

Thanks for the detailled feedback Leo!

Regarding the last point (line breaks):

• I think the only rule we have right now is to add an empty line after define-<function> expressions.
• @tippenein I think this is one of the case where we need to break determinism:
  • looks like most formatters keep 1 empty line if the orginal source has 1 or more between 2 expressions
  • we may want to force new lines in some places (beside define-<function> expr), ubt i'm not sure where

[tippenein]

Sounds reasonable to me! I'll add some tests for these. Will post the PR back here when it's ready. Thanks @pradel