Friday, 2 February 2018

Programming Standards

 Standards are agreed habits or rules or guidelines that a programmer should follow when coding. These can be either global and larger scale agreed standards or smaller "in- house" rules that the programmer would be expected to follow.

 Some examples of programming standards include:

 White spacing: This can also be known as "indenting", indentation doesn't benefit the computer or any device, it is a nice,etiquette to do so that if you share your code or work in a team the other colleagues will be able to easily understand and read the code without any issues or without it taking too long.  However if you are solo coding the programmers are probably less likely to use white spacing as it takes slightly longer and it's a little thing, they have a lot more to concentrate on so they  will probably not worry too much about the code looking neat.

Naming conventions:   This is where the certain variables or characters etc the programmer will name in a professional manner, these will  be  pre-agreed  name(s) agreed by the developers or the manager of the team which means when the developers share code or brainstorm ideas the different variables will be instantly visible and identifiable to every developer or member of the team. This can also be done by solo or smaller teams though it might be less likely as a solo programmer might not care for as many standards as a large scale team.
     This is a screenshot of my code where I was using my currency converter, this is where I told the computer what the comboBox1.Text is and I defined it as a variable(it is a string, as it is the name of the currency. I then told the computer what the GBP is and by using Parse you can enter numbers into the text box without the code breaking as it doesn't recognise the code. However the name of the combobox is not very unique so to improve I could rename the combobox to make it more identifiable when scrolling through the code so if there is an error you can identify it very easily and correct it.
I named it that as I feel I can identify the variable easily, however in a team the variable should be named better and following the companies convention (e.g. Currency-selector), so it sounds more professional and ensures fellow colleagues can identify the variable faster and reduces the errors made in the code.


However above is a bad example of where in my email validator I didn't follow any naming conventions or was even remotely professional I named it checkemail and included a few random letters after this doesn't make it very fast to access or easy if I ever had to share with fellow peers as I would have to explain that checkemailftw is a text-box where the code checks if the email is valid or not. To improve I should set myself some standards for which I should follow when coding.


Position of brackets
 This is an interesting convention, this is the issue as some companies or programmers will prefer putting brackets at the end and start of each function and variable etc on the same sentence. However some people will prefer indenting or moving the brackets until the brackets are directly below each other so when you click or select one the other bracket will also be highlighted and the section will be highlighted.  This method could be very useful when programming in a certain language or programming certain things(e.g. a web-page). This will make it easier for a team as by simply clicking a bracket, the different developers will be able to easily see the section in it and thus sort any errors should any arise.



Hungarian Notation  
This is a identifying system invented by Dr Charles Simonyi, he was Microsoft's chief architect so the system was first only really used in the Microsoft system but a while. This system is where the developer but an identifying prefix before the variable(e.g. i before a integer to show quickly if they are scrolling through the code what the function is). As time has passed and the system has been adopted by more companies they each may alter it by a small amount to better suit their purpose and improve the efficiency of the system for their developers etc.  There are 4 things  developers should consider when coding:
1. Mnemonic value or name, this is when the programmer uses a name they will remember easily when later reviewing the coding.
2. Suggestive, it has to imply what the name means to others that may wish to view the code, an example of this is when you might put a prefix in front of it, this might be  gi_power, this would let others know that this is a global integer that can be used by any function in the program, this makes it easier to locate and fix any errors faster if they involve this variable.
3. Consistency, similar variables should have similar names for the sake of consistency.
4.Speed of the naming process, the programmer can not spend too long deciding at what the name for the variable should be so they must choose a sensible name quickly.

In terms of using prefixes before variables, I personally don't think using prefixes in the programs I will make will my code any better, I will use the other things like whitespacing and sensibly naming variables to make more code more readable and easier to modify or fix should an issue arise.  However in Microsoft if it is standard to use prefixes to ensure variables can be identified by everyone and everyone knows its use and errors can be found and fixed quickly which is essential for a large corporation such as Microsoft, which I agree with. When working in a large company or even a small team, it is important to agree on standards and this help ensure you all can read and understand your colleagues code and you know what variables are involved in what(e.g.   if it is a global or local variable).  It is important you agree on these standards and programming style if you have to share your code across a long distance as you would not be able to stand next to them and explain your code and the different standards and styles you have used. Errors in understanding other colleagues code can be disastrous depending on what industry it is in, e.g. in the aviation industry. In certain IDE's there are inbuilt bug detectors such as zero in C++ this ensures there are no errors in the code, as it will make easier and more efficient for the developers as you don''t have to constantly check for errors in yours or others code.