ChallengeWrite the check in comment
In my code base, I have the following commit, which doesn’t have a checkin comment. This is the before:
private Entry GetEntryForSlug(string slug)
var entry = session.CreateCriteria(typeof(Entry))
if(entry != null)
//try load default document
return session.CreateCriteria(typeof (Entry))
.Add(Restrictions.Like("Slug", slug + "/default"))
And this is the after:
private Entry GetEntryForSlug(string slug)
var entries = session.CreateCriteria(typeof(Entry))
Restrictions.Like("Slug", slug) ||
Restrictions.Like("Slug", slug + "/default")
.OrderBy(x => x.Slug.Length)
What was the silent committer thinking about when he made the change? Can you write the check in comment?
More posts in "Challenge" series:
- (04 Jan 2023) what does this code print?
- (14 Dec 2022) What does this code print?
- (01 Jul 2022) Find the stack smash bug… – answer
- (30 Jun 2022) Find the stack smash bug…
- (03 Jun 2022) Spot the data corruption
- (06 May 2022) Spot the optimization–solution
- (05 May 2022) Spot the optimization
- (06 Apr 2022) Why is this code broken?
- (16 Dec 2021) Find the slow down–answer
- (15 Dec 2021) Find the slow down
- (03 Nov 2021) The code review bug that gives me nightmares–The fix
- (02 Nov 2021) The code review bug that gives me nightmares–the issue
- (01 Nov 2021) The code review bug that gives me nightmares
- (16 Jun 2021) Detecting livelihood in a distributed cluster
- (21 Apr 2020) Generate matching shard id–answer
- (20 Apr 2020) Generate matching shard id
- (02 Jan 2020) Spot the bug in the stream
- (28 Sep 2018) The loop that leaks–Answer
- (27 Sep 2018) The loop that leaks
- (03 Apr 2018) The invisible concurrency bug–Answer
- (02 Apr 2018) The invisible concurrency bug
- (31 Jan 2018) Find the bug in the fix–answer
- (30 Jan 2018) Find the bug in the fix
- (19 Jan 2017) What does this code do?
- (26 Jul 2016) The race condition in the TCP stack, answer
- (25 Jul 2016) The race condition in the TCP stack
- (28 Apr 2015) What is the meaning of this change?
- (26 Sep 2013) Spot the bug
- (27 May 2013) The problem of locking down tasks…
- (17 Oct 2011) Minimum number of round trips
- (23 Aug 2011) Recent Comments with Future Posts
- (02 Aug 2011) Modifying execution approaches
- (29 Apr 2011) Stop the leaks
- (23 Dec 2010) This code should never hit production
- (17 Dec 2010) Your own ThreadLocal
- (03 Dec 2010) Querying relative information with RavenDB
- (29 Jun 2010) Find the bug
- (23 Jun 2010) Dynamically dynamic
- (28 Apr 2010) What killed the application?
- (19 Mar 2010) What does this code do?
- (04 Mar 2010) Robust enumeration over external code
- (16 Feb 2010) Premature optimization, and all of that…
- (12 Feb 2010) Efficient querying
- (10 Feb 2010) Find the resource leak
- (21 Oct 2009) Can you spot the bug?
- (18 Oct 2009) Why is this wrong?
- (17 Oct 2009) Write the check in comment
- (15 Sep 2009) NH Prof Exporting Reports
- (02 Sep 2009) The lazy loaded inheritance many to one association OR/M conundrum
- (01 Sep 2009) Why isn’t select broken?
- (06 Aug 2009) Find the bug fixes
- (26 May 2009) Find the bug
- (14 May 2009) multi threaded test failure
- (11 May 2009) The regex that doesn’t match
- (24 Mar 2009) probability based selection
- (13 Mar 2009) C# Rewriting
- (18 Feb 2009) write a self extracting program
- (04 Sep 2008) Don't stop with the first DSL abstraction
- (02 Aug 2008) What is the problem?
- (28 Jul 2008) What does this code do?
- (26 Jul 2008) Find the bug fix
- (05 Jul 2008) Find the deadlock
- (03 Jul 2008) Find the bug
- (02 Jul 2008) What is wrong with this code
- (05 Jun 2008) why did the tests fail?
- (27 May 2008) Striving for better syntax
- (13 Apr 2008) calling generics without the generic type
- (12 Apr 2008) The directory tree
- (24 Mar 2008) Find the version
- (21 Jan 2008) Strongly typing weakly typed code
- (28 Jun 2007) Windsor Null Object Dependency Facility
I assume the || operator is a bug. The committer was probably thinking about a LINQ-like optimization.
Incidentally I did a very similar thing yesterday using Criteria lambda extensions. Instead of writing code like
myCriteria.Add<Person>(p => p.FirstName == fname)
myCriteria.Add<Person>(p => p.FirstName == fname &&
and it took me a minute to realize why I was getting a runtime exception.
Reduce number of potential queries by 50 %
I'd guess that it was rewritten to perform a single database query instead of unnecessarily performing two.
Maybe i'm wrong, but it doesn't like like neither of the queries are trying to archive the same result.
I've been bitten by this before.
UniqueResult will throw an exception if the query returns more than 1 row, which is quite possible when using LIKE.
He should use StringBuilder:
var sb = new StringBuilder().Append("slug").Append("/default") .ToString()
It would be faster.
why would that be faster? it would be slower.
comment: changed GetEntryForSlug to also return an entry for url with postfix "/default". first i try to find an entry that is an exact match for the slug. next i try it with a postfix. i ensured this by ordering by the length of the returned result list because the entry without postfix will be shorter and therefore first."
I get what the re-factor is doing, though I can't say I agree with it. The original code is pretty clear exactly what it's doing. return the item, if not found return the default, if not found, return #null. If anything, my only concern might be that the code is doing more than "one thing." For instance it might be a bit of a nuisance after the fact to determine if you actually retrieved an item or ended up with a default. But that's a digress.
The re-factor reduces the potential 2 queries to 1, however I'd say the readability of the intention of the code suffers. Get a list of the item an/or the item's default, then return the shortest one; assumed to be the item, if found, else the default, if found, else #null.
The thing is it took a couple careful passes looking at that to be sure it didn't have a "gotcha" or difference in behaviour. Frankly I favor readability over sheer optimization unless performance is a significant issue. Even so, in the ideal case where the "real" item is found, the extra query condition and LINQ sort & extraction is itself imparting an extra performance cost. I doubt the gain on average is more than negligible if anything at all.
Not sure what the actual choice in GIT comment ended up being, but I'd suggest that the following one should be an "Undo". ;)
While the code could certainly be more clear, it would be naive to suggest that the performance improvement is negligible. Surely you're not suggesting that an extra filter condition and a Linq OrderBy cost more than another round trip to the database...
To me, it really depends on how often we expect this code to load a default entry. If we are going to find real entry 90% of the time, I'd say leave the code as it was. If, instead, we're expecting to need a default entry around 50% of the time, and this code gets called frequently, then some kind of query optimization might make sense.
I don't know what this is from or for, but could it not have been written like:
private Entry GetEntryForSlug(string slug)
If so then that's far more read-able than both the original and committed... And it's not retrieving the result before deciding what to do with it...
Actually I just realized why the result was retrieved first, so that the orderby/firstordefault could be used against the resulted list...
Forget what I said I'm an idiot :)
It's an assumption either way. Based on that type of behaviour and where that method would likely be called, my guess would be it would be expecting to find the real one at least 50% of the time. The higher the percentage, the less effective that optimization becomes, and at some point it becomes an averaged penalty.
Still, my main point was that the re-factor hurt readability, and unless the gain was significant (i.e. noticable to the end user) then it wasn't worth it.
So obvious when working with ORMs :
Improved performance from 2 queries to one.
I wouldn't call this a "refactoring" as there is a clear change in behavior. This is a rewrite (on a small scale). A refactoring is "restructuring an existing body of code, altering its internal structure without changing its external behavior." as defined by Martin Fowler.
I would assume that said developer has a valid reason for this performance rewrite. neonp's "comment" seems the be the most accurate and concise.
What is the external behavior that was changed?
I knew that question would come up. Perhaps it's a stretch, but, I would say performance is the observable change in behavior here.
To me refactoring follows prescribed methods of modifying the structure of the code and has no effect on the algorithms in place. In the case above it seems the algorithm has been changed to observe improved performance.
I don't know, maybe Martin would ask what I've been smoking.
My logic may be slightly flawed, but it appears Martin and I are in agreement (well at least back in 2004)
@Mike: I'm not sure you're serious, but I know for sure that there are a lot of developers out there that actually believe that to be true. The matter of fact is that in simple concatenation cases like this using a StringBuilder would be orders of magnitude slower.
Comment : Did not slept well this night therefore i thought how i can screw up a working system.
The GetEntryForSlug now can return null, instead of throwing an exception when nothing matched (before uniqueresult, now firstordefault)
UniqueResult will return null if nothing is matched
I guess the comment counts for me then :P