This makes it really annoying to grep for log messages. I can't control what you do in your codebase but I will always argue against this the ones I work on.
I haven’t found this to be a problem in practice. You generally can’t grep for the complete message anyway due to inserted arguments. Picking a distinctive formulation from the log message virtually always does the trick. I do take care to not place line breaks in the middle of a semantic unit if possible.
Yes, I find the part of the message that doesn't have interpolated arguments in it. The problem is that the literal part of the string might be broken up across lines.
And to add to this, you rarely need to read a log message when just visually scanning code, its fine going off the screen.
Splitting log messages across lines like that is pure evil. Your punishment is death by brazen Bull. Sorry I don’t make the rules, just how it is. :(
Nitpick: this looks like Python. You don't need + to concatenate string literal. This is the type of thing a linter can catch.
IMO, implicit string concatenation is a bug, not a feature.
I once made a stupid mistake of having a list of directories to delete:
directories_to_delete = (
"/some/dir"
"/some/other/dir"
)
for dir in directories_to_delete:
shutil.rmtree(dir)
I essentially did an `rm -rf /` because of the implicit concatenation.
It’s actually Java, where the “+” is necessary.
I like splitting long text as in log statements into appropriate source lines, just like you would a Markdown paragraph. As in:
I agree that many formatters are bad about this, like introducing an indent for all but the first content line, or putting the concatenation operator in the front instead of the back, thereby also causing non-uniform alinkemt of the text content.