# Programming Style Guide: Command Query Separation

An important aspect of programming, and one that people don’t think of to often, is being able to express the intentions of the code clearly.

Most of the times we programmers get lost in the code we write. It is important to step back and take a look at the code we have written from another person’s perspective. One can say, “But that’s what documentation is supposed to do right? Provide information to others!”. Yes, but that’s not the only way. A good example of that is a situation we often face with functions.

### Command Query Separation

Most functions can be generalised into 2 categories.

#### Command Functions

Functions that act on instructions sent to it and make changes to the underlying data/model. These are commands given to a function and the callee is not expecting a response.

#### Query Functions

Functions that are used as queries to examine the underlying data/model. The callee is most certainly expecting a response. The function should not modify the underlying model in any way.

It is not common to find a function that does both. In fact, to be consistent command functions must never return a response and a query function must only return a response. This is how ideal separation happens. This way programmers can easily distinguish between Commands & Queries and the objective of the function becomes clear.

The real world however is quite different. Most functions we write are not guaranteed to work the way we want. The likelyhood of an error occurring while a function is being run is very high. This can happen during data validation or some underlying process. Hence, most functions are very likely to return a response indicating the success of a function. This is done using a variety of techniques. It is this feature that throws Command Query Separation for a toss.

In this article we are going to look at some ways in which we can achieve Command Query Separation while still retaining error handling capabilities.

Let us start by looking at the example written below.

```//Division function
/*
Argument 1: Holds the numerator of type double
Argument 2: Holds the denominator of type double
Returns: Value of type double. The result of the division is returned. If the denominator is 0 the function returns 0
*/
double division(const double &firstNumber, const double &secondNumber)
{
if (!floating_point_equality(firstNumber, secondNumber))
{
return firstNumber / secondNumber;
}
return 0.0;
}
```

The function is a rather simple implementation of division written in C++. It is meant to be a Query function. It immediately becomes clear that we are trying to do 2 things here:

• We are trying to perform a division
• We are trying to check if the division succeeded with the help of a return value

The problem is the fact that the function returns error codes and the result the same way. Any programmer using this function will have to write the code to distinguish between the two.

In this case the error is represented by the value ‘0’. There is no way for the caller to tell if the result of the division was 0 or if there was an error. It gets even worse if the function is a pure command function. A pure command function ideally should not return anything. However we will have to return a value to account for errors.

Here is an example of a Command Function:

```//Division function
/*
Argument 1: Holds the numerator of type double
Argument 2: Holds the denominator of type double
Returns: An error code in the form of an integer. A '0' indicates success. '-1' indicates division by Zero error.
*/
int display_division_of_numbers(const double &amp;firstNumber, const double &amp;secondNumber)
{
if (!floating_point_equality(secondNumber, ZERO))
{
std::cout&lt;&lt;firstNumber&lt;&lt;&quot; divided by &quot;&lt;&lt;secondNumber&lt;&lt;&quot; = &quot;&lt;&lt;(firstNumber / secondNumber)&lt;<span id="mce_SELREST_start" style="overflow:hidden;line-height:0;"></span>&lt;std::endl;
return 0;
}
else
{
return -1;
}
}```

As we can see the function is a command function. It shouldn't be returning a value. But we are forced to return a value to communicate success.

Let us look at some alternatives.

#### Returning Error Codes

This approach is the one that was implemented above & has the obvious short comings.

#### Passing An Error Code variable

This is the next best approach. Instead of returning an error code pass in an object that represents error. After the call is completed, check to see if the error object is nil/NULL. This ensures that the return value always corresponds to an answer and nothing else.

```//Potential Error Codes

typedef enum ErrorCodes
{
DIVIDE_BY_ZERO, NaN, NEGATIVE_NUMBER
} ErrorCodes;

//ErrorCode struct. This is the object that contains error information
typedef struct ErrorCode
{
public:
ErrorCode(const ErrorCodes &code, const std::string &description)
:errCode(code), errDescription(description)
{

}

std::string description() const
{
return errDescription;
}

private:
//Holds the code
ErrorCodes errCode;

std::string errDescription;
} ErrorCode;

//Division function
/*
Argument 1: Holds the numerator of type double
Argument 2: Holds the denominator of type double
Argument 3: Holds a pointer to the error code object. If the object is nil then there was no error.
Returns: Value of type double. The result of the division is returned.
*/

double division_of_numbers(const double &firstNumber, const double &secondNumber, ErrorCode **error)
{
if (!floating_point_equality(secondNumber, ZERO))
{
return firstNumber / secondNumber;
}
else
{
*error = new ErrorCode(DIVIDE_BY_ZERO, "Attempting to divide by zero");
}
return 0.0;
}```

