[FLGMwt]

Having just moved to my first Scala team, I would really really not like this to be in the language. Given 5 ways to do something, a large organization is going do something all 5 ways.

Scala is a fun language, but consistency is not one of its ecosystem's strengths.

Grain of salt: again, I'm new to Scala, but I'd hate to think of it as a language that can only be good once you're Stockholm'd.

[lacampbell]

Having just moved to my first Scala team, I would really really not like this to be in the language. Given 5 ways to do something, a large organization is going do something all 5 ways.

I agree with you on one level. But taking a step back, and looking at it from a much longer time perspective than is practical in business - is the problem really the programming languages giving us too much choice?

Constraining how a programming language does something because we're not yet "there" in terms of software engineering does seem a bit backwards.

[chowells]

Programming language design is a part of software engineering. The easier a language makes it for you to do something, the more likely you are to do - regardless of whether it's considered good software engineering.

That said, I don't see anything wrong with this proposal. It makes more likely that code structure mirrors its layout, which is a good thing. Even if it's not always used, it's an improvement where it is.

[emsy]

There should be a styleguide that is enforced by CI tools, regardless of language, so that's not an issue.

However, special cases in the syntax increase the complexity and I would always argue against that.

[FLGMwt]

Yeah, and there's certainly style tools in place at some level (formatting, implicit types, etc). But I don't know if I agree that there should be global language rules about what defines sematic style across an org with 20+ relatively independent teams.

And that says nothing about third party libs that one can't control. Again, I am new to the ecosystem, but with languages like C#, it seems that the comparatively fewer language constructs streamline API patterns.

[emsy]

I don't know about how your organization works, but any one development team with a shared codebase should enforce coding styles. This means indentation but also how common constructs are used. Especially if someone external might work on the code. Some standards are just necessary to achieve uniformly looking code. But some might prevent bugs (For example mandatory curly braces after ifs). It's also just a simple Tool to prevent friction and create a sense of shared code ownership.

External libraries are usually black boxes and you don't work on the code so I don't understand the argument.

[tormeh]

Like Scalastyle?

[hocuspocus]

A combination of scalastyle, hairyfotr's linter, wartremover, scalafmt.