I was reviewing a solution (not developed by Pentia) for a customer as they were concerned about the performance and stability of their site.
It didn’t take me long to find the following bit of code which calls the SQL server to find the languages for a given item:
I was shocked that anyone would not use the Languages property on the Item class, which would have replaced the entire function.
I think in all my years of Sitecore development this is the worst bit of code I have ever seen, it shows a complete lack of respect for the API and if the site was upgraded it is possible that the database schema could change and therefore the code would break!
On average the SQL query took 400mS (which is quite slow, but then again the SQL server was getting hit by 4 front end servers for every request).
The same call to the Item.languages took 0.1mS, this simple change made every request 400mS quicker and reduced the load on the SQL server considerably.
Alan Coates - Sitecore/.NET blog 
Ugh, I feel your pain. I come across “gems” like this from time to time as well. How about (written from memory – and this is probably nicer than the actual code):
public string GetSitecoreFieldValue(Item item, string fieldName)
{
Database master = Sitecore.Configuration.GetDatabase(“master”);
Item theItem = master.GetItem(item.Paths.FullPath);
Field field = theItem.Fields[fieldName];
if (field != null)
return field.Value;
return “”;
}
Nice 🙂
Ha Ha Ha… 🙂
Really a SQL lover and Sitecore API ignorer..
Tbf, I think another gem I have come across was (pseudo-code)
public string GetTranslation(string key)
{
Item dictionaryRoot = Sitecore.Context.Database.GetItem(“{path to dictionary root}”);
foreach(Item child in dictionaryRoot.GetChildren())
{
if(child[“key”] == key)
{
return child[“value”];
}
}
return String.Empty;
}
Not only was is wasteful on calls, the dictionary unfortunately was added to until it got > 500 items. The compounded by the fact the method was called for every text string on the page (some 60 – 70 calls). It was bad in production, but in the page editor, without the caching, it was horrendous.