0

I am used to

for(int i = ...)
    for(int j = ...)
        for(int k = ...)

If more than 2 nested indexes, then I give some of them proper names (item, obj, parent, window, etc.).

Then I am used to events with e as event argument and exceptions:

try { ... } catch (Exception... e)

If exception is inside event, then I use ee variable.

But what about linq? I see some peoples use

blablabla.Any(i => i.Value == SomeValue);

or

bla.Where(u => u.Something == Something);

Is there any standards of naming variables inside predicates or only opinions? Or is it just me? =D

Sinatr
  • 20,892
  • 15
  • 90
  • 319
  • 2
    There is no standard, just use what works for you. – Jason Evans Apr 07 '14 at 10:27
  • I use `x=>`. I have no Idea why am doing that ;) – Sriram Sakthivel Apr 07 '14 at 10:28
  • just be consistent. I don't see any reason for a long descriptive name as long as you are consistent. Long names are required, for good reason, in many code standards, but in LINQ, the context of the name is so close that a short consistent name is more readable. – Holstebroe Apr 07 '14 at 10:30
  • I prefer x (y,z for nested LINQ), since "x" does carry any semantic information. I wouldn't like "i,j,k", because there is often some integer algebra associated with those names. – Holstebroe Apr 07 '14 at 10:32
  • @Holstebroe, yes, `i`, `j`, `k` are too often used as indexers, so we are used to see them as those. `x`, `y`, `z` are commonly used as coords, which doesn't fit linq well. You see, my point is exactly that, I don't want to learn to use something what is not logical or confusing. I could use `x`, but after that question will use abbreviation or `item` instead. – Sinatr Apr 07 '14 at 10:35
  • @Sinatr, surely, if you are working on a project, where x,y,z has special semantic meaning, then it is not a good choice, but if you are not working with coords, then x,y,z are common general purpose algebraic placeholders. My point is that the name does not carry any useful information, it is right there in the context, in your case "bla", which is visually very close. – Holstebroe Apr 07 '14 at 10:38
  • @Holstebroe, if only use `x`, then perhaps, because it is associated as *unknown* in our minds (or *variable* in mind of programmers). But when it comes to having `x` and then `y`, then it will automatically break your brains to think it's coords. This is the point. So, `x` is good, but `x` and `y` together are less good than any *named* (`item`, `child`) or *abbreviated* (`c`ustomer, `c`lient, `a`rray, perhaps `l`ist?) thingies. – Sinatr Apr 07 '14 at 11:07
  • @Sinatr, if x, y will cause a slight confusion, I would recommend using "x" for non-nested LINQ and longer names for nested LINQ. Usually the other variable is some kind of list, where "x" is not a good name. If you have a list of list of pancakes, then "pancakes" would probably be more readable as the outer variable. Though, another common scenario for nested LINQ is if you are creating a functional programming style LINQ composition. Here I would go for very discrete names similar to what you would see in, say Haskell or Prolog, where placeholder scope is kept extremely short. – Holstebroe Apr 07 '14 at 11:53

2 Answers2

4

A common practice is to use a single letter, the first letter of the type, c for customers, p for products. x is used a lot, I use x when I am typing out the lambda but will usually refactor into a descriptive name or single letter that matches the collection item.

If it is more than a simple lambda, consider using a proper descriptive variable name as always.

The end goal is to make the code readable. If you feel a simple x is readable, use x. If you feel giving a full name more readable use a full name.

Sam Leach
  • 12,746
  • 9
  • 45
  • 73
  • nice tip, thanks! This is exactly the point, I don't feel good with that `i` or `x` by themselves. If `c` is used in place of customer list, then it is much more readable, then it would be blind `x`. – Sinatr Apr 07 '14 at 10:27
  • I prefer a consistent use of "x" over the first letter of the type. The context is right there in front of you, so "x" is just a little less information you need to interpret, which make it easier to read for me. – Holstebroe Apr 07 '14 at 10:35
  • Actually, now I see `o` (object) as a very valid name. It's short, unique and make sense in many scenaries. – Sinatr Apr 07 '14 at 11:11
  • Linq predicate variable is a variable. I'd say all the good practices still apply. In Clean Code book you will read that the variable name length should be proportional to the variable's scope. Therefore some use x or any other single letter name. Personally I recommend to always use short name which is a word. So if there is a collection of cars I name it car, collection of flights - flight. It works very well. Software is complex anyway, let's don't increase cognitive complexity by introducing shortcuts that needs to be interpreted/memorized. – Krystian Mar 03 '23 at 17:56
2

Let me expand on my comment above. I use common sense for some LINQ queries e.g.

bool hasExpiredItems = items.Any(item => item.IsExpired());

If I have a plural collection name then, as in this example with Any(), I use the singular item. This isn't a rule though, jsut use what you think makes sense.

EDIT:

Ooops, my example was wrong. Have updated it.

Jason Evans
  • 28,906
  • 14
  • 90
  • 154