As is obvious from the code above, the return value always corresponds to the answer of the computation. All we have to do is check the ErrorCode pointer to see if it is NULL.

Here is the implementation for the Command Function.

//Division function
/*
Argument 1: Holds the numerator of type double
Argument 2: Holds the denominator of type double
Argument 3: Holds a pointer to the error code object. If the object is nil then there was no error.
*/
void display_division_of_numbers(const double &firstNumber, const double &secondNumber, ErrorCode **err = NULL)
{
if (!floating_point_equality(secondNumber, ZERO))
{
std::cout<<firstNumber<<" divided by "<<secondNumber<<" = "<<(firstNumber / secondNumber)<<std::endl;
}
else
{
*err = new ErrorCode(DIVIDE_BY_ZERO, "Attempting to divide by Zero.");
}
}

As you can see the function looks like a true Command Function. There is no value being returned. However, the caller still has to check if the Error object is NULL.

Another implementation of this is to use a complex response.

```//Potential Error Codes
typedef enum ErrorCodes
{
DIVIDE_BY_ZERO, NaN, NEGATIVE_NUMBER, NO_ERROR
} ErrorCodes;

//Response struct. It will hold either the error or a response.
typedef struct Response
{
public:
Response(ErrorCodes err)
: errCode(err), value(0.0)
{

}

{

}

ErrorCodes getError() const
{
return errCode;
}

double getValue() const
{
if (NO_ERROR == errCode)
{
return value;
}
return 0.0;
}

private:
ErrorCodes errCode;
double value;
} Response;

//Division function
/*
Argument 1: Holds the numerator of type double
Argument 2: Holds the denominator of type double
Returns: A struct of type Response that either contains the value or the error. The caller must examine the struct before probing the value.
*/
Response* division_of_numbers(const double &firstNumber, const double &secondNumber)
{
if (!floating_point_equality(secondNumber, ZERO))
{
}
else
{
Response *error = new Response(DIVIDE_BY_ZERO);
return error;
}
}
```

This approach is a combination of the first 2 approaches. It immediately sends information to the caller that he/she must examine the object for errors before probing for the value. In the earlier example, there is no guarantee that the caller will examine the error. There is no guarantee with this approach either. But at least it simplifies the implementation for the caller and provides an easier mechanism to handle errors without having to manually create error objects.

Something similar is achieved in Swift using Associated Enums.

```
//Response Enum. It will hold either the error or a response.

enum Response
{
case Error(String)
case Value(Double)
}

//Division function
/*
Argument 1: Holds the numerator of type double
Argument 2: Holds the denominator of type double
Returns: An Enum Response that either contains the value or the error. The caller must examine the struct before probing the value.
*/

func division_of_numbers(firstNumber : Double, by secondNumber : Double) -> Response
{
if (!floating_point_equality(firstNumber : secondNumber, Equals: ZERO))
{
let answer : Response = Response.Value(firstNumber/secondNumber)
}
else
{
let error : Response = Response.Error("Dividing by Zero")
return error;
}
}```

Of course the Swift implementation does not need a struct as enums allow us to encapsulate a value in them.

#### Exceptions & Exception Handling

This is a much better approach. The idea is that you write you function to work as it is normally supposed to. If something goes wrong throw an exception. This approach completely eliminates the need to examine the return value or check to see if there are errors in the response object.

In exception based programming, your code will follow the correct path if there is no problem. If an issue occurs then your code jumps to the part where the error needs to be handled.

Here is an example:

```#ifndef MathException_hpp
#define MathException_hpp

#include
#include
#include

namespace MathematicalExceptions {
class MathException : public std::exception
{
public:
virtual const char * what() const throw ();
MathException(const std::string &information);

private:
std::string description;
};
}
#endif /* MathException_hpp */```

The next file:

```#include "MathException.hpp"

const char * MathematicalExceptions::MathException::what() const throw ()
{
return description.c_str();
}

MathematicalExceptions::MathException::MathException(const std::string &information)
: description(information)
{

}
```

the next file.

