Purescript style guide

[ngua]

We have a Haskell style guide which we can partially follow, but we should probably have one for Purescript code as well (and maybe even for FFI code)

Let's use this issue as a list of conventions we try to follow

• Avoid newtypes when there are no type class instances for the type, except of cases where we want to use newtypes to prevent confusion when working with multiple values of the same type.
• No explicit instance names
• No $ required before do, unlike in Haskell
• Don't mix $ with parentheses where it's possible to use only $s
• Prefer f1 $ f2 $ f3 v over f1 <<< f2 <<< f3 $ v and (f1 <<< f2 <<< f3) v (compose uses more stack and has longer operator name)
• Naming of FFI functions should start with underscore, except of cases when the function is exported right away with no changes to the public interface
• If the goal of an import is just to re-export, use import Foo.Bar (baz) as X, not import Foo.Bar (baz) as Foo.Bar (avoids boilerplate and clearly indicates the purpose of the import)
• Do not export functions more than once from Contract.* modules. The motivation is it would make imports management more complicated for the users (the need to choose between modules). language-server users will have a better UX (there is no need to choose a module if only one module exports an identifier)
• Do not import modules from test/ in src/ (the reason is: spago only looks up for modules from src/ in dependencies of a project, so that would make CTL unusable as dependency).

[klntsky]

This one looks good for me, though it is a bit dated (effect types are not used anymore). Also I don't see a valid rationale for Doubly indent nested record or array literals .

[ngua]

Hmmm, I don't understand that one either. I think some of the guidelines won't work with purty as well. It's probably a good starting point though, thanks for sharing it

[klntsky]

Since we have an autoformatter now, can we just use it as an oracle instead of writing a guide?

[adamczykm]

I think there's more to style guide than formatting. We should probably have one that is based on Haskell one where possible.

[klntsky]

Some PS-specific questions to address:

• should we write instance names: NO
• naming of FFI functions

[uhbif19]

@klntsky Should not it be closed, as the matter is settled?

[klntsky]

@uhbif19 the list in the original post is about things not eforced by the formatter

[rynoV]

How about:

• Prefer f1 $ f2 $ f3 v over f1 <<< f2 <<< f3 $ v and (f1 <<< f2 <<< f3) v

I think the first is preferable for purescript since the compose function is more characters.

[klntsky]

@rynoV I agree, also, compose uses more stack.

[rynoV]

Suggestion:

• Prefer not $ f a b over not f a b. The second will generate more complex JS code and use more stack.

I haven't checked this, but based on the definition that would be used for the latter, I think recursively resolving the instances would be less efficient.