Anonymous method formatting, again.
A while back I asked for some feedback about how we should format anonymous methods. Then I was asking whether the default should be to put the opening brace on the same line as the delegate keyword or not. From your feedback, it looks like we'll keep the default the same as it is now (on the next line). So that brings me to another question. Some people have requested the ability to have the anonymous method braces indented. I'll give some examples:
Currently, anonymous methods look something like this:
List<Thing> somethings = things.FindAll(delegate(Thing thing)
{ return thing.ShouldBeIncluded; }
);
Or this:
List<Thing> somethings = things.FindAll(delegate(Thing thing)
{ return thing.ShouldBeIncluded; });
Or this:
List<Thing> somethings = things.FindAll(delegate(Thing thing)
{
return thing.ShouldBeIncluded;
});
Depending on where you put newlines.
With the proposed option, you would be able to make those look like:
List<Thing> somethings = things.FindAll(delegate(Thing thing)
{ return thing.ShouldBeIncluded; }
);
Or this:
List<Thing> somethings = things.FindAll(delegate(Thing thing)
{ return thing.ShouldBeIncluded; });
Or this:
List<Thing> somethings = things.FindAll(delegate(Thing thing)
{
return thing.ShouldBeIncluded;
});
Or even this:
List<Thing> somethings = things.FindAll(delegate(Thing thing)
{
return thing.ShouldBeIncluded;
}
);
So my question for you today is: Do you want the new option? If you do, what should the default be, indented, or not indented?
Please post and let me know.
Comments
- Anonymous
August 08, 2004
Of your seven samples, i'd have to go with number 3.
Although, to be honest, i'd probably prefer something like this:
List<Thing> somethings = things.FindAll(
delegate(Thing thing)
{
return thing.ShouldBeIncluded;
});
or:
List<Thing> somethings = things.FindAll(
delegate(Thing thing)
{
return thing.ShouldBeIncluded;
}
);
But of course, that second one was really just to show that no matter what you think you can cover, we'll all do it different anyway :)
But my preference for this is to take the view that defining the delegate is basically defining a function - with the delegate keyword being the name of the function - so therefore i'd want to make it look like a function, but with an extra level of indenting to show that it's 'inline'.
Make sense? - Anonymous
August 08, 2004
The comment has been removed - Anonymous
August 08, 2004
Of your seven samples, I vastly prefer #4 or #7 (both of which are indented). I find the unindented versions less clear. - Anonymous
August 08, 2004
The comment has been removed - Anonymous
August 08, 2004
Hi Zirakzigil,
I should point out that with the option you would be able to do any of the 7 examples. Without the option, you would be able to do 1, 2, 3.
I take it though, that you would like to have the option, and have it's default value be true? - Anonymous
August 08, 2004
I think the indenting makes it a lot clearer. It's really like night and day.
So, to answer your question, I definitely think the new option should be included and should probably be the default option. - Anonymous
August 08, 2004
Personally, I agree with Geoff's formattting, and if we can do that already, I guess I don't care what new options you offer. Normally I wouldn't post this fact, because that seems like a useless answer. However, maybe it's a useful response if enough people agree and you can theregore avoid putting in a new option.
Now, I'm normally against limiting choice, but managers are always looking for features they can cut...so maybe my response will make a PM happy somewhere. - Anonymous
August 08, 2004
Geoff,
I'm was wrong, you can't do that today, but I'm probably going to make it so that that will work, regardless. - Anonymous
August 08, 2004
laughs
Good to see you correct yourself :)
Doesn't matter to me what can and can't be done, i was just telling you what i'd prefer.
If you choose to bow down before me and accept my preferences, then that's only the world working as it should.
If you discover that you won't/can't make it happen, i'm sure the world is no worse off - so long as i can still do option 3.
Although, whatever the formatting chosen, i think it's pretty safe in assuming that people won't really care so long as there's indenting involved, and the indenting makes sense and is clearly showing what block it's encapsulating.
I prefer the option where you bow before my judgement however :) - Anonymous
August 08, 2004
As a newbe, i prefer option 7. - Anonymous
August 08, 2004
I'd prefer having the option. - Anonymous
August 08, 2004
Like Geoff, I think that example 3 is the clearest, with example 6 coming in second.
As far as the indent option goes: I think having more options is always better... - Anonymous
August 08, 2004
The comment has been removed - Anonymous
August 08, 2004
When I'm writing 'for' loops in VS2003, they look like your option #3. That's how I like them to look. I'm not aware of ever having messed with curly-brace-formatting options in VS, but it's certainly certainly possible that I did. Assuming there are VS2003 curly-brace-formatting options (I'm out of town with a laptop that doesn't have VS on it), I'd want VS2005 to respect the curly-brace formatting options that I set in VS2003 (which in this case would cause anonymous methods to look like method #3 for my newlining behavior). If there are no such options in VS2003, I'd want VS2005 to have defaults that are as close to VS2003 behavior as possible (which again would be #3 for people like me who use a lot of newlines). - Anonymous
August 09, 2004
The comment has been removed - Anonymous
August 09, 2004
I think this is the most readable:
List<Thing> somethings = things.FindAl(delegate(Thing thing)
{
return thing.ShouldBeIncluded;
}
); - Anonymous
August 09, 2004
I like #4 or #7 (depending on the length of the method body). Would prefer by default. - Anonymous
August 09, 2004
I'd like to see Geoff's second formatting or your [Kevin] seventh formatting. Indenting is generally preferable to not having it. I'd also recommend having this as the default (indenting turned on).