```#include <span id="mce_SELREST_start" style="overflow:hidden;line-height:0;"></span>
#include
#include "MathException.hpp"

const double ZERO = 0.0;

//Floating point equality checker
/*
Argument 1: Holds the LHS value of type double
Argument 2: Holds the RHS value of type double
Returns: Boolean value
*/
bool floating_point_equality(const double &amp;firstNumber, const double &amp;secondNumber)
{
return fabs(firstNumber - secondNumber) &lt; std::numeric_limits::epsilon();
}

//Division function
/*
Argument 1: Holds the numerator of type double
Argument 2: Holds the denominator of type double
Returns: A struct of type Response that contains the value.
This function throws an exception of type MathematicalExceptions::MathException
*/
double division_of_numbers(const double &amp;firstNumber, const double &amp;secondNumber)
{
if (!floating_point_equality(secondNumber, ZERO))
{
double answer = firstNumber / secondNumber;
}
else
{
MathematicalExpections::MathException exception = MathematicalExceptions::MathException(&quot;Attempting to divide by zero&quot;);
throw exception;
}
}

int main(int argc, const char * argv[]) {
double numerator = 32.1;
double denominator = 0.0;

try
{
}
catch (MathematicalExceptions::MathException &amp;err)
{
std::cout&lt;&lt;err.what()&lt;&lt;std::endl;
}
return 0;
}```

Exceptions are about the closest we can come to achieving Command Query Separation. Anyone using functions that implement the Exception throwing and handling capability is clear as to whether it is a Command function or a query function without compromising on safety and error handling in any way.

Here is an example with Swift.

```//Exception Enum. Will be used to throw an exception for mathematical operations
enum MathExceptions : Error
{
case Divide_by_Zero(String)
case NaN(String)
case NegativeNumber(String)
}

//Division function
/*
Argument 1: Holds the numerator of type double
Argument 2: Holds the denominator of type double
Returns: The value of type Double. The caller must handle any exceptions that might be thrown.
*/
func division_of_numbers(firstNumber : Double, by secondNumber : Double) throws -> Double
{
if (!floating_point_equality(firstNumber : secondNumber, Equals: ZERO))
{
let answer : Double = firstNumber / secondNumber
}
else
{
throw MathExceptions.Divide_by_Zero("Attempting to Divide by zero.")
}
}

let ans : Double = 0.0

do
{
ans = try division_of_numbers(firstNumber: 22.3, by: 0.0)
}
catch let err
{
print(err.localizedDescription)
}```

Again, the Swift implementation is rather Straightforward thanks to Associated Enums which conform to the Error protocol.

Here is how the Command function would look with exceptions.

```//Division function
/*
Argument 1: Holds the numerator of type double
Argument 2: Holds the denominator of type double
*/
void display_division_of_numbers(const double &amp;firstNumber, const double &amp;secondNumber)
{
if (!floating_point_equality(secondNumber, ZERO))
{
std::cout&lt;&lt;firstNumber&lt;&lt;&quot; divided by &quot;&lt;&lt;secondNumber&lt;&lt;&quot; = &quot;&lt;&lt;(firstNumber / secondNumber)&lt;<span id="mce_SELREST_start" style="overflow:hidden;line-height:0;">&#65279;</span>&lt;std::endl;
}
else
{
MathematicalExceptions::MathException exception = MathematicalExpections::MathException(&quot;Attempting to divide by zero&quot;);
throw exception;
}
}```

This produces a much better implementation of the function, while maintaining the error handling capabilities.

### Conclusion

As we can see implementing perfect Command Query Separation is not easy. But by writing our functions properly and by using better error handling such as exceptions it becomes a lot easier to achieve that. Programmers should be able to look at a function & tell if it is a ‘Command’ or a ‘Query’ knowing that error handling is not part of the function signature in any way.

# Programming Style Guide: Documentation

Now we will shift our attention to that part of programming which is often ignored. Documentation.

Documentation is a key part of programming. In fact, some might go as far as saying that Documentation is the most important aspect of Programming. Let us understand what we mean by documentation by looking at some key points. Later we will look at different ways of documenting our code.

We document our code so that:

1. Anyone who is reading our code can understand what we are trying to achieve.
2. Anyone who wishes to make changes to our code knows where to make the changes.
3. Anyone who issuing our code can easily find out its capabilities and limitations.
4. Other programmers can figure out how to use our code.
5. Developers can find out when and where changes were made to a code. This is useful to understand the evolution of our code.
6. We can easily recollect what, why, when, where & how something was done by us. This is necessary if we are revisiting code that we have written a long time back.
7. We can add warnings and disclaimers

There may be some other reasons why we may want to document our code, but the list above summaries the most common reasons. This can easily be seen from a simple example.

