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

Setup automatic code formatting in SBT #513

Closed
alexandru opened this Issue Jan 11, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@alexandru
Member

alexandru commented Jan 11, 2018

Style is difficult to maintain and a burden in code reviews.

I long maintained that formatting should be done by the developers themselves, due to available tools not understanding context well. But for public projects that receive contributions this does not scale.

My preference would be for scalafmt, but it remains to be seen if it can be configured well.

Settings need to be adjusted to match the current style as much as possible.
Some quick rules, probably more to come as the need arises:

  1. Automatic copyright header
  2. ScalaDoc formatting should be disabled, being completely the responsibility of the developer
  3. In general I don't like dangling things to the right and I hate what IntelliJ IDEA does by default with function and class constructor params
  4. one line branches in match statements are OK, but the style needs to be consistent for all branches of an expression (if/else, match, etc), so either all branches are one lines, or all of them introduce newlines between condition and expression

No. 1 — auto copyright header

Being careful about the copyright header is a burden I'd like to avoid.

No. 2 — ScalaDoc

Monix uses carefully crafted indentation that does not match the formatting rules of IntellIJ IDEA and I'd like to avoid any fuckups of an automated plugin.

ScalaDoc is documentation and documentation requires manual crafting.

No. 3 — no dangling stuff to the right

For classes, this is OK:

case class Foo(
  number: Int,
  name: String)

case class Bar(
  number: Int,
  name: String
)

This is not OK:

case class Foo(number: Int,
               name: String)

For functions, this is OK:

def foo(number: Int,
  name: String): Result = {
  ???
}

def bar(
  number: Int,
  name: String): Result = {

  ???
}

// At call site
foo(
  number,
  name)

But this is not OK:

def foo(number: Int
        name: String): Result = {
  ???
}

// At call site
foo(number
    name)

So there's a strict policy against dangling stuff to the right.

No. 4 — indentation of match / if

For if/else, this is OK:

if (condition) success
else failure

if (condition) success else {
  failure
}

if (condition)
  success
else
  failure

This is not OK:

if (condition) success
else {
  failure
}

if (condition) {
  success
} else failure

For match, this is OK:

// All branches are one lines
expr match {
  case Foo(_) => success
  case Bar(_) => failure
}

expr match {
  case Foo(_) => 
    success
  case Bar(_) => 
    failure
}

// OK for the first branches(s) to be one lines, 
// but only if the formatter can distinguish this from the other cases
expr match {
  case Foo(_) => success
  case Bar(_) =>
    failure
}

This is not OK:

// unaesthetic mixed style
expr match {
  case Foo(_) =>
    success
  case Bar(_) => failure
}
@Avasil

This comment has been minimized.

Collaborator

Avasil commented Jan 18, 2018

@oleg-py
Did you plan to work on it (asking because of #531) ? If not - I could take a look into this issue tomorrow

@lorandszakacs

This comment has been minimized.

Contributor

lorandszakacs commented Jan 18, 2018

@Avasil, I just opened up a PR. Feel free to lift stuff from there and modify it to better suit the existing formatting.

#546

@Avasil

This comment has been minimized.

Collaborator

Avasil commented Jan 18, 2018

@lorandszakacs cool! I'll have a closer look tomorrow :)

@alexandru alexandru modified the milestones: 3.0.0-RC1, 3.0.0-RC2 Mar 18, 2018

@alexandru alexandru modified the milestones: 3.0.0-RC2, 3.0.0 Nov 6, 2018

@alexandru

This comment has been minimized.

Member

alexandru commented Nov 6, 2018

We have formatting rules in place, but truth be told I don't want automatic code formatting.

IntelliJ IDEA knowing how to interpret those rules is good enough.

@alexandru alexandru closed this Nov 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment