The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I dislike the deep indents ... but your code is immediately understandable, without having to figure out what each parameter is. IMO the winner is readability for the next person who has to mess with the code. [or for myself 3-12 months from now, wondering whutinthuheck I was doing]
That's the way I do it. Except I move the && (or ||) to the start of the next line instead of leaving it trailing - it often helps when I want to comment out an option or two temporarily while testing.
- I would love to change the world, but they won’t give me the source code.
That's my preference as well, unless I'm still debugging the code, and I want to verify the output of one of the chained calls. Otherwise setting a breakpoint, say, on line 6 sets a breakpoint on the entire thing. But once I'm confident I won't have to revisit it, it all goes back to a single statement split among multiple lines.
When lines become long, I split before a binary operator, and make sure that binary operators always are in the same line, or, if the line is split, in the same column as the parentheses, if there are any. In addition, I usually put like binary operators in the same column. If a line is split at a binary operator, I indent both operands by the same amount, e.g. two characters to the right. Like so:
No, no, I wasn't looking at it from a code review perspective. I realize this is demo code.
I was just using it's an example of why I would never have long lines like that, in any code. The validation check for the values doesn't have to be there because this is demo code. I was pointing out the case that breaking the lines out of the chain makes spotting such missing functionality easier.
ou're really not saving yourself anything by piling it all into a single statement.
Debugging is key for me. A fellow coder loves to chain things together ... but if there is a problem with one parameter, it's harder to nail down when it's part of a large chain.
Plus it's not immediately obvious what parameters are in many cases. Name the variables well and it lends to self documenting code. [Although I want a comment explaining the business and/or technical reason for the code.]