Oh and if we go with 4 spaces, we really have to make tab work to indent on Scastie
1 Like
For what its worth, I want to apologize to anyone rolling their eyes at the discussions that happened after this comment. I meant this in the sense of “hey, if you find significant indent hard to read like me, and are thus worried about this style suggestion, maybe to try with the above scalafmt setting, it did thus far counterbalance the reduced clarity of braceless code for me”
If we would settle on using \t then everyone could display it as they like 2 or 4 spaces and maybe some folks prefer 3 or 8. one could even use their preferred style in the same project where someone else displays it differently.
but well, I guess we would have one topic less to bikeshed, not sure that’s worth it 
1 Like
Tab does not help. You still need a fixed size that scalafmt will use to compute the line length, to decide whether and where to wrap. So you still have one “tab size” that actually works in any given project, and the others don’t. If your own tab size display does not match the project’s tab size, you’re in trouble.
4 Likes
You are right about the line length. The funny thing is, I never had conflicts in files which use tab but most likely that was just luck.
Personally, I don’t mind if the chosen width for calculation would be a scalafmt implementation detail (e.g. use 4 for this calculation) which would mean sometimes a line could be longer than whatever maxColumn I defined if my visual indent is more than 4 and it could wrap earlier than anticipated if I use a visual indent which is less than 4.
But I get that this is not for everyone, so we are back at bikeshedding what the default indent for the calculation should be but… we won one degree of freedom for all those which don’t mind the implementation detail. Isn’t that a win already?
Most code I look at these days don’t stretch until maxColumn (which is at 120, another topic to bikeshed about I guess) and there is room for personal preferences on the left.
Documentation is an exception but I assume most people would not mind if documentation wraps earlier than maxColumn.
This thread has been inactive for two weeks now. Looking at the responses, I think they are mostly “cautiously positive”, which is as much as we could have hoped for. So it’s worth pursuing this further.
Things to do:
- Create a scalafmt style that implements the recommendations.
- Over time, migrate more of the official docs to the common style.
- One open ended questions is how IDEs can better support the common style. The one advantage of end markers is that they don’t break the flow: I can write a block with some expressions, a blank line, and then some more expressions. Then I just have to add an end marker at the end. With braces I’d have to go back and insert an opening brace then move to the end and insert the closing brace. It would be nice if IDEs offered a shortcut here. Some way to insert the brace pair with one action, ideally when the curser is at the end of the block. Or auto-insert braces after the first embedded blank line of a block.
The question whether to use 2 or 4 spaces for indentation should be treated separately. I personally don’t have a strong opinion either way. But even with 4 spaces there will be sometimes a need for a construct to close a scope, so the discussion whether that should be end markers or braces is still relevant.
4 Likes
For Koine Scala, I hope the IDE inserts braces when I type end and also autocompletes the end marker.
1 Like
I recently got caught by indentation issues where a couple of functions where indented on one level two many - it took me forever to figure it out - hovering with Metals showed the types were correct but the compiler disagreed. I am mostly using indentation in Scala 3 and I like 2 space indentation. My classes use braces which I don’t really mind but open to indentation and end as needed.
I do like the fact that Scala looks much like Python and many people are using type annotations in Python so it looks even more like Scala - I have been doing some work in Python.
I am an early supporter of scalafmt, bringing it to Scala Native for formatting and starting the process for Scala.js. Scala.js took the scalafmt author itself to do the last few miles. Congrats to Albert and the Scala.js team for that.
I am a supporter of a more horizontal, binpacking type approach rather that the super vertical defaults of scalafmt because it leaves more code on the page. It is great that scalafmt respects returns so you can put a 3x3 matrix (in and array) in three rows and three columns. I am not a big supporter of ← and => alignment as changing a name or adding a case makes more of a diff to adjacent lines.
My experience as a Java coder was that the Java books showed the style and it was followed - Google and others like Eclipse started to change things a bit but not too radical. In Scala, I feel the different coding standard need normalizing because bike shedding over format is really a waste of time like the tab vs spaces arguments (tabs for make).
I hope a good compromise can be reached.
2 Likes
Given that the majority of our code is now likely to be written by AI, our standard coding style must be AI-friendly. This facilitates the AI in generating higher-quality, more readable code.
Please do not extrapolate personal experience to whole community - at $WORK we use AI too, but, in my experience, most of software is written by humans. Documentation might get generated by AI (mostly “how?” part) and generated text gets adjusted by humans to provide “why?” part.
We should design language and style for meatbags first and let AI adapt - we should use AI, not serve to it nor bend to it!
Which means simple.
I like this idea, because it says: “braces are good, do not scare it” Use it when it is realy needed.
This reduces the distance between “the two camps”
IMHO: I personally do not understand why It is more comfortable to use less braces. I really do not see differences between less or more braces when I am reading the code.
diff
object Foo {
def bar() =
while condition do {
if baz then
val text = getDataFromSomewhere()
val arg = argParser.process(text)
quux(arg)
else
bippy()
doSomethingElse()
}
def baz() = someOtherThing()
}
object Foo {
def bar() =
while condition do {
if baz then {
val text = getDataFromSomewhere()
val arg = argParser.process(text)
quux(arg)
} else {
bippy()
}
doSomethingElse()
}
def baz() = someOtherThing()
}
I personally prefer use braces always because of:
- I can type reflexively without need to predict the size of a block
- In python I am always sad when I need to format code manually when I can just call a formatter in other languages. May be AI will make me more happily in such cases
2 Likes
I like end markers because unlike braces, they indicate what it is that ends. I would prefer if they were the recommended style.
2 Likes
OMG that makes two of us. We need to start a club of some sort.
We could print placards to carry at protest events covered by the media.
def fascism =
end fascism
Obviously braces would not work, except maybe:
Future {
people
}
The future embraces the people!
Me too! I’m always surprised at how much end markers seem to be disliked in these discussions.
2 Likes
Very much a matter of taste, but I personally find them bulky – “noisier” than curlies.
1 Like
Probably IDE could add auto-comment for them. IDEA provides “virtual” types (and expose implicits), it should be possible to get rendering like:
def abc() = {
"123"
} // end abc
//^^^^^^^^^^ - this part could be part of visualization/rendering
Only problem with such “virtual” approach is that it is challenging to provide such “hint” in MRs and PRs.
is it? autogenerating it for diffing purposes shouldn’t need typechecking, so just parsing individual files before and after changes should be enough. github already has a mechanism for folding bodies of anything: value, method, class, object, etc, so it knows where to put the extra virtual end marker, doesn’t it?
We can accept that line length might be a few characters off. It’s not 1980 and we are not programming on 80 column terminals where it has to be so precise.
Especially because line length is another thing that can be adjusted. So we would have to specify both the tab size and the line length. So unless the Scala style guide specifies both 4 spaces and 80 spaces line length, it is gonna be off.
Scalafmt can just assume 4 space tab, and people who pick 5…8 spaces for indentation will get a little longer lines in 1% of the unfortunate cases where the line is both long and heavily indented.
Tabs are the way to go, but I have very low hopes we dare to go against the norm of “most” programing languages. GO does, and they are the language that values simplicity.
1 Like