LINQ naming Standard - Lambda Expression

Question

We normally follow coding / naming standard for all C# syntax. For Example, if we declare string inside the method, we use Scope-datatype-FieldName format. (lstrPersonName)

List<Person> icolPerson;
private LoadPersonName()
{
   string lstrPersonaName;
}

i am kind of thinking how do we follow the naming standard in Lambda Expression. Especially when we defined the arguments for func delegate, we use shorted names like x. For Example

var lobjPerson = icolPerson.Where(x => x.person_id = 100)

if you look at the above line, X does not follow any standard. i also read that one purpose of lambda expression is to reduce the lenghthy code.

i am here to seek help to get the right approach for naming standard.

var lobjPerson = icolPerson.Where(x => x.person_id = 100)

OR

var lobjPerson = icolPerson.Where(lobjPerson => lobjPerson .person_id = 100)

Answer 1

There is no the right approach at all. Naming standard like any other coding standards (like spaces and new lines after/before expressions) is a convention inside group. So just write your code as you like and as you should do it at your company. But do it consistently!

i prefer use underscore prefix in names of private fields. but your style(visibility + type + name) looks for me like an old WInAPI code citation(Hungarian notation) =).

Answer 2

I usually just use the first letter of the type I am querying so in your case since it is of type Person I would do:

var lobjPerson = icolPerson.Where(p => p.person_id = 100);

Another example if it was say type Car I would do:

var lobjCar = icolCar.Where(c => c.car_id = 100);

I do this for quickness, however, I don't think there is anything wrong using full names in the query i.e. car => car.car_id

Answer 3

As long as your lambda expression is only a single statement, I'd keep the variable name as short as possible. The overall purpose of naming is to make the code readable, and in these cases, the method name and general context should be enough.

You don't have to use x all the time. For a Person object, I'd tend to use p instead.

If you need to write a more complex expression involving braces and semicolons, I'd say that all the normal naming rules apply.

Answer 4

I think the naming standard you use (hungarian notation) was the need of the hour when high profile tools like Visual Studio were not present. Today you have technologies like Intellisense which tell you most of the things you are doing wrong with a variable as you type, like assigning an int to a string. So, as of today, it is not an exclusive part of good coding conventions or standards as it used to be. Most people follow pascal casing or camel casing these days. If anybody uses it, I think it is more because of a personal preference.

Having said that, according to the way you code and name your variables, you should follow the second approach instead. Again, this boils down to you personal preference.

PS: This comment does not mean that I am looking down on your usage of hungarian notation. :)

Answer 5

My lambdas use one letter arguments, usually the first letter of what the parameter name would be:

• buttons.Select(b => b.Text);

• services.Select(s => s.Type);

But sometimes I add a few more letters to make things clearer, or to disambiguate between two parameters.

And when there isn't much meaning attached to the things I use xs and ys:

• values.Aggregate((x, y) => x + y);

All said, the standard I use for lambdas is shortness first, expressiveness later, because the context tends to help understand things (in the first example it's obvious that the b stands for a button).

Answer 6

If your collection is called something-persons, then it's obvious that when you're doing persons.Where(p => p.Whatever) that p is a person. If your lambdas are so complicated it's not immediately obvious whatever the parameters you're using are, then you shouldn't use lambdas at all, or make them drastically simpler.

As for your other conventions, what is the point of using Hungarian for calling out that personName is a string? It's obvious that a name would be a string. And why do you need a prefix to remind you that a variable is a local? Its declaration is necessarily in the same method, so that can't be so long ago that you've already forgotten it. If you have, then your methods are too long or complex.

Just have your identifiers appropriately describe what the meaning of the variable is, then the rest will be obvious.

Answer 7

I've done a lot of programming in VBScript (ASP), and there the use of hungarian notation to keep track of the data type was crucial to keep sane. In a type safe language like C# I find no use at all to use hungarian notation that way.

Descriptive variable names does very much for the readability of the code, but it doesn't always have to describe every aspect of a variable. A name like persons indicates that it's a collection of person objects, whether it's a List<Person> or IEnumerable<Person> is usually not that important to understand what the code is doing, and the compiler tells you immediately if you are trying to do something completely wrong.

I frequently use single letter variable names, where the scope of the variable is very limited. For example the i index variable in a small loop, or in lambda expressions.