```func fahr_to_cent(Centigrade temp : Float) -&amp;gt; Float
{
return (32 + (temp * 1.8))
}
```

It is clear to use what the function does simply from its name. However, there is a lot more information that we can provide. Let us modify the implementation a little bit to make it more informative and readable.

```/**
This function takes temperature in Centigrade and converts it to Fahrenheit.
- important: This function does not do data validation
- parameter temp: This is the temperature in Centigrade. It can be a negative value too.
- returns: This is the temperature in Fahrenheit.
- requires: `temp > -273.0 && temp < 1000.0`
- Note: The requirement mentioned is not enforced.
- Since: iOS 11
- author: Arun Patwardhan
- version: 1.0
*/
func convert_to_fahrenheit_from(Centigrade temp : Float) -&amp;gt; Float
{
return ((temp * 9.0 / 5.0) + 32.0)
}
```

The code above looks a lot better now. We made the function name better, but more importantly we have added documentation that better describes the function. This includes range of permitted values, version number, important notes. The comments haven’t been written randomly. They have been formatted in a way that will make them appear in quick help. So now if we have to use the function we know what to watch out for.

Now that we know why we need to document our code let us look at some of the ways this can be done.

The most common form of documentation is by using comments. Most programming languages support comments. Comments are text which is ignored by the compiler. As such they are not used to build the actual software. The sole reason why they exist is because there has to be some mechanism to write notes.

```// This is a comment
```

A single line comment as the name says is a piece of text that can fit in one line.

Good when a short description is required. Normally this is placed before or after a variable as most variables would need a short description.

You can have multiple lines using the Single comment mechanism too.

```// This is a comment
// This is a comment on the next line
```

There is a better way to implement multi line comments. We can enclose the text in a /* */ range.

```/* This is a comment
This is a comment on the next line
Useful when we have to write really large pieces of comments&amp;amp;amp;lt;span 				data-mce-type="bookmark" 				id="mce_SELREST_start" 				data-mce-style="overflow:hidden;line-height:0" 				style="overflow:hidden;line-height:0" 			&amp;amp;amp;gt;&amp;amp;amp;lt;/span&amp;amp;amp;gt;
*/
```

#### Use Case

Here are some examples of when comments can or should be used.

```/*
File Name.   : main.cpp
Date Created : 13th February 2017
Created By   : Arun Patwardhan
Project Name : String Parser
File Contents:
- Command Line Option selector
- Different entry points for the remaining code
Contact      : arun@amaranthine.co.in
*/
```

This is a classic example of a multi line comment. This comment provides useful information about the name of the file, when it was created, who created it, contact information, the code that is found in this file.

```/*
Exception Possibilities while Reading/Writing from/to Database
write_error : This is thrown when there is duplicate data that is being
written into the database.
db_empty.   : This is thrown when you attempt to read from an empty data
base.
Use the func is_empty() method.
invalid_data: This is thrown when the data to be written is not valid.
data_missing: This is thrown when insufficient data is passed. If the write
operation requires mandatory data an exception is thrown
*/
enum DBExceptions : Error
{
case write_error(String)
case db_empty(String)
case invalid_data(String)
case data_missing(String)
}
```

This example shows the necessary documentation while declaring a new type. In short its purpose and situations when different values might be used.

Here is an example of code for functions.

```@interface Converter : NSObject
/*!
@brief This is a temperature conversion function

@discussion This functions takes floating point values and does a floating point conversion to make sure that we get a precise conversion.

@param temperature This is the value in centigrade that is passed in. Note, negative values can also be passed in. Values whose results exceed the range supported by float will produce un predictable results.

@return float Returns a floating point value
*/
@end
```

The comment gives information about different aspects of the function. Including the rage of values supported. Note that it also uses special markup to allow for the code description to show up in the Help menu bar or when you option click the method. This is how the comments with markup look like. They appear in the ⌥ click menu as well as the help menu on the right hand side.

Another thing one can do along with comments is to create Read Me files. Read Me files are plain text files that are bundled as a part of the project. Unlike comments which give information about a specific piece of code or an entire file, Read Me files give information about the entire project as a whole. Since they are text files we actually treat them as text.

Here is some typical information that is found in a Read Me file:

Project Name : String Parser
Project Request/Ticket Code: 13788
Orignal Project Author : Arun Patwardhan
Contact Details :
– arun@amaranthine.co.in
http://www.amaranthine.in

