LINQ queries: SQL-style abbreviations or spell it out?

Microsoft is pretty clear that .NET "identifiers" or "parameters" should not contain abbreviations. Straight from the horse's mouth:

To avoid confusion and guarantee cross-language interoperation, follow these rules regarding the use of abbreviations:

• Do not use abbreviations or contractions as parts of identifier names. For example, use GetWindow instead of GetWin.
• Do not use acronyms that are not generally accepted in the computing field.
• Where appropriate, use well-known acronyms to replace lengthy phrase names. For example, use UI for User Interface and OLAP for On-line Analytical Processing.
• When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io.
• 开发者_如何学PythonDo not use abbreviations in identifiers or parameter names. If you must use abbreviations, use camel case for abbreviations that consist of more than two characters, even if this contradicts the standard abbreviation of the word.

- http://msdn.microsoft.com/en-us/library/141e06ef%28VS.71%29.aspx

---

Yet, if you take a look at MSDN's own 101 LINQ Samples page, you will find tons of examples like this...

var productNames =
    from p in products
    select p.ProductName;

...and very few (none?) like this...

var productNames =
    from product in products
    select product.ProductName

...but on other MSDN pages, you'll find examples that spell things out (e.g., http://msdn.microsoft.com/en-us/library/bb384065.aspx).

Discussion

I have mixed feelings about this. With intellisense, it's not exactly a hardship to spell everything out, but I'm not sure there's much advantage in it either. Is it more readable or less? You're sort of trading off wordiness for clarity. SQL programmers seem to get along well enough with short abbreviations for table names, but then again, programmers used to survive using Hungarian notation, too, and that's been pretty well proven to be a bad idea.

So, a couple questions:

1. Is there any official guidance on whether LINQ queries should be abbreviated or not?
2. What is your particular preference and why?

---

I suppose you could say that a range variable doesn't really follow the same rules as other identifiers, since its scope is entirely limited to the query expression. It's a bit more obvious what "p" means because you're never looking at it outside the context of from p in products.

My preference - and perhaps I shouldn't be admitting this - is just to use "p". To be honest, I simply don't see the point in descriptively naming something that can only ever be used in one statement.

Imagine you're writing a lambda expression instead. Would you write:

products.Where(p.ProductID == productID).Select(p => p.ProductName)

or

products.Where(product.ProductID == productID).Select(product => product.ProductName)

I actually find the first version more readable, but maybe that's just personal preference.

---

I think it's much more akin to index variables in a for-loop. While I would normally avoid single letter variable names, in that context and in the context of a temporary placeholder in a LINQ query (or lambda expression), I'm ok with it. I like the brevity. It sets it apart from locally scoped variables. Since I'm more apt to use extension methods than LINQ syntax, I use single variable names a lot in lambdas and prefer it there. It's certainly no harder to read and may be easier when the number of such variables is small. If a longer variable name makes it more understandable, though, I'm not against using that either.

---

I use the whole word if its less than 10 or so characters. I also use the @symbol to as a in/out of scope visual cue.

var productNames =
from @product in products
select @product.ProductName