Coding Standard - xeeshad/E-commerce GitHub Wiki

Coding Guidelines This document contains the coding guidelines for the Mono Project. It contains four major sections: • Style guidelines on how to organize your source code. • Git workflow changes discusses how our workflow has changed now that Mono is hosted on GitHub. • Source code control details our source code control use. • Best practices used in the project.

Style Guidelines In order to keep the code consistent, we use the following conventions. From here on ‘good’ and `bad’ are used to attribute things that would make the coding style match, or not match. Indentation Use tabs (and configure IDE to show a size of 4 spaces for them) for writing your code (hopefully we can keep this consistent). If you are modifying someone else’s code, try to keep the coding style similar.

for (i = 0; i < 10; i++) if (something (i)) { do_more (); } } Switch statements have the case at the same indentation as the switch: switch (x) { case 'a': ... case 'b': ... } Performance and Readability It is more important to be correct than to be fast. It is more important to be maintainable than to be fast. Fast code that is difficult to maintain is likely going to be looked down upon. Where to put spaces# Use a space before an opening parenthesis when calling functions, or indexing, like this: method (a); b [10]; Good: method (a); ……… [10];

Bad: method ( a ); ………[ 10 ]; If we use if statement and it wil be Good: if (dingus) { ... } else { ... } Bad: if (dingus) { ... } else { ... } Multiline Parameters When you need to write down parameters in multiple lines, indent the parameters to be below the previous line parameters, like this Good: WriteLine (format, foo, bar, baz); If you do not want to have parameters in the same line as

WriteLine ( format, moved, too, long); OR

WriteLine (foo , bar , baz);

Multiline comments /*

  • North
  • South
  • University */ Casing# Argument names should use the camel casing for identifiers, like this: good: void Method (string myArgument) bad: void Method (string lpstrArgument void Method (string my_string)

Line length and alignment For best results use the same number of tabs used on the first line followed by enough spaces to align the arguments. That ensures that the arguments will remain aligned when viewed with a different tabsize. In the following example, the line that declares argc is indented with 2 tabs and 15 spaces: namespace N { class X { void Function (int arg, string argb, int argc) { } } }

Initializing Instances Good: var x = new Foo () { Label = "This", Color = Color.Red }; Bad: var x = new Foo (); x.Label = "This"; x.Color = Color.Red; Git Workflow Changes One Line Summaries Before full the commit message, we will use a one-line summary of the change as this improves the output of GitHub’s rendering of changes done to the project. No more manual ChangeLog editing We no longer maintain ChangeLog files by hand. You still must create a commit message that contains a 1-line summary Remember, this is used by maintainers over the course of the project. Mono is almost 10 years old now, so we need this information for future maintainers to look at.

Source Code Control Summary Description Include a one-line summary description at the top of your commit message to improve the rendering of the commit history on GitHub. After the one-line summary description, you should continue to add the detailed description of your change to the commit message, detailing what the change does. We will add more tags as time goes by. The commit message is mainly for the other people, so they should be able to understand it now and six months later. First line (the brief description) must only be one sentence and should start with a capital letter You can prefix the first line with one tag, to make it easier to know to which part of the module the commit applies Best Practices Correctness is essential . Because our code is called by many other people, we often must be more pendantic than most people would be when writing code The class libraries are grouped together in the assemblies they belong. Documentation As you write new features, user visible or developer visible consider that the feature will be invisible to users unless it is documented. If you write new features and there is no accompanying documentation, the feature is for all purposes bloat as only a handful of developers will know about it, but everyone will pay the price by carrying this undocumented code with them.

Tests When fixing a bug, write a test, so we can make sure that we do not re-introduce bugs in the future accidentally. When writing new code, write tests to exercise the API. Write tests when you are exploring an API on Windows, you will have to write test cases anyways to understand how the API works. Check all arguments Public functions must check their arguments. It is important to throw exceptions such as ArgumentNullException rather than NullReferenceException. Locking and Threading As humans, we are trained to think about one thing at a time. We, by nature, are not multi-taskers. Thus, when we write code, we tend to think about it as if it was the only thing happening on the operating system. Sadly, this is not the case. In Mono, we are providing a base framework for others to use. This means that our code can often be called from multiple threads. Our code might be running on 8 cpu server with hyperthreading.