Programming Practices

Coding Standards and good writing practices.

Coding Standards and good writing practices.

Why do most programmers pay attention of quality the written code?

You probably know why, but I will repeat it anyway… In the large projects, you have to stick to the rules of code penning because  allowing programers write negligently code cause terrible mess in the project. There will be no time for any corrections, analyzing and expanding projects will consume much more time.

Before I started working in my first job, I thought that, I write a clear and good code but after few days at work I learned, how wrong I was. Thanks to Code Review in my work and Robert C. Martin’s book’s “The Clean Code: A Code of Conduct for Professional Programmers” I could find out what mistakes I made earlier. Now I decided to share my knowledge with you.

 

Of course, code writing conventions are slightly different in some companies, but the general rules are very similar.

Naming convention

1. Pascal Case & camel Case

Pascal Case and camel Case is the naming convention. Pascal Case is a subset of camel Case where the first letter is capitalized.

camel Case:
  • camelCaseExample

We use for: 

  • local variables
  • function parameters
  • non-public fields
Pascal Case:
  • PascalCaseExample

We use for: 

  • Class
  • Functions
  • Const
  • Property
  • Others not mentioned previously
2. Write in English

If you are not english native like me, remember that the names of variables, methods, classes ect. should be written in English.

3. Interface names always start with “I”
4. Two-letter shortcuts write in uppercase (small for field), more than two-character write in PascalCase
  • IOServer
  • ioServer 
  • CommonWsbFiles  
5. Use and write namespaces.

The namespace system should reflect the directory layout up to the third level of nesting.

Formatting

6. Tab settings – default for Visual Studio.
7. Avoid too long lines of code.
8. The braces including the code blocks are always set in a new line, i.e. 

  I don’t like java-like code writting.  

9. Each “if” contains braces {} in a new line.
10. Implementation segregation
  1. Events and delegates
  2. Properties
  3. Fields
  4. Constructors and destructors
  5. Methods
  6. Nested Enums, Structs, and Classes.

    Within these groups, order by modifiers:
    1. public
    2. protected
    3. internal
    4. private
11. Avoid using #region. It is used to hide the badly written code.
12. Calling a method with a large number of parameters  is hard to read. If You have to call a method with large number of parameters try keep one parameter per line.
13. Brackets for combining Boolean expressions should look like this:
//Not Ok

if (a<b && c>d)
{
//do something
}

//Ok
if ((a<b) && (c>d))
{
//do something
}

Implementation

14. Avoid creating excessive amounts of DLLs for non-shared code.
15. There is one class or interface per one .cs file. It is allowed to create small auxiliary classes or structures in the same file, but they must be clearly marked (#region, comments)
16.Accessors should not be avoided, when you are defining classes and their elements, i.e:
public class Horse 
{
int age; // BŁĄD, domyślny akcesor private
private string name; // OK, zdefiniowany akcesor
}
17. Use the internal modifier where public is not necessary.
18. Use var only when we explicitly know what type will be.q
Ok var text=GESHI_QUOTsome textGESHI_QUOT; Not Ok var someValue=foo.CreateValue();
19. Always check that the delegate is not null (eg throwing an event).
var handler = SomeEvent;
if(handler != null)
{
handler(this,EventArgs.Empty);
}
20. Avoid using fixed inline (magic numbers) constants. It is better to use const or enum.
21. Avoid explicit projection. Instead, use the “as” conversion operator and check that the returned value is not null.
object dataObject = LoadData(); 
DataSet ds = dataObject as DataSet;
if(ds != null)
{
}
22. Automatically generated property is much better than property with backing field when there is no logic for getter and setter.
lass Class
{
   //Good
   public int Prop1{get;set;}
 
   //Bad
   public int Prop2
   {
      get{return prop2;}
      seT{prop2 = value;}
   }
 
   int prop2;
}
 
23. Use the readonly attribute for class fields initialized only in the constructor.
24. Remove unused function and code snippets.

Comments

25. There is no obligation to comment on the code inside the function.

..but unintuitively class, fields should have documentation in XML.

26. Use // or /// but avoid / * … * / where possible.
27. Do not embellish your comments. It looks stupid  😛
 // ***************************************
 //  -> Ridiculous comment block <-
 // ***************************************
// ______________________________________

Exceptions

28. Never write an empty catch block. At least Log use is required
29. Avoid nesting a try…catch block inside another catch block.

Recommended literature

2 thoughts on “Coding Standards and good writing practices.

  1. I juѕt couldn’t leave your web site Ьefore suggesting that
    І really enjoyed the uѕual information a person supply in your ᴠisіtors?
    Is going to Ƅe back steadily to cheсk out new posts

Leave a Reply

Your email address will not be published. Required fields are marked *