jokiz : design guidelines

single letter variable names

jokiz — Mon, 08 Jan 2007 00:37:02 GMT

If j(i) < 1 Then m = m + j(i - 1) Else m = m + j(i - 1) - 1

Single letter variables are good for iterators, but if integer variables will involve coditions such as the statement above, better use a more descriptive variable or refactor the said line to a method with a descriptive name. I guess if you're using vb6/vba, you cannot escape from transitioning values between 0 index to 1 index conditionals.

to derive or not to derive from ApplicationException

jokiz — Tue, 27 Jun 2006 10:13:00 GMT

remember the rule to always derive custom exceptions from ApplicationException? so you thought that the CLR never throws an ApplicationException? Krzysztof Cwalina (co-author of Brad Adams in the famous Framework Design Guidelines book) blogs about the exception (pun) here.

Do not call overridable methods in constructors

jokiz — Thu, 25 May 2006 09:12:00 GMT

I noticed that Resharper 2.0 highlighted (meaning it is against a rule) a call to a virtual method in a constructor in one of my business objects. It gave me the following information information in msdn (http://msdn2.microsoft.com/en-us/library/ms182331.aspx)

Looking at the sample code from the link above, the base class calling the virtual method. I expect the override to be called eventhough the subclass is not yet fully instantiated. Does it mean that other languages expect the base class virtual method to be called when the subclass is not yet instantiated?

String Property construct

jokiz — Tue, 18 Apr 2006 00:25:00 GMT

anybody who is also using this construct for string properties? we rarely want our string properties to be null and since it is a reference type, we have to have handling for it. can you see any disadvantage of such construct?

[code language="C#"]
        public string StringProperty
        {
            get { return _stringProperty; }
            set
            {
                if(value == null) value = string.Empty;
                //Do whatever
            }
        }
[/code]

TDS Protocol

jokiz — Sun, 26 Feb 2006 07:24:00 GMT

For most of you who have been using stored procedures and following the MS guidelines in .NET Application Development, you must have been using SET NOCOUNT ON as stated in Chapter 12 of the Improving .NET Application Performance and Scalability.

Although the MSDN docs was enough to tell me that with NOCOUNT set to OFF (man, their keyword sucks, the one often used should be the default variable, this is just like IsPostBack for ASPNET), the row count data which is often not needed is always transferred, I wanted to know the internals of the data being passed between SQL Server and the client application. I was lucky to find this TDS Documentation.

As many of you know, SQL Server uses this Tabular Data Stream Protocol in passing data. The TDS documentation was able to give me a snapshot of how data is being transferred between SQL Server and the SQLClient Data Provider.

http://www.freetds.org/tds.html

Naming Guidelines

jokiz — Wed, 09 Nov 2005 13:16:00 GMT

In response to dehranph's comment on my previous post (http://community.devpinoy.org/blogs/joeycalisay/archive/2005/11/08/401.aspx), it reminded me of the naming guidelines in .NET.

His comment was about the DeleteCustomer method which has a Customer object as parameter, which we both agreed to be redundant and should have been just a Delete method with a Customer instance as parameter.

It's very important for me to follow the naming guidelines for readability. As for the scenario cited, it also shortens codes because for me, i hate it when I can't fit a single method call or an if test in just one line (especially if I'm using an 800x600 resolution).

In addition, naming classes with an acronym (two or three letter of the project name) before each classes is a PITA for me. It's the primary purpose of namespaces in .NET!

OOP-Encapsulation issues

jokiz — Tue, 08 Nov 2005 12:14:00 GMT

As I was refactoring some of our codes, what struck me was the idea of object oriented programming particularly encapsulation.

For example, we have this Customer object which is distinct with its CustomerID property. We needed to have versioning for the said entity and so we introduced an additional Version integer property. I've been seeing routines throwing CustomerID alongside Version to refer to a particular Customer object. Ideally (from what I know), the said routines should be just interacting with an instance of Customer object in the first place. The versioning should have been implemented internally through encapsulation and calling routines should be unaware about versioning which should've been handled by the Cutomer class himself.

I hate to see codes throwing and consuming PK's of business entities as parameters and not instances of business entities. Anyone who wants to shed a light on these? Am I on the right track?

ArgumentNullException - API design hall of shame

jokiz — Tue, 21 Jun 2005 21:21:00 GMT

I have read this before but just want to make a permanent reference to it in this blog.

Brad Adams explains why the ArgumentNullException class violates the Design Guidelines here for not following the exception constructor patterns.

http://blogs.msdn.com/brada/search.aspx?q=argumentnullexception&p=1

Designing .NET Class Libraries Series

jokiz — Mon, 25 Apr 2005 06:30:00 GMT

I've seen a part of this (Brad Adams presentation on Naming) perhaps a month ago, I just discovered that it is a part of a good set of webcasts worth seeing. Can't wait to see Brian Pepin's presentation (design time guru).

http://msdn.microsoft.com/netframework/programming/classlibraries/

Code Complete 1st edition

jokiz — Thu, 21 Apr 2005 06:18:00 GMT

I was reading Steve McConnell's first edition of Code Complete and the book is highly recommended. Although the sample uses old languages like pascal and c, and some topics does not apply to current programming languages, I love the way he presents his arguments on how to do things the right way. Although one might not agree on all his suggestions/views, it is worth reading and knowing his guidelines in coding. The second edition is obviously on my books-to-buy list.

Hungarian Notation

jokiz — Tue, 29 Mar 2005 05:42:00 GMT

I started programming with C and used Hungarian notation since then. It was very helpful back then to instantly know what type the variable is from its name.

When I started programming in .NET using Visual Studio, Intellisense made a major breakthrough and helped a lot. You just point your mouse over a variable and intellisense will provide you with its underlying type. Not to mention the automatic dropdown of object members after a dot(.) operator.

Upon seeing a number of codes on the net and knowing the preferred convention of on naming variables, I started to realize that I'm beginning to hate Hungarian Notation. I don't want to see those str prefixes on string variables, etc. And besides, if you follow today's standard naming guidelines, you can deduce from the variable names their types.

Property Naming WTF

jokiz — Fri, 18 Mar 2005 04:53:00 GMT

I got tired of seeing a common property of our controls (since it is part of an interface) and this week, I got fed up and can’t take it anymore seeing them.

AlignmentInContainer

You might suggest ContainerAlignment but layout properties obviously relates the control to its immediate parent container. Just like Anchor and Dock properties, the container word is unnecessary. I renamed it to just:

Alignment

Rethrowing exceptions, the right way

jokiz — Mon, 21 Feb 2005 04:04:00 GMT

I have read the Exception Handling Best Practices article in .NET in CodeProject and all this time I thought that rethrowing exceptions is this way:

[code language="C#"]
try
{
    // Some code that throws an exception
}
catch (Exception ex)
{
    // some code that handles the exception
    throw ex;
}
[/code]

I just learned that it should have been this way:

[code language="C#"]
try
{
    // Some code that throws an exception
}
catch (Exception ex)
{
    // some code that handles the exception
    throw;
}
[/code]

Reason: Stack Trace Preservation

Currently, I still don’t have a solid understanding on .NET Exceptions, its internals, etc. I still have to do a number of readings about them…