Writing robust quality code for algorithmic trading software development is just as important as any other mission-critical system due to the financial risk that is involved. Good quality and well-written code reduce the risk of potential bugs in the system that could cause some serious loss of money.
Coding conventions are a set of guidelines for a specific programming language that recommend programming style, practices, and methods for each aspect of a program written in that language.
Below are some of our C# coding standards, naming conventions, and best practices that we use when we create software for our customers. Use these in your own projects and adjust these to your own needs.
use PascaleCasing for class and method names. |
This makes the code consistent with Microsoft's .NET Framework, easy to read for ongoing support and future development.
use camelCasing for method arguments and local variables |
This makes the code consistent with Microsoft's .NET Framework, easy to read for ongoing support and future development.
use Hungarian notation or any other type identification in identifiers
|
Consistent with Microsoft's .NET Framework and Visual Studio IDE makes determining types very easy (via tooltips). In general, you want to avoid type indicators in any identifier.
use SCREAMING CAPITAL letters for read-only variables |
This is plain and simple ugly coding, the same way as if you were sending a text with capital letters.
using Abbreviations. Exceptions: abbreviations commonly used as names, such as Id, Xml, Ftp, Uri |
This makes the code consistent with Microsoft's .NET Framework and prevents inconsistent abbreviations.
use PascalCasing for abbreviations 3 characters or more (2 chars are both uppercase) |
This makes the code consistent with Microsoft's .NET Framework, Caps would grab visually too much attention. easy to read for ongoing support and future development.
use Underscores in identifiers. Exception: you can prefix private static variables with an underscore.
|
This makes code consistent with Microsoft's .NET Framework and makes code more natural to read (without 'slur'). Also avoids underline stress (inability to see underline).
use predefined type names instead of system type names like Int16, Single, UInt64, etc |
This makes the code consistent with Microsoft's .NET Framework, and easy to read for ongoing support and future development.
use implicit type var for local variable declarations. Exception: primitive types (int, string, |
This removes clutter, particularly with complex generic types. Type is easily detected with Visual Studio tooltips. Also, it is consistent with Microsoft's .NET Framework, and easy to read for ongoing support and future development.
use noun or noun phrases to name a class. |
This makes the code consistent with Microsoft's .NET Framework, and easy to read for ongoing support and future development.
organize namespaces with a clearly defined structure |
This makes the code consistent with Microsoft's .NET Framework, Maintains good organization of your codebase.
vertically align the curly brackets. |
Microsoft has a different standard, but developers have overwhelmingly preferred vertically aligned brackets. We have also adopted this style.
declare all member variables at the top of a class, with static variables at the very top. |
This makes the code consistent with Microsoft's .NET Framework and generally accepted practice that prevents the need to hunt for variable declarations.
use singular names for enums. Exception: bit field enums. |
This makes the code consistent with Microsoft's .NET Framework and makes the code more natural to read. Plural flags because enum can hold multiple values (using bitwise 'OR').
Free Algorithmic Trading Course
Why not join our free Algorithmic Trading Course so that you can start to learn how to build your own technical indicators and automated trading robots using Microsoft C# and the cTrader trading platform.
Do Not Carry the C++ Standards into C#
We see many programmers using C++ standards with C#, this is incorrect as they are different programming languages and hold different coding conventions. If you try to make code in one language look like code in another, you're likely to start using idioms from that language and end up speaking C# with a C++ accent.