Being Cellfish

Stuff I wished I've found in some blog (and sometimes did)

August, 2009

Change of Address
This blog has moved to
  • Being Cellfish

    20 tips to write a good stored procedure (is really just 12)


    A few days ago there was an article with 20 tips to write a good stored procedure (requires free registration to read). The problem is that there are really only 12 good tips (and 4 bad and 4 neither good or bad). So let me go over the tips one by one and comment on them:

    1. Capital letters for keywords and proper indentation. With todays code editors with syntax high lighting I don't see why you want to high light keywords with capital letters. The code editor will do that for you. And suggesting proper indentation is not really a tip to write a good stored procedure. It's common (coding) sense! So I don't think this one counts... Score (good-not really-bad advice IMHO): 0-1-0.
    2. Use SQL-92 syntax for joins. If MS SQL server drops support for the old syntax this is good advice. Score: 1-1-0
    3. Use as few variables as possible. The article mentions cache utilization as an argument. Sounds like premature optimization to me. I'd say use as many variables as makes sense to make the code most readable. If that turns out to be a problem, then you optimize. So in general I found this advice to be bad. Score: 1-1-1
    4. Minimize usage of dynamic queries. Kudos to the article to pointing out how to minimize the bad of dynamic queries and I guess technically minimizing could mean zero but that is really the only good advice; don't use dynamic queries. So once again a bad, or at least misleading advice IMHO. Score: 1-1-2
    5. Use fully qualified names. If you don't do this you might end up with some weird behavior so this is a good advice. Score: 2-1-2
    6. Set NOCOUNT on. Good advice: Score: 3-1-2
    7. Don't use sp_ prefix. Score: 4-1-2
    8. KEEPFIXED PLAN. Learn from this article and use it correctly. Hard to argue with "learn something and use it right". Score: 5-1-2
    9. Use select instead of set. Once again performance is mentioned as a motivator. However the potential bad side effects of using select rather than set are more important in my opinion. The problem with select is that the variable might not be set if a query returns no rows and the set gives you an error if the select returns more than one row. Read more about it here. I'd definitely prefer set over select. Score: 5-1-3
    10. Compare the right thing in the where clause. This advice just confuses me. The article talks about what operators are the fastest and then refers to this page talking about preference. Even though the article is confusing on this point the basic idea is correct. For example using IN is generally faster than NOT IN. So I'll call this one a draw. Score: 5-2-3
    11. Avoid OR in WHERE clause. This is good advise for good performance. Score: 6-2-3
    12. Use CAST over Convert. CAST is SQL92 standard. Convert is not. Score: 7-2-3
    13. Avoid distinct and order by. Once again this is common sense. Don't do things you don't need... Score: 7-3-3
    14. Avoid cursors. This falls into the same category as dynamic queries to me. The only good advice is don't use cursors. Score: 7-3-4
    15. Select only the columns you need. Common sense! Score: 7-4-4
    16. Sub queries vs joins. Article lists a few good rule of thumbs. I think you should use whatever is most readable. Score: 8-4-4
    17. Create table vs select into. Article points out important differences. Score: 9-4-4
    18. Use variables instead of temporary tables. Score: 10-4-4
    19. Use proper indexes. Score: 11-4-4
    20. Use profiler. Many tips in the article suggest you do things to improve performance. But I think doing so before you know you have a problem is a waste of time and resources. So this advice is actually one of the best advices in the article. Score: 12-4-4
  • Being Cellfish

    Object Calisthenics: First contact


    A few weeks ago I was introduced the the object calisthenics described by Jeff Bay in the book The ThoughtWorks Anthology. The object calisthenics is a way to practice writing object oriented code. The nine rules of are not intended to be used in your every day work. The rules are intended to be used on a small problem such as a coding Kata. The idea is that by applying these strict rules on a small problem you'll learn to write better code.

    So I decided to try this on the MineSweeper Kata. In the beginning I decided to try to conform to the rules all the time, but pretty soon I changed my mind and wrote a working solution and then started to refactored to conform to the rules. I think this was a mistake. Some design decisions turned out to require very big refactorings when conforming to the rules and I actually never got all the way. But this doesn't mean I didn't learn anything. First of all I think I experienced a variant of you can't test in quality, you have to build it in from the start. I should have stuck with the initial strategy and make sure the code followed the rules all the time. I also learned that classes that I felt were really small and doing only one thing actually could be split up when I had to in order to conform to the rules. Reminds me of when people thought atoms were the smallest building blocks of the universe and then it turned out to be something smaller...

    So all in all I think doing a coding Kata while applying the object calisthenics rules will improve my ability to write object oriented code. And it will be interesting to see how it works out in a coding dojo. By now you're probably wondering what the nine rules are. The rules are:

    1. Use one level of indentation per method
    2. Don't use the else keyword
    3. Wrap all primitives and strings
    4. Use only one dot per line
    5. Don't abbreviate
    6. Keep all entities small
    7. Don't use any classes with more than two instance variables
    8. Use first class collections
    9. Don't use any getters, setters or properties

    I'll go into more detail of these nine rules over the next few days.

  • Being Cellfish

    Object Calisthenics: Rule 2: Don't use the else keyword


    Some people think that the if branch should be the every thing is good branch and the else branch being the error case. Others think the if branch should be as short as possible since it makes it easier to understand what would bring us into the else branch. But this rule is not about what guideline is the best. It is about putting you into a situation where you have to consider other ways to implement your conditional logic. Polymorphism and the Null Object pattern being two good alternatives.

  • Being Cellfish

    Object Calisthenics: Rule 1: Use one level of indentation per method


    First of all a method with a lot of different indentation is harder to understand than a method with less indentation. I also think that each level of indentation typically means you're doing another thing. Look at this code:

    1: public void Format() 2: { 3: for (int row=0; row<rows; row++) 4: { 5: for (int column=0; column<columns; column++) 6: { 7: grid[row,column].Format(); 8: } 9: } 10: }

    The nested for loop introduces two levels of indentation. One of them can be refactored into a second method so it looks like this:

    1: public void Format() 2: { 3: for (int row=0; row<rows; row++) 4: { 5: FormatRow(row); 6: } 7: } 8:   9: private void FormatRow(int row) 10: { 11: for (int column=0; column<columns; column++) 12: { 13: grid[row,column].Format(); 14: } 15: }

    Some people might say that it is just another level of indirection and that we have now made the Format method harder to understand since we also have to look in the FormatRow method to understand what is happening. I think that is only true if you use bad method names I'm perfectly fine with assuming that FormatRow actually formats a row without looking at the code for FormatRow. So if extracting code to a separate method will make your code less readable you're probably not giving the method a very good name.

    Some people also scream that more methods means bad performance. First; believe in the compilers ability to optimize code for you. Second; only optimize what is proved to be a bottleneck. I think readability is preferred over any theoretical performance issue. Only real performance issues should be addressed.

    Last but not least, this rule is not intended to be used in your production code. We're talking object calisthenics, remember? If you want to apply this rule to your real code you probably want to say use as few levels of indentations as possible in each method.

  • Being Cellfish

    Object Calisthenics: Rule 8: Use first class collections

    Yet another rule to keep your objects focused at a single responsibility. Any class with an instance variable that is a collection should have no other instance variables. When I first tried object calisthenics this was actually easier said than done. Having a collection and some other instance variable made sense a few times, but once I wrapped the collection into a separate class I actually ended up with less code duplication.
  • Being Cellfish

    Object Calisthenics: Rule 3: Wrap all primitives and strings


    This rule states that no parameters should be a of a primitive type (e.g. int, double) nor a string. Instead new objects should be created to represent what the parameters are. Is the integer really representing money or a coordinate. This small classes also creates great places to put methods that manipulate whatever the primitive type represents.

    When I first tried the object calisthenics this was one of the harder rules actually. Not by itself but because of the ninth rule; don't use getters or setters. Together it really makes you have to think about how to represent things in your code.

    By itself I think this rule is one rule that easily translates to your real code. Making sure you're passing objects to your methods which actually are what they represent rather than a primitive type that represent something is generally a good thing if you some day have to change the representation. E.g. money should be a double rather than an integer.

  • Being Cellfish

    Object Calisthenics: Rule 5: Don't abbreviate


    This rule has a weird name I think. What it means is that whenever you abbreviate in a class or method name you should think about why you do that. The assumption is that if you feel you need to abbreviate something it means you're using it too much. Also that a long method name typically means there is another class that could be created. A simple example would be an order object with a method "CreateInvoice". Maybe a better solution is to have an invoice object with a "Create" method.

    The confusing part however is that don't abbreviate to me means writing everything out. But the explanation for this rule is that you should not abbreviate anything and each class and method name should be one or two words only. This is a fairly easy rule to conform to when practicing object calisthenics.

  • Being Cellfish

    Object Calisthenics: Rule 4: Use only one dot per line


    Not only is a long line with a lot of dots harder to understand. It usually means that your object is using not only the objects it knows but the objects their "friends" know too. Having only one dot per line does not only make your code more readable. It also helps putting the code in the right place. Consider this method:

    1: public void Update() 2: { 3: context.CurrentSession.Update(); 4: }

    Changing it to this is not the intention of this rule:

    1: public void Update() 2: { 3: Session session = context.CurrentSession; 4: session.Update(); 5: }

    Rather the rule want you to do this:

    1: private void Update() 2: { 3: context.Update(); 4: }

    And here the Update method of the context object has been left out, but it would only call Update on the CurrentSession object. All in all I think this is a rule that is suitable for production code too.

  • Being Cellfish

    Object Calisthenics: Rule 9: Don't use any getters, setters or properties

    This is my favorite rule. I think it's a forgotten guideline in OO design to tell objects what to do with their state rather than asking for their state. Applying this rule to code changed the way I had to write code most of all rules. Keeping classes under 50 lines changed a lot but this rule is much harder to apply than just extracting methods and classes. You really have to rethink the way you write your code I think. Actually I think that if you're going to try object calisthenics and only want to use one rule, this is probably the rule you should use.
  • Being Cellfish

    Object Calisthenics: Rule 7: Don't use any classes with more than two instance variables


    This is another aspect of keeping your entities small I think. Classes with a lot of instance variables tend to have more than one responsibility. This rule may also help you create a more generic design if used correctly. For example consider you want a class representing the names (first, last and middle) of a person. Since this would be three strings you choose to represent it as GivenNames and LastName where GivenNames is another class with a list of names. Suddenly you support any number of first/middle names. So a more generic solution. End even if you don't do this and let GivenNames only have two names (First and Middle) this can be changed more easily in the future.

    All that said, remember that this is a rule intended for practice, not necessarily a good thing to always use in all code.

Page 1 of 2 (17 items) 12