Combine linq statement or leave
up vote
-2
down vote
favorite
I have the following code. Should the linq statements be combined or left as is?
I typically like to break it up but some members on my team like a one-liner.
Thoughts?
var startDate = DateTime.UtcNow;
var endDate = startDate.AddDays(expirationDays);
var allTokens = await repository.Query<Domain.Models.AccessToken>()
.Where(x => !x.IsRevoked)
.ToListAsync()
.ConfigureAwait(false);
var filteredTokens = allTokens.GroupBy(x => x.ApplicationName)
.Select(y => y.OrderByDescending(z => z.ExpirationDate).FirstOrDefault())
.Where(x => x != null && ! x.IsRevoked && x.ExpirationDate >= startDate && x.ExpirationDate <= endDate);
return filteredTokens.Select(x => x.Id).ToList();
c# linq
add a comment |
up vote
-2
down vote
favorite
I have the following code. Should the linq statements be combined or left as is?
I typically like to break it up but some members on my team like a one-liner.
Thoughts?
var startDate = DateTime.UtcNow;
var endDate = startDate.AddDays(expirationDays);
var allTokens = await repository.Query<Domain.Models.AccessToken>()
.Where(x => !x.IsRevoked)
.ToListAsync()
.ConfigureAwait(false);
var filteredTokens = allTokens.GroupBy(x => x.ApplicationName)
.Select(y => y.OrderByDescending(z => z.ExpirationDate).FirstOrDefault())
.Where(x => x != null && ! x.IsRevoked && x.ExpirationDate >= startDate && x.ExpirationDate <= endDate);
return filteredTokens.Select(x => x.Id).ToList();
c# linq
ha, that's completely up to you. Kind of hard to answer that question.
– ylax
Nov 19 at 21:32
The main difference here is how much data you end up pulling from the DB and filtering in memory instead of letting the DB handle for you.
– juharr
Nov 19 at 21:32
1
Do you needallTokens
to be a list? Is it a Queryable without theToListAsync
call? If so, then, if you remove theToListAsync
call, doing it all in one go or as three separate statements is purely a matter of taste.
– Flydog57
Nov 19 at 21:41
add a comment |
up vote
-2
down vote
favorite
up vote
-2
down vote
favorite
I have the following code. Should the linq statements be combined or left as is?
I typically like to break it up but some members on my team like a one-liner.
Thoughts?
var startDate = DateTime.UtcNow;
var endDate = startDate.AddDays(expirationDays);
var allTokens = await repository.Query<Domain.Models.AccessToken>()
.Where(x => !x.IsRevoked)
.ToListAsync()
.ConfigureAwait(false);
var filteredTokens = allTokens.GroupBy(x => x.ApplicationName)
.Select(y => y.OrderByDescending(z => z.ExpirationDate).FirstOrDefault())
.Where(x => x != null && ! x.IsRevoked && x.ExpirationDate >= startDate && x.ExpirationDate <= endDate);
return filteredTokens.Select(x => x.Id).ToList();
c# linq
I have the following code. Should the linq statements be combined or left as is?
I typically like to break it up but some members on my team like a one-liner.
Thoughts?
var startDate = DateTime.UtcNow;
var endDate = startDate.AddDays(expirationDays);
var allTokens = await repository.Query<Domain.Models.AccessToken>()
.Where(x => !x.IsRevoked)
.ToListAsync()
.ConfigureAwait(false);
var filteredTokens = allTokens.GroupBy(x => x.ApplicationName)
.Select(y => y.OrderByDescending(z => z.ExpirationDate).FirstOrDefault())
.Where(x => x != null && ! x.IsRevoked && x.ExpirationDate >= startDate && x.ExpirationDate <= endDate);
return filteredTokens.Select(x => x.Id).ToList();
c# linq
c# linq
asked Nov 19 at 21:17
Jason Jay
325
325
ha, that's completely up to you. Kind of hard to answer that question.
– ylax
Nov 19 at 21:32
The main difference here is how much data you end up pulling from the DB and filtering in memory instead of letting the DB handle for you.
– juharr
Nov 19 at 21:32
1
Do you needallTokens
to be a list? Is it a Queryable without theToListAsync
call? If so, then, if you remove theToListAsync
call, doing it all in one go or as three separate statements is purely a matter of taste.
– Flydog57
Nov 19 at 21:41
add a comment |
ha, that's completely up to you. Kind of hard to answer that question.
– ylax
Nov 19 at 21:32
The main difference here is how much data you end up pulling from the DB and filtering in memory instead of letting the DB handle for you.
– juharr
Nov 19 at 21:32
1
Do you needallTokens
to be a list? Is it a Queryable without theToListAsync
call? If so, then, if you remove theToListAsync
call, doing it all in one go or as three separate statements is purely a matter of taste.
– Flydog57
Nov 19 at 21:41
ha, that's completely up to you. Kind of hard to answer that question.
– ylax
Nov 19 at 21:32
ha, that's completely up to you. Kind of hard to answer that question.
– ylax
Nov 19 at 21:32
The main difference here is how much data you end up pulling from the DB and filtering in memory instead of letting the DB handle for you.
– juharr
Nov 19 at 21:32
The main difference here is how much data you end up pulling from the DB and filtering in memory instead of letting the DB handle for you.
– juharr
Nov 19 at 21:32
1
1
Do you need
allTokens
to be a list? Is it a Queryable without the ToListAsync
call? If so, then, if you remove the ToListAsync
call, doing it all in one go or as three separate statements is purely a matter of taste.– Flydog57
Nov 19 at 21:41
Do you need
allTokens
to be a list? Is it a Queryable without the ToListAsync
call? If so, then, if you remove the ToListAsync
call, doing it all in one go or as three separate statements is purely a matter of taste.– Flydog57
Nov 19 at 21:41
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
Personally, I follow the mantra, "Programs must be written for people to read, and only incidentally for machines to execute" (Harold Abelson.) Make the code as readable as possible (and only then worry about optimizations/efficiency/etc if needed). It's easier to optimize clean code than it is to clean up optimized code.
So on that important readability front, I'd say: Break them Up! Breaking up your LINQ statements into multiple lines lets you do something very very valuable:
var records = someLinqStatement;
var activeUserRecords = records.SomeLinqStatement;
var mostRecentUserRecords = activeUserRecords.SomeLinqStatement;
... it lets you use the variable name to document the contents of the linq. You're using it to improve the readability of your code. If anything, you've grouped too much (there's a lot going on in that 3-line filteredTokens line in your version.)
Trying to read what your coworkers would have:
var allTokens = await repository.Query<Domain.Models.AccessToken>()
.Where(x => !x.IsRevoked)
.ToListAsync()
.ConfigureAwait(false)
.GroupBy(x => x.ApplicationName)
.Select(y => y.OrderByDescending(z => z.ExpirationDate).FirstOrDefault())
.Where(x => x != null && ! x.IsRevoked && x.ExpirationDate >= startDate && x.ExpirationDate <= endDate)
.Select(x => x.Id).ToList();
... is a freaking nightmare. At that point, I'm no longer reading code, I'm slowly trying to decipher it.
1
This also makes it easy to view intermediate results when debugging.
– TrueWill
Nov 19 at 22:20
1
@TrueWill - very very good point. :-)
– Kevin
Nov 19 at 22:22
agreed, thank you
– Jason Jay
Nov 19 at 22:25
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
Personally, I follow the mantra, "Programs must be written for people to read, and only incidentally for machines to execute" (Harold Abelson.) Make the code as readable as possible (and only then worry about optimizations/efficiency/etc if needed). It's easier to optimize clean code than it is to clean up optimized code.
So on that important readability front, I'd say: Break them Up! Breaking up your LINQ statements into multiple lines lets you do something very very valuable:
var records = someLinqStatement;
var activeUserRecords = records.SomeLinqStatement;
var mostRecentUserRecords = activeUserRecords.SomeLinqStatement;
... it lets you use the variable name to document the contents of the linq. You're using it to improve the readability of your code. If anything, you've grouped too much (there's a lot going on in that 3-line filteredTokens line in your version.)
Trying to read what your coworkers would have:
var allTokens = await repository.Query<Domain.Models.AccessToken>()
.Where(x => !x.IsRevoked)
.ToListAsync()
.ConfigureAwait(false)
.GroupBy(x => x.ApplicationName)
.Select(y => y.OrderByDescending(z => z.ExpirationDate).FirstOrDefault())
.Where(x => x != null && ! x.IsRevoked && x.ExpirationDate >= startDate && x.ExpirationDate <= endDate)
.Select(x => x.Id).ToList();
... is a freaking nightmare. At that point, I'm no longer reading code, I'm slowly trying to decipher it.
1
This also makes it easy to view intermediate results when debugging.
– TrueWill
Nov 19 at 22:20
1
@TrueWill - very very good point. :-)
– Kevin
Nov 19 at 22:22
agreed, thank you
– Jason Jay
Nov 19 at 22:25
add a comment |
up vote
2
down vote
accepted
Personally, I follow the mantra, "Programs must be written for people to read, and only incidentally for machines to execute" (Harold Abelson.) Make the code as readable as possible (and only then worry about optimizations/efficiency/etc if needed). It's easier to optimize clean code than it is to clean up optimized code.
So on that important readability front, I'd say: Break them Up! Breaking up your LINQ statements into multiple lines lets you do something very very valuable:
var records = someLinqStatement;
var activeUserRecords = records.SomeLinqStatement;
var mostRecentUserRecords = activeUserRecords.SomeLinqStatement;
... it lets you use the variable name to document the contents of the linq. You're using it to improve the readability of your code. If anything, you've grouped too much (there's a lot going on in that 3-line filteredTokens line in your version.)
Trying to read what your coworkers would have:
var allTokens = await repository.Query<Domain.Models.AccessToken>()
.Where(x => !x.IsRevoked)
.ToListAsync()
.ConfigureAwait(false)
.GroupBy(x => x.ApplicationName)
.Select(y => y.OrderByDescending(z => z.ExpirationDate).FirstOrDefault())
.Where(x => x != null && ! x.IsRevoked && x.ExpirationDate >= startDate && x.ExpirationDate <= endDate)
.Select(x => x.Id).ToList();
... is a freaking nightmare. At that point, I'm no longer reading code, I'm slowly trying to decipher it.
1
This also makes it easy to view intermediate results when debugging.
– TrueWill
Nov 19 at 22:20
1
@TrueWill - very very good point. :-)
– Kevin
Nov 19 at 22:22
agreed, thank you
– Jason Jay
Nov 19 at 22:25
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
Personally, I follow the mantra, "Programs must be written for people to read, and only incidentally for machines to execute" (Harold Abelson.) Make the code as readable as possible (and only then worry about optimizations/efficiency/etc if needed). It's easier to optimize clean code than it is to clean up optimized code.
So on that important readability front, I'd say: Break them Up! Breaking up your LINQ statements into multiple lines lets you do something very very valuable:
var records = someLinqStatement;
var activeUserRecords = records.SomeLinqStatement;
var mostRecentUserRecords = activeUserRecords.SomeLinqStatement;
... it lets you use the variable name to document the contents of the linq. You're using it to improve the readability of your code. If anything, you've grouped too much (there's a lot going on in that 3-line filteredTokens line in your version.)
Trying to read what your coworkers would have:
var allTokens = await repository.Query<Domain.Models.AccessToken>()
.Where(x => !x.IsRevoked)
.ToListAsync()
.ConfigureAwait(false)
.GroupBy(x => x.ApplicationName)
.Select(y => y.OrderByDescending(z => z.ExpirationDate).FirstOrDefault())
.Where(x => x != null && ! x.IsRevoked && x.ExpirationDate >= startDate && x.ExpirationDate <= endDate)
.Select(x => x.Id).ToList();
... is a freaking nightmare. At that point, I'm no longer reading code, I'm slowly trying to decipher it.
Personally, I follow the mantra, "Programs must be written for people to read, and only incidentally for machines to execute" (Harold Abelson.) Make the code as readable as possible (and only then worry about optimizations/efficiency/etc if needed). It's easier to optimize clean code than it is to clean up optimized code.
So on that important readability front, I'd say: Break them Up! Breaking up your LINQ statements into multiple lines lets you do something very very valuable:
var records = someLinqStatement;
var activeUserRecords = records.SomeLinqStatement;
var mostRecentUserRecords = activeUserRecords.SomeLinqStatement;
... it lets you use the variable name to document the contents of the linq. You're using it to improve the readability of your code. If anything, you've grouped too much (there's a lot going on in that 3-line filteredTokens line in your version.)
Trying to read what your coworkers would have:
var allTokens = await repository.Query<Domain.Models.AccessToken>()
.Where(x => !x.IsRevoked)
.ToListAsync()
.ConfigureAwait(false)
.GroupBy(x => x.ApplicationName)
.Select(y => y.OrderByDescending(z => z.ExpirationDate).FirstOrDefault())
.Where(x => x != null && ! x.IsRevoked && x.ExpirationDate >= startDate && x.ExpirationDate <= endDate)
.Select(x => x.Id).ToList();
... is a freaking nightmare. At that point, I'm no longer reading code, I'm slowly trying to decipher it.
answered Nov 19 at 22:16
Kevin
1,524417
1,524417
1
This also makes it easy to view intermediate results when debugging.
– TrueWill
Nov 19 at 22:20
1
@TrueWill - very very good point. :-)
– Kevin
Nov 19 at 22:22
agreed, thank you
– Jason Jay
Nov 19 at 22:25
add a comment |
1
This also makes it easy to view intermediate results when debugging.
– TrueWill
Nov 19 at 22:20
1
@TrueWill - very very good point. :-)
– Kevin
Nov 19 at 22:22
agreed, thank you
– Jason Jay
Nov 19 at 22:25
1
1
This also makes it easy to view intermediate results when debugging.
– TrueWill
Nov 19 at 22:20
This also makes it easy to view intermediate results when debugging.
– TrueWill
Nov 19 at 22:20
1
1
@TrueWill - very very good point. :-)
– Kevin
Nov 19 at 22:22
@TrueWill - very very good point. :-)
– Kevin
Nov 19 at 22:22
agreed, thank you
– Jason Jay
Nov 19 at 22:25
agreed, thank you
– Jason Jay
Nov 19 at 22:25
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53382763%2fcombine-linq-statement-or-leave%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
ha, that's completely up to you. Kind of hard to answer that question.
– ylax
Nov 19 at 21:32
The main difference here is how much data you end up pulling from the DB and filtering in memory instead of letting the DB handle for you.
– juharr
Nov 19 at 21:32
1
Do you need
allTokens
to be a list? Is it a Queryable without theToListAsync
call? If so, then, if you remove theToListAsync
call, doing it all in one go or as three separate statements is purely a matter of taste.– Flydog57
Nov 19 at 21:41