Platforms on which Application Can Run
– macOS 10.10 or later
– Windows 7 or later
– Linux (Ubuntu 14 or later)

Compiler Supported – g++

Building the Application

```make
```

Testing

```strParser -f Test1 -o myOutput1
strParser -f Test2 -o myOutput2
```

Files
– makefile
This is the file used to build the Application.

– main.cpp
This is the entry point file. The selection of execution path on the basis of command line options is done here.

– Parser.h
This file contains the declaration for the Parser class as well as its internal structure.

– Parser.cpp
This file contains the implementation of the Parser class

– DataStructure.h
This file contains the declaration of the internal structure of the data structure.

– DataStructure.cpp
This file contains the implementation of the internal structure of the data structure.

– Validator.h
This file contains the declaration of the internal structure of the data structure.

– Validator.cpp
This file contains the implementation of the internal structure of the data structure.

– Test1
Runs a basic set of strings as input.

– Output1
Expected output after running Test1. Compare your results with the results of this file.

Libraries Required – Standard Template Library

The above is just a sample Read Me file. In real world implementations these can get a lot bigger with references to links and future developments. Some of the other things that can be mentioned are:

• Bugs fixed (potentially with the bug fix request ticket)
• Limitations
• Tools that are required to make this code
• Additional tools that need to be installed
• Project Status

## Naming Conventions

Documentation becomes a lot easier if we follow good naming conventions. Variables, functions, types, files… which are well named in itself become self explanatory and at the very least reduce the amount of documentation required.

## Additional Tools Documentation in C++, Objective-C

Doxygen

HeaderDocretired You may come across some projects that use this.

## Additional References for Documentation for Swift

Here is an article on Markups for Swift.

# Programming Style Guide: Code Refactoring

One of the key attributes towards code that is readable and easy on the eyes is code that is split into appropriately sized pieces. Code refactoring is does exactly that. It is very easy to write a program as one big piece of code. Of course, any program that grows becomes increasingly complicated and highly inefficient. If not controlled, it will soon reach a point where it is highly unreadable, extremely difficult to maintain & filled with bugs. Not to mention that it is inefficient too.

Refactoring code and breaking it down into smaller reusable chunks is the key. The objective is:

1. To make code easier to read
2. To make reusable components so that we can save on duplication of code. This will reduce the code count and make sure that any changes to the reused code are available everywhere.
3. To lend a structure to the application. Tasks now have their own space.
4. Build scalable and maintainable code.
5. Build bug free code.

Let us look at an example. This code is clearly written poorly. Its difficult to read. There aren’t good whitespaces. No consistency. Even the naming conventions are poor.

The fix would be :

• Break it down into different functions
• Separate tasks into their own files
• Name the different elements of the code properly.

This is how the code looks now. It has been broken down into different files.

main.cpp

```#include <iostream>
#include "MathOperations.hpp"
#include "Choices.hpp"

int main(int argc, const char * argv[])
{
float number1           = 0.0;
float number2           = 0.0;
Choices selectedOption  = CLEAR;

while(EXIT != selectedOption)
{
//Welcome message
std::cout<<"Welcome to Calculator Program"<<std::endl;
std::cout<<"Choose between the following options"<<std::endl;
std::cout<<"1. Add\n2. Subtract\n3. Multiply\n4. Divide\n5. Remainder\n6. Percentage"<<std::endl;

//User choice
std::cout<<"Choice: ";                               std::cin>>selectedOption;

//Chance to enter first number
std::cout<<"Number 1: ";                               std::cin>>number1;

//Chance to enter second number
std::cout<<"Number 2: ";                               std::cin>>number2;

switch (selectedOption)
{
break;
case SUBTRACTION:
std::cout<<"The subtraction of "<<number1<<" & "<<number2<<" = "<<answer<<std::endl;
break;
case MULTIPLICATION:
std::cout<<"The multiplication of "<<number1<<" & "<<number2<<" = "<<answer<<std::endl;
break;
case DIVISION:
std::cout<<"The division of "<<number1<<" & "<<number2<<" = "<<answer<<std::endl;
break;
case REMAINDER:
std::cout<<"The remainder of "<<number1<<" divided by "<<number2<<" = "<<integralAnswer<<std::endl;
break;
case PERCENTAGE:
std::cout<<"The percentage of "<<number1<<" out of "<<number2<<" = "<<answer<<span 				data-mce-type="bookmark" 				id="mce_SELREST_start" 				data-mce-style="overflow:hidden;line-height:0" 				style="overflow:hidden;line-height:0" 			></span><std::endl;
break;
default:
break;
}
}
return 0;
}

```

