In many languages, it is common to split long lines at member access, with the '.' operator moved to the new line, and I tend to prefer this approach in python. It makes it easier to visually parse chained calls/accesses. YAPF tends to add line breaks _after_ the '.'. Could there be a new option to tell YAPF to prefer splitting before?
Sure. The caveat is that I don't know how well using the Java-style Builder format works in general. But yeah, we can add that flag.
Glad to hear it! I'm not sure what you mean specifically by the "Java-style builder format." I assume it's an example of a case where you call a bunch of chained methods to set parameters on a builder? I picked up the break-before-period from rust, e.g. from the rust docs:
fn double_arg(mut argv: env::Args) -> Result<i32, String> {
argv.nth(1)
.ok_or("Please give at least one argument".to_owned())
.and_then(|arg| arg.parse::<i32>().map_err(|err| err.to_string()))
.map(|n| 2 * n)
}
It would also be nice to have control over the split penalty for splits around the '.', as well as things like after opening paren (if that isnt already covered by SPLIT_PENALTY_AFTER_OPENING_BRACKET). As a concrete example, I want to be able to format code as:
if condition:
raise RuntimeError(
"A sort of long message. {}. Blah blah blah"
.format(useful_data))
rather than:
if condition:
raise RuntimeError(
"A sort of long message. {}. Blah blah blah".format(
useful_data))
I find the former formatting drastically more readable.
Any updates or docs to point towards to contribute to this knob as I'd love to see it in an upcoming release.
Most helpful comment
Any updates or docs to point towards to contribute to this knob as I'd love to see it in an upcoming release.