Open ntjess opened 4 months ago
it is related to how we format code blocks. currently code blocks are always take at least 3 lines. i think we can make a special case for this.
I think it is a little bit hard to determine when to fold these into a single line. I did some initial test but the result doesn't look good
Fair point; perhaps only when an "else" clause is also specified?
Fair point; perhaps only when an "else" clause is also specified?
I propose a way to determine whether to inline if
or not:
if
s that directly appears in code blocksif
s, if it has an else
clause and all its subclause only has a single item(and the item is not commet!), and if all these thing can fit in the column width, we put it in a single line.That makes sense to me!
For other
if
s
Are there additional if
s besides assignment and control statement?
I mean we may only inline if
s that appears in expression, function args, rhs of assignment ... But we shouldn't inline if
s that is directly in a code block.
{
// DO NOT
if ... {
...
} else {
..
}
let a = if ... { } else { } // DO
let a = f(if ... { } else { }, ...) // DO
let a = (1, 2, if ... { } else { }) // DO
}
I just realize that the body of if can be content blocks as well, like
#if 1 > 2 [ 111 ] else [ 222 ]
So maybe we should have a special code path for "simple if"s. If we have a if,
We try to inline it.
Content blocks should be acceptable too, right? IMO As long as they are short enough, the cognitive complexity is still lower when inlined.
All the other conditions make sense to me.
- Never inline if statement. That is, ifs that directly appears in code blocks
- For other ifs, if it has an else clause and all its subclause only has a single item(and the item is not commet!), and if all these thing can fit in the column width, we put it in a single line.
From my point of view, the first point is good but the second point is not quite good. I don't think it good and robust to check so many conditions: if it has an else clause and all its subclause only has a single item(and the item is not commet!)
. Why don't we change the perspective for this issue to simplify the rule? inline if
expression only if
#table( // named item can be as a function argument
fill: (x, y) => if y == 0 { white.darken(15%) } else { none },
)
#let paint = ( // named item can be as an item of some dictionary literal
stroke: if y == 0 { white.darken(15%) } else { none },
)
I think it is a generally great enough rule to make beautiful named items, and we can find other good rules when someone make another issue.
I think the reduced complexity makes sense, but I would advocate for let
declarations to also be considered. To me, readability decreases with spacing for the following example:
#let x = if cond {
5
} else {
6
}
However, let
introduces all the edge cases from above. So I can understand avoiding it in favor or straightforward rules.
Consider this case:
The function definition is short (< line length) and clearly indicates parameter usage.
typstyle
reformats to:which is arguably less readable.
My request is for inline ternary functions shorter than the user-specified line length to remain one-line.