Choices.hpp

```#ifndef Choices_hpp
#define Choices_hpp

#include <stdio.h>
#include <iostream>

enum Choices : unsigned short int { ADDITION = 1, SUBTRACTION, MULTIPLICATION, DIVISION, REMAINDER, PERCENTAGE, CLEAR, EXIT};

typedef enum Choices Choices;

std::istream& operator >>(std::istream &is, Choices& enumVar);

#endif
```

Choices.cpp

```#include "Choices.hpp"

std::istream& operator >>(std::istream &is, Choices& enumVar)
{
unsigned short int intVal;
is>>intVal;
switch (intVal) {
case 1:
break;
case 2:
enumVar = SUBTRACTION;
break;
case 3:
enumVar = MULTIPLICATION;
break;
case 4:
enumVar = DIVISION;
break;
case 5:
enumVar = REMAINDER;
break;
case 6:
enumVar = PERCENTAGE;
break;
default:
enumVar = EXIT;
break;
}
return is;
}
```

MathOperations.hpp

```#ifndef MathOperations_hpp
#define MathOperations_hpp

#include <stdio.h>

//Subtraction
float subtraction(float number1, float number2);

//Multiplication
float multiplication(   float number1, float number2);

//Division
float division(float number1, float number2);

//Remainder
int remainder(int number1, int number2);

//Percentage
float percentage(float number1, float number2);

#endif
```

MathOperations.cpp

```#include "MathOperations.hpp"

{
return number1 + number2;
}

//Subtraction
float subtraction(float number1, float number2)
{
return number1 - number2;
}

//Multiplication
float multiplication(   float number1, float number2)
{
return number2 * number1;
}

//Division
float division(float number1, float number2)
{
if (number2 > 0) {
return number1 / number2;
}
return 0.0;
}

//Remainder
int remainder(int number1, int number2)
{
return number1 % number2;
}

//Percentage
float percentage(float number1, float number2)
{
if (number2 > 0) {
return (number1 / number2) * 100.0;
}
return 0.0;
}
```

Let us look at how this looks for Swift.
main.swift

```import Foundation

var number1 : Float             = 0.0
var number2 : Float             = 0.0
var selectedOption : Choices    = Choices.CLEAR
var answer : Float              = 0.0
var integralAnswer : Int        = 0

func readNumbers(One firstNumber : inout Float, Two secondNumber : inout Float)
{
//Chance to enter first number
print("Number 1: \n")
firstNumber = Choices.inputNumbers()

//Chance to enter second number
print("Number 2: \n")
secondNumber = Choices.inputNumbers()
}

while(Choices.EXIT != selectedOption)
{
//Welcome message
print("Welcome to Calculator Program")
print("Choose between the following options")
print("1. Add\n2. Subtract\n3. Multiply\n4. Divide\n5. Remainder\n6. Percentage")

//User choice
print("Choice: \n")
selectedOption = Choices.inputChoices()
switch (selectedOption)
{
break
case Choices.SUBTRACTION:
answer = subtraction_of(_value: number1, from_value: number2)
print("The subtraction of \(number1) & \(number2) = \(answer)")
break
case Choices.MULTIPLICATION:
answer = multiplication_of(_value: number1, with_value: number2)
print("The multiplication of \(number1) & \(number2) = \(answer)")
break
case Choices.DIVISION:
answer = division_of(_value: number1, by_value: number2)
print("The division of \(number1) & \(number2) = \(answer)")
break
case Choices.REMAINDER:
integralAnswer = remainder_of(_value: Int(exactly:number1)!, <span 				data-mce-type="bookmark" 				id="mce_SELREST_start" 				data-mce-style="overflow:hidden;line-height:0" 				style="overflow:hidden;line-height:0" 			></span>divided_by_value: Int(exactly: number2)!)
print("The remainder of \(number1) divided by \(number2) = \(integralAnswer)")
break
case Choices.PERCENTAGE:
answer = percentage_of(_value: number1, with_respect_to_value: number2)
print("The percentage of \(number1) out of \(number2) = \(answer)")
break
default:
selectedOption = .EXIT
break
}
}
```

Choices.swift

