# How to break up long lines of code. (Example Line: Results of method call added to list.)

Often I generate long lines of code such as the following...

shippedItems.AddRange(OrderItem.Fetch(market: this.MARKET, shipConfirmState: ORDERITEMSHIPCONFIRMSTATE.NONE, orderPlacedAfter: serverTime.AddDays(-7), orderPlacedBefore: serverTime.AddHours(-85)));


... which adds the results of a method call to an existing list.

Adding white space to this line could improve readability. At one point in time or another have rationalized almost every possible behavior between:

• Leave everything on a single line and let the editor wrap where it feels is best.
• Put even shippedItems.AddRange( on a line by itself.

While over time I feel that the clarity and readability of the code that I write has improved -- and lets hope for reasons other then white space -- I have never come to peace with how to break long lines.

I will up vote any answer that does NOT include as the solution:

• shorter variable names.
• disregarding named parameters (at least for this example).
• creation of variables only used once.
• There's nothing wrong with creating a variable that is only used once. Sometimes, the required indentation is just too much. – EndangeredMassa Feb 14 '11 at 18:37
• I am curious as to why you would not use a Pretty Print preprocessor to do this for you. – user1707 Feb 20 '11 at 21:14
• What would StyleCop do? – Leonid Aug 17 '12 at 5:03

I would break it up something like this:

shippedItems.AddRange(
OrderItem.Fetch(market: this.MARKET,
shipConfirmState: ORDERITEMSHIPCONFIRMSTATE.NONE,


Depending on previous indentation, some lines might flow over the "max line length", but I think that characters per line is more of a suggestion and there are good times to break that rule because breaking it leads to code that is more readable than code that doesn't.

• New line after an open paren.
• Line breaks after commas.
• Indent the inner method calls.
• Line up parameters to a method that are on new lines.
• Break "max line length" rules if it means the code is more readable.
• Top of the pile after 1 week. Accepted on the basis of most preferred. – jphofmann Feb 21 '11 at 15:13

As a follow up to @Thomas Owens, another rule I personally like to follow is:

• Either put all parameters for a method on the same line, or put each parameter on its own line.

So I would write the code as follows. I like this because it makes reading the parameters more consistent, and doesn't indent them quite as far.

shippedItems.AddRange(
OrderItem.Fetch(
market: this.MARKET,
shipConfirmState: ORDERITEMSHIPCONFIRMSTATE.NONE,

• I sometimes do this, myself. I suppose it depends on how many parameters I have and how long each one is. – Thomas Owens Feb 14 '11 at 16:18
• I think this works well with named parameters, but without readability breaks down when a parameter is another function call. – jphofmann Feb 14 '11 at 16:40
• +1 as I find it annoying to have to fix the leading whitespace after a rename/refactor to keep things lined up. I might put OrderItem.Fetch( on the line above for compactness, and I put the ending )); on its own line, outdented from the parameters (indented only one tab stop). – David Harkness Feb 15 '11 at 6:37
• This is definitely my preferred way of writing that kind of code – Pete Feb 15 '11 at 19:42

Interesting to see the range of responses. I would tend towards a different answer from any of those so far:

shippedItems.AddRange(OrderItem.Fetch(
market: this.MARKET,
shipConfirmState: ORDERITEMSHIPCONFIRMSTATE.NONE,
));


This to me reads more intuitively as "add the fetched order items to shippedItems, using the following block of arguments to fetch".

One piece of advice from someone who has been through the same dilemma for a while now: don't try to put rules on it. Take each example on its own merit and try to write it in the way that you would want it to be written if you were someone else trying to figure out what it does.

Sometimes it is a good idea to have a use-once variable to make something more readable. For example, if AddRange above had a second argument, where would you put it? Even this simple case reads badly

shippedItems.AddRange(
OrderItem.Fetch(
market: this.MARKET,
shipConfirmState: ORDERITEMSHIPCONFIRMSTATE.NONE,
),
2
);


var orderItems = OrderItem.Fetch(
market: this.MARKET,
shipConfirmState: ORDERITEMSHIPCONFIRMSTATE.NONE,
);


Each case on its own merit.

• +1, I use the One-True-Brace style (1TBS), so all the answers where the closing parenthesis and semicolon are indented make me cringe. Can't match the semicolon with the opening of the statement to tell where the multi-line statement ends. This looks much better. That being said, the 2nd example with 2 as a second parameter looks fine to me. – DCShannon Aug 26 '14 at 0:47

This may be a sign you need to factor out the Fetch into a new method:

....
....

private OrderItems LastWeeksMarketItems ()
{
return OrderItem.Fetch(market: this.MARKET,
shipConfirmState: ORDERITEMSHIPCONFIRMSTATE.NONE,
}


The method name gives you further clarity about what it is you are trying to add.

• For me, this just abstracts away what is actually being added to shippedItems. Also, this ends up defining in two places, to varying degrees, what items are being added. In the method name as "last weeks" and in the parameters being passed into fetch. – jphofmann Feb 16 '11 at 21:32
• It depends on the usage to determine how useful it is. Think of it like a drill down. If you are adding last weeks in one place, last months in another and last years in another then you can quickly see which is being achieved. – Mongus Pong Feb 16 '11 at 21:56
• Also if you add last weeks items in several places, this of course keeps the logic in one place. – Mongus Pong Feb 16 '11 at 21:56
• If you are adding arbitrary times in just this place, then it probably isn't so useful.. – Mongus Pong Feb 16 '11 at 21:57
• +1. +50 if I could. Abstraction is what it's all about, and you identified a very useful abstraction here. – Christoffer Lette Feb 21 '11 at 10:39

This is what I would do:

shippedItems.AddRange(
OrderItem.Fetch(market: this.MARKET,
shipConfirmState: ORDERITEMSHIPCONFIRMSTATE.NONE,
);


I feel that just as with brackets ({}) the closing parenthesis should be on its own line when a method call spans multiple lines. It seems more consistent to me.

Alternatively, you could line up the :'s:

market:           this.MARKET,
shipConfirmState: ORDERITEMSHIPCONFIRMSTATE.NONE


but that it difficult to maintain.

Another option:

shippedItems.AddRange(OrderItem.Fetch(market: this.MARKET,
shipConfirmState: ORDERITEMSHIPCONFIRMSTATE.NONE,


That uses fewer lines, but is longer horizontally. Also, at first glance it looks like the arguments are to AddRange, not Fetch.

• I have been a fan in the past of the trailing ); as it makes a nice distinct "block" of code. But, I gave it up because I was ending up with multiple lines in a row of ) and }. For now, indent level is enough for me. – jphofmann Feb 14 '11 at 16:15
• Also, if you were willing to give AddRange its own level of ); why not a ) on a single line for Fetch? – jphofmann Feb 14 '11 at 16:16
• @jphofmann: It's a matter of style, really. My reasoning for placing OrderItem.Fetch on a new line was to prevent readers from thnking that the arguments were to AddRange. That does not apply in Fetch's case, so I left them on the same line. – Michael K Feb 14 '11 at 16:19
• @jphofmann first comment: There are limits, obviously. However, I've found that many times if you have calls that go that long you really need to do some refactoring anyway. – Michael K Feb 14 '11 at 16:21

I think you are unwise to reject creation of variable used only once. The forced line breaks you seem to be requesting are difficult if not impossible to implement in an aesthetically satisfactory way in an automated formatter - and if you're not using an automated formatter, you're wasting time.

var state = ORDERITEMSHIPCONFIRMSTATE.NONE;
var range = OrderItem.Fetch(market: MARKET, shipConfirmState: state, orderPlacedAfter: start, orderPlacedBefore: end);

• What automated formatter would you suggest? – jphofmann Feb 20 '11 at 14:58
• I'm afraid I'm from the Java world, not .net; I don't know what's available there, although I would hope Visual Studio would offer something like Eclipse's options for code formatting. If not, there must be some tool that will do the job. – Carl Manaster Feb 20 '11 at 16:04

I really like Mongus Pong's answer, but I have a couple of things to add.

• The name of the extracted method should reflect the actual meaning of the magic numbers (-7 and -85) inside the method.
• The magic numbers themselves should probably be turned into named constants, for added clarity.
• The extracted method should be put where it belongs. I would suggest using the repository pattern, but in this specific case it would probably be a good idea to put it next to the Fetch method, inside the OrderItem class. (The OrderItem class looks like a domain entity to me, so this would break SRP, but I digress.)
• If all usages of Fetch could be replaced by methods like this, Fetch could eventually be made non-public.

Something like this:

shippedItems.AddRange(OrderItem.FetchLastWeeksOrderItems(MARKET, serverTime));

public class OrderItem
{
public static IEnumerable<OrderItem> FetchLastWeeksOrderItems(
string market, DateTime serverTime)
{
return OrderItem.Fetch(
market: market,
shipConfirmState: ORDERITEMSHIPCONFIRMSTATE.NONE,