Code structure: Size and layout

How many times have you come across a source file that is so huge in length that to trace a part of code in it can get you sick, not only because there is too much of code to dig into but also because the scroller is too small to grab? ;-)

It is important to know when it is enough!

• If a method exceeds beyond 30-40 lines, you should consider splitting into further segments. Rarely business logic has to be written above 40 lines without an option to divide it into segments. As long as dividing the code into methods makes sense, it does not matter. Compartmentalized code only makes it readable and easier to understand.
• Watch the number of arguments that a methods has. If the list of arguments exceeds 5-6, think again. May be, you can use a structure as class for it. You don’t want to have a terrible argument list as the COM methods in Office Automation, do you?
• 300-400 lines of code in a file already make the file huge. If a source file exceeds this limit, you must be missing something. Check if a new class can be introduced or your code is not optimized enough.

Layout of code

Just like a blueprint for a building or an editor’s draft of a book, the code layout is very important. When you are using Word or any similar editor, have you not noticed how many option are available to format the text (with options for headings, subheadings, emphasis and much more; we call them markup)? What is the advantage of a good layout or formatting of code? You make the code readable and help others to easily maintain it when needed.

How easy it is to understand a statement like this:

querystring="name="+userName+"&userid="+userID+"&email="+email;

For developers who are familiar with Visual Basic (that uses & operator to concatenate) and C# (that uses + operator to concatenate), this statement must hold you for a while before you figure out which operator is used to concatenate the string.

Now what about this:

querystring = "name=" + userName + "&userid=" + userID + "&email=" + email;

It is the same statement, but the concatenation operator (+ in this case) is so distinct compared to earlier example.

Let us talk about the standards for code layout:

• Always indent code. Use tabs to indent code, not spaces.
  There is enough argument on the web on whether to use spaces or tabs to indent. Using tabs can be troublesome if different developers use different length of spacing for tabs, while using spaces has always been a tedious job. However, when all developers are using the same editor (everyone in our organization uses Visual Studio 2005 or 2008 for development in C# with default setting of tab at 4 characters), using tabs is the best way to indent.
  
  
• Never leave more than one blank line between statements.
  Blank lines should be used to separate units as methods, and also separate different segments of code for clarity. However, it is never necessary to use more than one blank line anywhere in code. Avoid using more than one blank line, but do not forget to use blank lines completely. You must use a single blank line always to separate methods and logical segments of code.
  
  
• Know when to use spaces and when not.
• Always use a space between an operator and an operand. However, in case of unary, increment or decrement operator, do not use a space between the operator and the operand.
• For flow control primitives (if, else, while, do, for, switch), always put a space between the keyword and the starting bracket. But do not use a space between bracket and text inside a bracket.
• Always follow a comma or a semicolon with a space.
• Do not use a space between the methods name and bracket in method while defining or calling a method.
• Do not use a space within square brackets for subscripts.
  

Bad: if (x==y) for(i=0;i<10;i++) BuildSampleString ( myChar, 0, 1 ); x = dataArray[ index ];

Good: if (x == y) for (i = 0; i < 10; i++) BuildSampleString(myChar, 0, 1); x = dataArray[index];

• Always put curly braces on a separate line.
  For example:
  
  class MyClass {
     …
  }
  
  or
  
  if (x == y) {
     …
  }
  
  should be written as:
  
  class MyClass
  {
     …
  }
  
  and
  
  if (x == y)
  {
     …
  }

It takes time for developers to get into this habit if they already are not following this. But with IDEs like Visual Studio helping developers with auto indentation and spacing, it is not very difficult for developers now. So, no excuses! ;-)