```import Foundation

enum Choices { case ADDITION, SUBTRACTION, MULTIPLICATION, DIVISION, REMAINDER, PERCENTAGE, CLEAR, EXIT}

extension Choices
{
static func inputChoices() -> Choices
{
let ip : String? = readLine()
let choice : String = String(ip!)

switch choice {
case "1":
case "2":
return .SUBTRACTION
case "3":
return .MULTIPLICATION
case "4":
return .DIVISION
case "5":
return .REMAINDER
case "6":
return .PERCENTAGE
default:
return .EXIT
}
}

static func inputNumbers() -> Float
{
let ip : String? = readLine()

let numberFormatter = NumberFormatter()
let number = numberFormatter.number(from: ip!)

let num : Float? = number?.floatValue
return num!
}
}
```

MathOperations.swift

```import Foundation

func addition_of(_value number1 : Float, with_value number2 : Float) -> Float
{
return number1 + number2;
}

//Subtraction
func subtraction_of(_value number2 : Float, from_value number1 : Float) -> Float
{
return number1 - number2;
}

//Multiplication
func multiplication_of(_value number1 : Float, with_value number2 : Float) -> Float
{
return number2 * number1;
}

//Division
func division_of(_value number1 : Float, by_value number2 : Float) -> Float
{
if (number2 > 0) {
return number1 / number2;
}
return 0.0;
}

//Remainder
func remainder_of(_value number1 : Int, divided_by_value number2 : Int) -> Int
{
return number1 % number2;
}

//Percentage
func percentage_of(_value number1 : Float, with_respect_to_value number2 : Float) -> Float
{
if (number2 > 0) {
return (number1 / number2) * 100.0;
}
return 0.0;
}
```

## Discussion on Swift Extensions

As we can see that most of the code in Swift is very similar to C++. Most of the differences are basic syntactic differences. However, there is 1 feature of Swift that greatly aids code refactoring that I would like to talk about, Extensions.

Extensions allow us to add new functionality to the existing type. As the name says the type is extended. This allows us to add changes to a type in a consistent & clearly demarcated way. Developers can now neatly separate newly added components. This greatly helps in understanding the evolution of types.

#### “This is often referred to as versioning.”

Extensions can be used in the following ways to implement code refactoring:

• Different sections of a type reside in their own extensions
• Changes made to a type are made by keeping them in their own extensions
• Step by step build up of code is done by representing each step as an independent extension. This gives clarity on how a certain end result was achieved.

## Conclusion

As we can see from the sample code above (for both C++ & Swift) the program is much more readable. Code is carefully compartmentalised. Its a lot easier to read. It is a lot easier to scale too.

The reader may point out that the amount of code to achieve the same result is significantly higher, that however is a small price to pay in the long run. The biggest advantage is the scalability & the ease with which it can be done. Simply breaking code down into separate files & functions makes a huge difference. Here are some other benefits:

• Individual files can be modified. This means one can now have a team working on different parts of the code.
• Code is less cluttered. Changes are now spread across files & are easier to track.

# Programming Style Guide – The Need for programming standards

Programming Style Guide refers to the conventions followed while writing programs. This guide is going to be a series of blogs highlighting different programming standards. The series will try to cover as many standards as possible, focus will be on common and popular standards.

But why the need for programming standards? Standards help software developers design software in such a way that it is easy to read, understand, maintain & expand. It provides a consistent experience & also speeds up the way in which software development is done.

A program written with the best standards kept in mind is self explanatory, easy to read, can be built on, & is a stable piece of software

This specific article will act as a Content list for all the articles written as a part of this series. The examples are from the Swift & C++ programming languages.

# Programming Style Guide: Naming Conventions

Today we are going to look at Naming conventions you can follow while writing code.

Naming conventions lay down the basic rules for naming different elements in your code. The objectives are simple:

• Make the element easy to read
• Should be self explanatory
• Should contain information in a compact and concise manner.

Ideally a well named variable or function should not need a comment to explain what it is for.

With the above objectives in mind let us look at some of the naming conventions that can be followed. The examples are from the Swift & C++ programming languages.

### Naming Conventions

#### Camel Case Names

In camel case naming convention the entire name of the element is constructed by forming a sentence joined into a single word. So for example if we have a variable for keeping track of the price of oil in US dollars then the variable name might be priceOfOilUSD.

Here are some examples of naming conventions with the camel case.

SWIFT

`var priceOfOil : Float = 23.49`

C++

`float priceOfOil = 3.45;`
```class PersonInfo
{

};```

#### Underscore Separated Names

In the underscore separated naming convention the entire name of the element is constructed by forming a sentence joined together with the help of underscores in-between them. So if we take the example of the variable keeping track of the price of oil in US dollars the the variable name might be price_of_oil_usd.

Swift

`var price_of_oil : Float = 45.71`

C++

```float price_of_oil = 99.87;

void print_value_of_pi()
{
//print something
}```

#### Names with type information

A naming convention that is quite popular is the one that mixes the previous 2 naming conventions, with the underscore used to separate the type description in the prefix. So if we take the example of the variable keeping track of the price of oil in US dollars then the variable name might be f_priceOfOil or float_priceOfOil. Either of the design styles work. The prefix is popularly abbreviated and you can create your own rules for abbreviating the type description.

This style is often referred to as the Hungarian notation. The additional information that is provided as a part of the prefix can be:

• Whether the variable is a pointer
• Whether the variable is an object
• The scope of the variable
• Type size
• Whether the data can vary or is a constant

Swift

`var f_priceOfOil : Float = 0.0`

C++

`float f_priceOfOil = 22.3;`
`int *ptr_memmoryBuffer = NULL; //ptr indicates variable is a pointer`

### Naming Rules

There are some rules that are typically followed while designing names for variables and  functions. Like the conventions themselves the rules are not binding but they are very useful an give the added punch that naming conventions provide.

1. Variable names always start in lower case.
2. Type names always start in upper case.
3. The naming conventions is consistently applied through all the projects
4. Names should be kept as small as possible without sacrificing on the description

### Naming Strategies

As far as strategies are concerned there are multiple approaches that one can follow. Here are some potential strategies.

• Follow one naming convention for variables and another convention for functions.
• Let constants be all upper case
• Prefix types with your companies initials.

### Summary

The above illustrate just some of the naming conventions that can be followed. By no means are they comprehensive or complete. Also it is not necessarily true that everyone follows the above naming conventions. You may find that many software development firms have their own unique naming convention. This article should give you an an idea about naming conventions. Feel free to share some naming conventions that you have come across.

# C++ in iOS – 2

Continuing from the previous post. This one will look into a working example for the same. The code used here is pretty trivial. It is organized in the following sets of files. A c++ header file which contains the declaration of a class. A c++ implementation file (.cpp) where the member functions are implemented. An Objective-C++ header file which holds the C wrapper struct & an Objective-C wrapper object. An Objective-C++ implementation file (.mm) which implements the C struct & all the member functions for both the C struct as well as the Objective-C class.

CppStruct.h

```
#include <string>
class MyObject
{
public:
std::string getName();
void setName(std::string tempName);
MyObject();
private:
std::string name;
};
```

CppStruct.cpp

```#include "CppStruct.h"
#include <string>
#include <iostream>

std::string MyObject::getName()
{
return name;
}

void MyObject::setName(std::string tempName)
{
name = tempName;
}

MyObject::MyObject()
{
name = "NIL";
}
```

CppStructWrapper.h

```struct PersonWrapper;

@interface CppStructWrapper : NSObject
{
struct PersonWrapper *obj;
}

-(void) makeAPerson;
-(void) setName:(NSString *) personName;
-(NSString *) getName;
@end

```

CppStructWrapper.mm

```#import "CppStructWrapper.h"
#include "CppStruct.h"
#include <string>

@implementation CppStructWrapper

struct PersonWrapper
{
MyObject *personObj;
std::string getName();

void setName(std::string tempName);
PersonWrapper();
};

std::string PersonWrapper::getName()
{
return personObj->getName();
}

void PersonWrapper::setName(std::string tempName)
{
personObj->setName(tempName);
}

PersonWrapper::PersonWrapper()
{
personObj = new MyObject;
}

-(id) init
{
self = [super init];
if(self)
{
obj = nil;
}
return self;
}

-(void) makeAPerson
{
obj = new PersonWrapper;
}

-(void) setName:(NSString *) personName
{
std::string temp([personName UTF8String]);
obj->setName(temp);
}

-(NSString *) getName
{
NSString *str = [[NSString alloc] initWithUTF8String:obj->getName().c_str()];
return str;
}

@end
```

ViewController.m

```//this code could be anywhere I have put it inside the ViewController.m within the init message.
#import "ViewController.h"
#import "CppStructWrapper.h"

-(id) init
{
self = [super init];
if(self)
{
CppStructWrapper *obj = [[CppStructWrapper alloc] init];
[obj makeAPerson];
[obj setName:@"ABC"];
NSString *str = [obj getName];
NSLog(@"%@",str);
}
return self;
}
```