Design & Implement a GUI based system using a suitable Integrated Development Environment

{`
  Programme title	HND IN COMPUTING
  Unit(s)	UNIT 01 PROGRAMMING
  Assignment title Design & Implement a GUI based system using a suitable Integrated Development Environment
  Pearson Higher Nationals in Computing`}
  

2.1 Define what is meant by a Programming Paradigm. Explain the main characteristics of Procedural, Object oriented and Even-driven paradigms and the relationships among them (P2).

2.2 Analyze the features of an Integrated Development Environment (IDE) and explain how those features help in application development (M2).

2.3 Write small snippets of code as example for the above three programming paradigms using a suitable programming language(s) and critically evaluate their structure and the characteristics (D2).

Ayubo Drive is the transport arm of Ayubo Leisure (Pvt) Ltd, an emerging travel & tour company in Sri Lanka. It owns a fleet of vehicles ranging from cars, SUVs to vans.

The vehicles that it owns are hired or rented with or without a driver. The tariffs are based on the vehicle type. Some of the vehicle types that it operates are, small car, sedan car, SVUs, Jeep (WD), 7-seater van and Commuter van. New vehicle types are to be added in the future.

Vehicle rent hire options are described below.

1. Rent (With or without driver) – For each type of vehicle rates are given per day, per week and per month. Rate for a driver also given per day. Depending on the rent period the total rent amount needs to be calculated. For example: if a vehicle is rented for 10 days with a driver, total amount to be calculated as follows:

Total rent = 1_week_car_rent + 1_day_rent x 3 + 1_day_driver_rent x 10

2. Hire (with driver only) – These are based on packages such as airport drop, airport pickup, 100km per day package, 200km per day package etc. Standard rates are defined for a vehicle type for a package type that is applicable for that type of vehicle. For each package maximum km limit and maximum number of hours are also defined. Extra km rate is also defined which is applicable if they run beyond the allocated km limit for the tour. For day tours if they exceed max hour limit, a waiting charge is applicable for extra hours. Driver overnight rate and vehicle night park rate also defined which is applicable for each night when the vehicle is hired for 2 or more days.

Task 3: Implement basic algorithms in code using an IDE (LO3).

3

3.1 Design suable algorithms for vehicle tariff calculation for rents and hires (P3).

Ideally 3 functions should be developed for this purpose as follows:

Function 1: Rent calculation.

Return the total rent_value when rented_date, return_date, with_driver parameters are sent in. with_driver parameter is set to true or false depending whether the vehicle is rented with or without driver.

Function 2: Day tour - hire calculation.

Calculate total hire_value when start_time, end_time, start_km_reading,

end_km_reading parameters are sent in. Should return base_hire_charge, waiting_charge and extra_km_charge as output paramters.

Function 3: Long tour - hire calculation.

Calculate total hire_value when start_date, end_date, start_km_reading, end_km_reading parameters are sent in. Should return base_hire_charge, overnight_stay_charge and extra_km_charge as output parameters.

3.2 Implement the above algorithms using visual studio IDE (using C#.net) and design the suitable database structure for keeping the tariffs for vehicle types and different packages which must be used for implementing the above functions (M3).

3.3 What is the purpose of using an IDE in application development? Evaluate the use of the Visual Studio IDE for your application development contrasted with not using an IDE. (D3).

Task 4: Determine the debugging process and explain the importance of a coding standard (LO4).

Design and build a complete system for the vehicle reservation and billing for Ayubo drive. This includes the completing the database design started in 3.2 and designing the suitable interfaces for vehicle and package additions and reservation handling and customer billing (P4).

4.1 What is debugging an application? Explain the importance of the debugging facility in Visual studio IDE. Debug your source code by putting few debugging points in your application (P4).

4.2 Implement the above functionalities using the IDE while adopting the coding standards to improve maintainability of the code. Explain the coding standards used in your code in the written report (P5).

4.3 Evaluate how you used the debugging process to develop more secure, robust application with examples (M4).

4.4 Explain the coding standards you have used in your application development. Critically evaluate why a coding standard is necessary in a team as well as for the individual. (D4).

Grading Rubric

Task 1: Define basic algorithms to carry out an operation and outline the process of programming an application (LO1)

Searching on an array/list is to find a given element on the array and return whether it is found or not and return its position if found. Linear search and binary search are two popular searching algorithms on arrays.

1.1 Define what an algorithm is and outline the characteristics of a good algorithm. Develop algorithms for linear search and binary search using Pseudo code

1.1.1 Definition of algorithms

An algorithm is a set of instructions designed to perform a specific task. This can be a simple process, such as multiplying two numbers, or a complex operation, such as playing a compressed video file. Search engines use proprietary algorithms to display the most relevant results from their search index for specific queries.

In computer programming, algorithms are often created as functions. These functions serve as small programs that can be referenced by a larger program. For example, an image viewing application may include a library of functions that each use a custom algorithm to render different image file formats. An image editing program may contain algorithms designed to process image data. Examples of image processing algorithms include cropping, resizing, sharpening, blurring, red-eye reduction, and color enhancement.

In many cases, there are multiple ways to perform a specific operation within a software program. Therefore, programmers usually seek to create the most efficient algorithms possible. By using highly-efficient algorithms, developers can ensure their programs run as fast as possible and use minimal system resources. Of Assignment, not all algorithms are created perfectly the first time. Therefore, developers often improve existing algorithms and include them in future software updates. When you see a new version of a software program that has been "optimized" or has "faster performance," it most means the new version includes more efficient algorithms.

Figure 1 Algorithm

1.1.2 Characters of algorithm

Running Time: A good algorithm should have shortest running time when compared with others.

Space Utilization: Lesser the amount of space an algorithm uses, the better.

Finiteness: An algorithm should terminate infinite number of steps and each step must finish in finite amount of time.

Definiteness (No Ambiguity): Each step of algorithm should be clearly and precisely defined and there should not be any ambiguity.

Inputs: An algorithm must have zero or more but must be finite number of inputs. Example of zero input algorithm. Print the ASCII code of each of the letter in the alphabet of the computer system.

Output: An algorithm must have at-least one desirable outcome, i.e., output.

Effectiveness: An algorithm should be effective. Effective means that each step should be referred as principle and should be executing in finite time.

1.1.3 Linear search

In Linear Search the list is searched sequentially and the position is returned if the key element to be searched is available in the list, otherwise -1 is returned. The search in Linear Search starts at the beginning of an array and move to the end, testing for a match at each item.

All the elements preceding the search element are traversed before the search element is traversed. i.e. if the element to be searched is in position 10, all elements form 1-9 are checked before 10.

Figure 2 linear search

Pseudocode for linear search

Linear search (list, data)

Begin

Found=false

For I=0 to length of list-1

If list [I] =data then

found=TRUE

Break

End if

Next

If found=TRUE then

Print “data found”

Else

Print “data not found”

End if

End

1.1.4 Binary Search

A binary search algorithm is used to find the position of a specific value contained in a sorted array. Working with the principle of divide and conquer, this search algorithm can be quite fast, but the caveat is that the data has to be in a sorted form. It works by starting the search in the middle of the array and working going down the first lower or upper half of the sequence. If the median value is lower than the target value, that means that the search needs to go higher, if not, then it needs to look on the descending portion of the array.

A binary search is also known as a half-interval search or logarithmic search.

A binary search is a quick and efficient method of finding a specific target value from a set of ordered items. By starting in the middle of the sorted list, it can effectively cut the search space in half by determining whether to ascend or descend the list based on the median value compared to the target value.

For example, with a target value of 8 and a search space of 1 through 11:

1. The median/middle value is found and the pointer is set there, which in this case is 6.
2. The target of 8 is compared to 6. Since 6 is smaller than 8, the target must be in the higher half.
3. The pointer is moved to the next value (7) and compared to the target. It is smaller, therefore the pointer moves to the next higher value.
4. The pointer is now on 8. Comparing this to the target, it is an exact match, therefore the target has been found.

Using binary search, the target only had to be compared to three values. Compared to doing a linear search, it would have started from the very first value and moved up, needing to compare the target to eight values. A binary search is only possible with an ordered set of data; if the data is randomly arranged, then a linear search would yield results all the time while a binary search would probably be stuck in an infinite loop.

Figure 3 binary search

Pseudocode for binary search

Function binary_search (sorted list, search data)

Begin

Position = -1

Low=0

High (length of sorted list -1)

While(low<=high) DO

Mid = (low+ high)/2

If (sorted list[mid]=search data)

Position = mid+1

Break

Else if (search data>sorted list[mid])

Low =mid+1

Else

High=mid-1

End if

End do

Return Position

End

Start

List = input list of data

Sdata = input search data

Pos = binary_search (sorted List, Sdata)

If Pos! = -1 Then

Output “Data Found at”, Pos

Else

Output “Data Not Found”

Stop

1.2 Describe the steps involve in the process of writing and executing a program. Take an array of 10 or more elements and dry run the above two algorithms. Show the outputs at the end of each iteration and the final output.

1.2.1 Programming process

1. Problem Definition

This stage is the formal definition of the task. It includes the specification of inputs and outputs processing requirements, system constraints, and error handling methods. This step is very critical for the completion of a satisfactory program. It is impossible to solve a problem by using a computer, without a clear understanding and identification of the problem. Inadequate identification of problem leads to poor performance of the system. The programmer should invest a significant portion of his time in problem identification. If he does not spend enough time at this stage, he may find that his well-written program fails to solve the real problem. This step is the process of becoming familiar with the problem. It starts when the programmer is assigned a task. This step includes the reviewing of the design document that was prepared for the program, as well as any system wide information that would be helpful. The process ends when all the programmer’s questions have been resolved and the requirements of the program are understood.

Example

Step 1(problem)

Sum of two numbers(n1+n2)

2. Design the Program

Programs use algorithms which are like equations that tell the computer what task to perform. The aim of the programmer is to create algorithms that are clear and simple. Algorithms are expressed first in logical hierarchical form known as modularization. Using modules or (a complete thought) the programmer creates a logical thought process for the computer to follow. After that the program is broken down in greater detail using pseudocode. Pseudocode uses terms like if, else, and, then to relate the programs rules to the computer.

Two mini steps:

• Determine program logic through top down approach and modularization, using a hierarchy chart
• Design details using pseudocode and/or flowcharts, preferably involving control structure.

A module, a processing step of a program, made up of logically related program statements.

A hierarchy chart, which represents top-down program design, explains the main purpose of the program.

Pseudocode, a way of designing a program which uses normal language statements in order to describe the logic and the processing flow.

Program flowcharts, graphically shows the detailed series of steps Three control structure

Sequence control structure - No decision making

Selection control structure –

Loop control structure/Repetition or Iteration Structure

Case structure

Pseudocode for sum of two numbers (design the problem)

BEGIN

input n1, n2

sum = n1 + n2

display total

END

3. Code the program

After the program has been designed it must be coded or written. Using the pseudocode and logic requirements from step two an appropriate programming language must be selected. As stated in the introduction, coding languages differ in specifications and usability. Once the appropriate code language has been chosen, it is imperative that the programmer follow the syntax rules with as little deviation as possible in order for the program to have high accuracy.

Two mini steps:

• Select the appropriate high-level programming language
• Code the program in that language following the syntax carefully

Python code for sum of two numbers (code the problem)

Figure 4 python code sum of two numbers

4. Test the Program

After the program is written it then enters the programming debugging and testing phase of the Program Development Life Cycle (PDLC). During this time the programmer will be looking for errors in both logic and syntax, as well as exploring other areas that may cause the program to either not work properly or to not run at all.

This process is a lengthy and tedious one, oftentimes consisting of up to 50% of a program’s time in development (Morley 523). However, with a careful eye paid to program design and coding the amount of time spent debugging can be cut considerably.

As stated, debugging will uncover errors in both logic and syntax. Syntax errors will prevent the program from executing. They can be such simple things as misspelled words or can involve breaking the syntax rules of the programming language used.

On the other hand, logic errors will allow the program to run but will provide incorrect results. Errors of this kind may consist of merely using the wrong relational operator or larger, mistakes in writing formulas.

Once the programmer locates the errors they are then fixed and the program is run again. This will happen multiple times, often called “execute, check, and correct” (526), until the program runs flawlessly.

The program will then enter the testing phase.

Testing the program comes in two phases, alpha and beta.

• Alphatesting is the process of reading through the program in search of errors in logic. The second step is to run a diagnostic program to search for syntax or input errors.
• Betatesting involves using the program in the real world to see if it contains any bugs or other deficiencies.

Testing the python program

Figure 5 testing the sum of two numbers

5. Document and Maintain

Documentation should be ongoing from the very beginning because it is needed for those involved with program now and future. Upon completion User Documentation for commercial use, Operator Documentation for people who run computer systems, and Programmer Documentation for programmers charged with maintenance.

Four mini steps: -

• Write user documentation.
• Write operator documentation.
• Write programmer documentation.
• Maintain the whole program.

Every program requires certain processing time and memory to process the instructions and data. As the processing power and memory are the most precious resources of a computer, a program should be laid out in such a manner that it utilizes the least amount of memory and processing time

Figure 6 program development life cycle

1.2.2 Dry run

Dry run testing is a static test and should be performed by the developer to mitigate the effects of a failure of the product - meaning before the end user gets the product and discovers it doesn't do what it says it will. In dry run testing, no hardware is used, but it is assumed that the programmer who is testing the code is aware of what each line of code is supposed to do and gives him or her the opportunity to make corrections to the code before it becomes an issue for the actual software. Basically, a dry run test consists of programmers manually reading their code line by line to find errors and fix them. This is a simple Visual Basic code page; a full software application code page would look much more involved.

1.2.3 Dry run for linear search

Data found

Example:

List [20,15,30,27,47,89,90,67,16,7,56]

Search data [89]

Table 1 linear search (data found)

Results = data found

Table 2 linear search (data not found)

Data not found

Results = data not found.

1.2.4 Dry run for binary search

Data found

List 1[10,5,25,32,65,41,120,56,77,78,80]

Sorted the list 1[5,10,25,32,41,56,77,78,80]

Search data=25

Table 3 binary search (data found)

Data not found

Table 4 binary search (data not found)

1.3 Define what Big-O notation is and explain its role in evaluating efficiencies of algorithms. Write the Python program code for the above two algorithms and critically evaluate their efficiencies using Big-O notation

1.3.1 Big o notation

Big O notation is a convenient way to describe how fast a function is growing.

When studying the time complexity T(n) of an algorithm it’s rarely meaningful, or even possible, to compute an exact result. Typically, we are only interested in how fast T(n) is growing as a function of the input size n.

1.3.2 Efficiency of algorithms

• Computational resources: time and space
• Best, worst and average case performance

How to compare algorithms: machine-independent measure of efficiency

Growth rate

Complexity measure O ()

How much time does it need

How much memory (space) does it use

Algorithm is a well-defined sequence of steps which leads to solving a certain problem. Steps should be:

concrete

unambiguous

there should be finitely many of them

Best, worst and average case Linear search:

Best performance: the item we search for is in the first position; examines one position

Worst performance: item not in the array or in the last position; examines all positions

Average performance (given that the item is in the array): examines half of the array

Binary search

Best case - item in the middle, one check

Worst case - item in the last possible division; the maximal number of times an array of length N can be divided is log2 N

Average case: item is found after performing half of the possible number of divisions; ½ log2 N

More useful algorithm

Which is more useful?

For real time programming: the worst case

For getting a general idea of running time: average case; however, often difficult to establish • For choosing between several available algorithms: helps to know what is the best case (maybe your data are in the best-case format, for example random).

Machine Independence

The evaluation of efficiency should be as machine independent as possible.

For the time complexity of an algorithm,

we count the number of basic operations the algorithm performs

we calculate how this number depends on the size of the input.

Space complexity: how much extra space is needed in terms of the space used to represent the input.

Basic operations

Basic operations are operations which take constant time (at most time C for some constant C). In other words, time required to perform the operation does not grow with the size of the operands, or is bounded by a constant.

Basic operations contd.

If we are not sure how operations are implemented, we have to exercise judgement: can something be in principle implemented as a constant time operation?

For example, adding two 32-bit integers can be, but adding a list of 32-bit integers cannot: it is going to take longer for a longer list.

1.3.3 Python program for two algorithms

linear search (data found)

def linear search (list, search):

position=-1:

for I in range (0, Len(list)-1):

if list[I]==search:

positioni+1

break

if position=! =-1:

print (“data found”)

print (“position, position”)

else:

print (“data not found”)

k= [10,20,58,45,32,6,54,95,68,7,5,36,21]

search data=45

linear search (k, search data)

Figure 7 python code for linear search data found (big o notation)

linear search (data not found)

Figure 8 python code for linear search data not found (big o notation)

python code for binary search

def binary_search (item_list, item):

first = 0

last = Len(item_list)-1

found = False

while (first<=last and not found):

mid = (first + last)//2

if item_list[mid] == item:

found = True

else:

if item < item_list[mid]:

last = mid - 1

else:

first = mid + 1

return found

print (binary_search ([1,2,3,5,8], 8))

data found

Figure 9 python code for binary search data found (big o notation)

Data not found

Figure 10 python code for binary search data not found (big o notation)

1.3.4 Provide above algorithm critically evaluate their efficiencies using Big-O notation

Big O Notation is the language we use to describe the complexity of an algorithm. In other words, Big O Notation is the language we use for talking about how long an algorithm takes to run. It is how we compare the efficiency of different approaches to a problem. With Big O Notation we express the runtime in terms of — how quickly it grows relative to the input, as the input gets larger.

There’s a little linear search function for a small, fixed-size array, with the comment “do a binary search or lookup table later”. One of our Google Summer of Code students took this to heart and implemented a binary search that was unfortunately not only incorrect but also slower than the linear search. This is not too surprising, because implementing a binary search is anything but trivial, despite the seeming simplicity of the algorithm. Also, common wisdom says that for small array sizes, linear search beats binary search. I took this as the starting point for a little project, to find out about the respective virtues of linear and binary search on modern CPUs.

To limit the scope of this project, I concerned myself only with searching in small to medium sized sorted arrays of integers, producing the index of the first element that is equal to or greater than the search key. My results will not necessarily apply to other applications.

Although I will briefly explore the usage of SIMD instructions to speed up linear search this is not the primary purpose of this project, so I haven’t benchmarked those implementations as extensively, but I will present a few results.

Linear search

def linear search (list, search):

position=-1:

for I in range (0, Len(list)-1):

if list[I]==search:

positioni+1

break

if position=! =-1:

print (“data found”)

print (“position, position”)

else:

print (“data not found”)

k= [10,20,58,45,32,6,54,95,68,7,5,36,21]

search data=45

linear search (k, search data)

Every loop iteration here does two conditional branches: One to check whether we’re already at the element we’re looking for and the other to check whether we’re at the end of the array. Fortunately, both are easy to predict: By predicting that we’re not at the end of the array and that we haven’t found the element yet, we get exactly one branch misprediction per search, which is hard to improve upon. We can, however, reduce the total number of branches. First, by unrolling the loop, like this:

Linear search with SSE2

Using a SIMD instruction set like SSE2 we can further reduce the number of instructions per array element. First, we can load 4 array elements in one go into a 128-bit register. Then we can do 4 comparisons in parallel (with PCMPGTD) if we have prepared another register with 4 copies of key. We can then get the results of those comparisons into a general-purpose register (with PMOVMSKB) which we can then compare to the result we would expect if none of the 4 array elements match our key yet, in which case we increment our counter and repeat the loop. If the result indicated that one of the keys does match, we can use the BSF instruction, which counts the number of trailing zero bits in a register, to determine the index of the matching element without needing another loop. Using GCC’s SSE2 built-ins, the basic loop looks like this:

This loop can of Assignment be unrolled, as well. Note that after the sentinel we require that there be at least 3 more dummy array elements so that the load doesn’t result in a segmentation fault. If the array is properly aligned to 16 bytes that will always be the case.

We are now at one conditional branch per 4 array elements, but we can go even lower. Using the PACKSSDW and PACKSSWB instructions we can pack the results of 16 key comparisons into one vector which we can then move into a general-purpose register like above and branch on it. We’ll require even more dummy memory after the sentinel. Here’s what it looks like:

Binary search

def binary_search (item_list, item):

first = 0

last = Len(item_list)-1

found = False

while (first<=last and not found):

mid = (first + last)//2

if item_list[mid] == item:

found = True

else:

if item < item_list[mid]:

last = mid - 1

else:

first = mid + 1

return found

print (binary_search ([1,2,3,5,8], 8))

This will work for n < MAX_INT/2. For larger n, middle must be calculated as min + ((max - min) >> 1), which is one subtraction per iteration more.

Each iteration here also does two unconditional branches, one of which is essentially unpredictable. There’s no way for the CPU to know in which of the two halves of the search space the element you’re looking for will be, which means that we’ll get on average one branch misprediction per two iterations.

There is a way around this unconditional branch, however: It can be turned into two conditional move instructions. I haven’t found a way to tell GCC to do this, so I had to do it using inline assembly (for x86 and AMD64):

Figure 11 Linear search with SSE2

On the horizontal axis we have the array size and on the vertical axis we have the runtime for one search in seconds. As you can see the curves for the two binary searches with conditional move – plain and unrolled – are almost identical. The unrolled linear search beats plain linear search by more than a factor of two, and the unrolled linear search with sentinel is faster still. For array sizes larger than around 80, the unrolled SSE2 linear search (with sentinel) beats the best regular linear search, but below they are at about the same level. At around an array size of 100 we can see the fastest binary search starting to win against the fastest linear search. The fastest regular linear search can hold on against plain binary search until about an array size of 200. The SSE2 linear search is beaten by plain binary search only at an array size of over 400, which is not on the diagram. The 16-element per conditional branch SSE2 linear search (not shown in the diagram), which outperforms even the “normal” unrolled SSE2 search for larger array sizes, can hold on until about 550.

We can also calculate that at the breakeven point of 100 each search took on average almost exactly 50 cycles. For the linear search this means that each iteration took one cycle (because if you’re searching for random elements in an array of size 100 you have to visit an average of 50 elements), whereas each binary search iteration took about 6 cycles on average.

On a Core 2 (at 1.86 GHz) things look a bit different:

Figure 12 binary search with SSE2

The SSE2 optimized linear search doesn’t perform nearly as well as the unrolled linear sentinel search below 100, and the breakeven point with the fastest binary search is at around 64. We can also see that the unrolled binary search performs a bit better than the one without unrolling.

The following table summarizes the most important results for all the CPUs on which I’ve run the benchmarks. It does not include data for the SSE2 optimized linear searches because I have only run those on two of the CPUs in the table.

Figure 13 CPU SSE2

The column “Best” gives the asymptotically fastest search. “Best linear” is the asymptotically fastest linear search and “Best linear short” is the fastest linear search for small array sizes. “B/E” (for “break even”) is the array size for which the fastest binary search overtakes the fastest linear search. The last column, “Cycles @ B/E” gives the average number of cycles per search at the breakeven point.

As a last interesting tidbit, here’s a table that gives the performance of the fastest linear searches for an array size of 1000, in number of processed array elements per clock cycle:

Figure 14 PERFORMANCE OF TWO ALGORITHM

1.3.5 Conclusion for this two-algorithm performance

To put everything, I’ve learned from this into a few words: If you need to search through a sorted array of integers and performance is really, really important, use linear search if your array is below around 64 elements in size, binary search if it’s above. If you use linear search, it’s best to use a sentinel and to unroll the loop (16 times recommended). If you use binary search, make sure your code uses conditional moves inside the loop instead of a conditional branch. If you’re very, very serious about performance and know the array size statically, completely unroll the binary search.

Task 2: Explain the characteristics of procedural, object-orientated and event-driven programming, conduct an analysis of a suitable Integrated Development Environment (LO2)

2.1 Define what is meant by a Programming Paradigm. Explain the main characteristics of Procedural, Object oriented and Even-driven paradigms and the relationships among them

2.1.1Programming Paradigm

The first programming paradigm that a new developer is likely to learn is procedural or imperative programming. If you’re a stickler, those two are different. For me they’re close enough that it doesn’t matter.

Fundamentally procedural or imperative code is something that directly instructs a computer how to complete a task that you want it to do in logical steps. Rather than declaring the world’s state (as we mentioned declarative things like CSS do), you’d define that you shall make these things by cycling through this, appending it to that, and putting the result here.

Much of WordPress is fundamentally procedural, in that (theme template files, for example) are a direct set of very literal PHP and WordPress function calls that together accomplish the creation of a web page. This procedural style has a great advantage that it is less confusing than many alternatives, and there is less routing around through lots of different complicated concepts for most newer developers.

One common (and understandable) thing that confuses people (me included) is that the use of functions doesn’t in any way mean you’re not doing procedural programming. One of the most common ways that functions are used in PHP is in fact as a kind stored procedure that redoes the same mechanistic procedure whenever called. This is not “functional programming,

2.1.1.1 PROCEDURAL PROGRAMMING

The biggest knock against procedural programming is really that it’s among the oldest ways of programming. As a result of this, it’s derided as outmoded and generally not very cool. But those are pretty soft complaints. More concrete complaints that I think are good:

It is often hard to think clearly about the overriding program. Naming procedures with functions can help to simplify the machine-like nature of procedural code, but fundamentally the way humans and computers think aren’t that similar, so code that hews too close to what machines like confuses humans often.

There are no abstractions. Good programs abstract simple things from more complex underlying realities. They favor human comprehension over machine efficiency. There are times when you can’t have this for performance reasons, and in those cases procedural code can be faster and thus better.

Good things about procedural programming

That said, some really good things come out of procedural programming too. The first and most important is that it’s not over-abstracted, which can be a real help for newcomers. Understanding objects generally seems to feel more complicated to newcomers than a few function calls.

Procedural programs can also be faster than most alternatives. This is especially true historically. You easily get the maximum performance out of procedures because you’re “empathetic” to what the machine’s most efficient way to perform a task is. If you can do it in one call rather than 500, when you write procedural code you generally realize and do this.

Find the sum of two numbers

Figure 15 procedural programming SUM

Output for sum of two numbers

Figure 16 output for procedural programming sum

2.1.1.2 object-orientated

In an object-oriented program, you instead have a $message object, which is usually an instance of the Message class. This object has properties that people can be publicly read, like $message-was read and actions that it performs like message->destroy (). These are helpful, because we as humans are used to thinking about objects. We understand the idea that named things emerge from the chaos of the world and makes it easier for us to understand that world. That’s what a “chair” is, after all.

An event-driven program is one that largely responds to user events or other similar input. The concept of event-driven programming is an important one in application development and other kinds of programming and has spawned the emergence of event handlers and other resources.

Characters of object orientated program

Encapsulation – Encapsulation is capturing data and keeping it safely and securely from outside interfaces.
Abstraction- The ability to represent data at a very conceptual level without any details.

Inheritance- This is the process by which a class can be derived from a base class with all features of base class and some of its own. This increases code reusability.

Polymorphism- This is the ability to exist in various forms. For example, an operator can be overloaded so as to add two integer numbers and two floats.

Figure 17 object-orientated class

Figure 18 output for object-orientated class

2.1.1.3 event-driven

It reacts to specific kinds of input from users, whether it's a click on a command button, a choice from a drop-down list, an entry into a text box, or other kinds of user events.

Other programming languages may feature user events that are largely delivered through a command-line interface or some other type of user interface. The opposite of event-driven programming would be programming that is written to act regardless of user input.

For example, display apps such as those for weather updates or sports scores may feature less of the event-driven programming that is inherent in other kinds of programs. However, nearly all software relies on user events for functionality, and it would be easy to argue that event-driven programming is the default for nearly all kinds of projects.

That's because, in general, applications and code modules are written to respond to human actions, which is part of the core concept of how humans work with machines. However, identifying event-driven aspects of programs can be helpful in design analysis.

characteristics of event-driven programming

Emphasis on data rather than procedure

Programs are divided into entities known as objects

Data Structures are designed such that they characterize objects

Functions that operate on data of an object are tied together in data structures

Data is hidden and cannot be accessed by external functions

Objects communicate with each other through functions

New data and functions can be easily added whenever necessary

Follows bottom up design in program design

Service Oriented

Service oriented is a key feature in event-driven programming that used to write programs that are made for services and it takes does not slow down the computer as service oriented only consume little of the computer processing power and usually services run in the background of OS.

Time Driven

In event driven programming, time driven is a paradigm, it's a code that runs on a time trigger, time driven can be a specific code that runs on a specific time, which could be once an hour, once a week or once a month, this means it's a pre-set to do task. For example, windows update is the example of time driven, which user can set when to update or when to check and download the update.

Simplicity of Programming and Ease of Development

Event-driven programming is simple and easier to program compared to other type of programming as it's very visual, for example you can place a button by just select it and place it onto a form and write a code for it. Event-driven programming also easy for user to insert a pre-written code scripts into an existing application because it allows user to pause the code while it's running. Which make developing using event-driven programming is easy.

Figure 19 coding for event-driven (sum)

Figure 20 event-driven sum

2.1.2 Comparison between procedural, object oriented, even-driven paradigms

Difference between various paradigms

Programming paradigm is another method of classification of programming languages. Examples of paradigms include procedural paradigm (BASIC, COBOL, Ada), object-oriented paradigm (Java, C++), declarative paradigm (Prolog) and functional paradigm (LISP, Scheme), event-driven paradigm (VB, C#). The primary differences between each type of programming paradigms are described below.

Table 5 Comparison between procedural, object oriented, even-driven paradigms

2.2 Analyze the features of an Integrated Development Environment (IDE) and explain how those features help in application development

2.2.1 Integrated Development Environment

An integrated development environment (IDE) is a software suite that consolidates the basic tools developers need to write and test software. Typically, an IDE contains a code editor, a compiler or interpreter and a debugger that the developer accesses through a single graphical user interface (GUI). An IDE may be a standalone application, or it may be included as part of one or more existing and compatible applications.

An IDE's toolbar looks much like a word processor's toolbar. The tools in the toolbar facilitate color-coding, source-code formatting, error diagnostics, and reporting and intelligent code completion. The interface allows the developer to compile and execute code incrementally and manage changes to source code in a uniform manner. IDEs are typically designed to integrate with third-party version control libraries, like GitHub or Apache Subversion.

Increasingly, IDEs are being offered through a software-as-a-service (SaaS) delivery model. The benefits of cloud IDEs include accessibility to software development tools from anywhere in the world, from any compatible device; minimal to nonexistent download and installation; and ease of collaboration among geographically dispersed developers. Popular IDE tools include NetBeans, Eclipse, IntelliJ, Visual Studio and Windows PowerShell.

A software IDE is an application that developers use to create computer programs. In this case, "integrated" refers to the way multiple development tools are combined into a single program. For example, a typical IDE includes a source code editor, debugger, and compiler. Most IDEs also provide a project interface that allows programmers to keep track of all files related to a project. Many support version control as well.

Some IDEs provide a runtime environment (RTE) for testing software programs. When a program is run within the RTE, the developer can track each event that takes place within the application being tested. This can be useful for finding and fixing bugs and locating the source of memory leaks. Because IDEs provide a centralized face for writing code and testing programs, a programmer can make a quick change, recompile the program, and run the program again. Programming is still hard work, but IDE software helps streamline the development process.

2.2.2 Common IDE Features

The Explorer

The Explorer Filesystems tab presents a hierarchical view of directories and files that have been mounted for use in NetBeans. Files that are used by BBx or one of their accessory programs, such as App Builder, are identified by unique icons to the left of the name. Clicking on one of these files with the left mouse button selects it, while clicking with the right mouse button opens a popup menu displaying the operations available for that file.

The Source Editor

The Source Editor is a modern programmer's text editor that is optimized for writing Business BASIC source code. BBx program files in either text or tokenized format can be opened and edited. The Source Editor provides color syntax highlighting and sophisticated editing features such as advanced text find and replace, keyboard macros, word matching, abbreviation expansion, and quick navigation with bookmarks or Go To line number. Automatic popup code completion simplifies the use of BBj Object Syntax. Breakpoints can be set and saved from the Source Editor for convenience in later debugging sessions. The Source Editor is not connected with a BBj interpreter session and therefore does not require BBj Services to be running when it is used. It is the tool of choice when writing new code or making extensive changes to existing source files. When BBx source code is compiled, any resulting errors are displayed in the Source Editor via hyperlinks from the Compiler Output Window.

The Debugger

The Debugger incorporates BBj debugging and editing tools into the NetBeans environment, adding the ability to work with multiple files and manage projects. The Debugger features color syntax highlighting and code completion like the Source Editor, although other advanced code editing features may not be available. Unlike the Source Editor, the Debugger is always connected to a BBj interpreter and performs automatic syntax error checking as code is modified. Programs can be executed in the Debugger via command line dot-stepping. Breakpoints can be inserted to control the flow, and variables can be monitored in the Watch Tab. The Debugger is the tool of choice for testing application code and making minor editing corrections.

The Compiler

The IDE allows the compiling of Business BASIC source code into three different token formats. If a development system has PRO/5 installed along with BBj, tokenized program files can be created in any of these formats. Text files and directories of files to be compiled are selected in the NetBeans Explorer. Choosing Compile/Compile All or Build/Build All from the menu feeds all the selected files or directories to the compiler of the desired token format. Any resulting errors are displayed as hyperlinks in the NetBeans Compiler Output Window. Double-clicking on an error hyperlink causes the original text source file to be automatically opened in the Source Editor, where the line containing the error is highlighted.

The Data File Viewer

The Data File Viewer provides a convenient way to view the contents of database files. Like the character-based _browse utility, it does not allow creation or editing of data files, but instead displays their contents in hexadecimal and ASCII. The Data File Viewer uses the BBj Filesystem Server to open and parse database files, which means that BBj Services must be running in order to use it.

The Data Dictionary

The IDE's Data Dictionary plug-in module provides the ability to view and maintain BASIS data dictionaries in the same environment used for developing applications. Like the previous tool, DD Builder, the Data Dictionary module provides access to dictionaries located on the local machine (or accessible via mapped drives or UNIX mounts) as well as dictionaries accessible through PRO/5 Data Servers. However, unlike DD Builder, the Data Dictionary has access to remote BBj databases, and is available on all supported UNIX platforms with GUI support.

The Form Builder

The Form Builder plug-in module replaces the MS Windows-only Res Builder utility and is used to create graphical user interfaces for BBj programs. Graphical controls are arranged on a "form" just as they will appear in the application program. Form Builder saves the resulting interface to an ASCII resource file with the extension .arc, which BBj uses to create the actual GUI interface at runtime

An integrated development environment (IDE) is an application that facilitates application development. IDEs are designed to encompass all programming tasks in one application. Therefore, IDEs offer a central interface featuring all the tools a developer needs, including the following:

Code editor: This feature is a text editor designed for writing and editing source code. Source code editors are distinguished from text editors because they enhance or simplify the writing and editing of code.

Compiler: This tool transforms source code written in a human readable/writable language into a form executable by a computer.

Debugger: This tool is used during testing to help debug application programs.

Build automation tools: These tools automate common developer tasks.

In addition, some IDEs might also include the following:

Class browser: This tool is used to examine and reference the properties of an object-oriented class hierarchy.

Object browser: This feature is used to examine the objects instantiated in a running application program.

Class hierarchy diagram: This tool allows the programmer to visualize the structure of object-oriented programming code.

The IDE may be a stand-alone application or may be included as part of one or more compatible applications.

2.2.3 Benefits of IDE

The overall goal and main benefit of an integrated development environment is improved developer productivity. IDEs boost productivity by reducing setup time, increasing the speed of development tasks, keeping developers up to date and standardizing the development process.

Faster setup: Without an IDE interface, developers would need to spend time configuring multiple development tools. With the application integration of an IDE, developers have the same set of capabilities in one place, without the need for constantly switching tools.

Faster development tasks: Tighter integration of all development tasks improves developer productivity. For example, code can be parsed and syntax checked while being edited, providing instant feedback when syntax errors are introduced. Developers don’t need to switch between applications to complete tasks. In addition, the IDE’s tools and features helps developers organize resources, prevent mistakes and take shortcuts.

Further, IDEs streamline development by encouraging holistic thinking. They force developers to think of their actions in terms of the entire development lifecycle, rather than as a series of discrete tasks.

Continual learning: Staying up to date and educated is another benefit. For instance, the IDE’s help topics are constantly being updated, as well as new samples, project templates, etc. Programmers who are continually learning and current with best practices are more likely to contribute value to the team and the enterprise, and to boost productivity.

Standardization: The IDE interface standardizes the development process, which helps developers work together more smoothly and helps new hires get up to speed more quickly.

SAP Web IDE is a flexible tool for developers to accelerate asynchronous development, especially in a geographically distributed team environment.

Review the following SAP Web IDE features to fully understand how your application development can benefit from them.

Build SAPUI5 applications applying SAP Fiori UX guidelines using wizards, templates, and WYSIWYG editors.

Expedite coding and testing by using a collection of dynamic interactive features, such as code completion and API reference support.

Instantly preview your applications for any screen size - desktop, tablet, or smartphone.

Use mock data to build and preview your entire application UI without connecting to any system.

Deploy on SAP HANA Cloud Platform (HCP) and SAP ABAP using Business Server Pages (BSP).

Use SAP Web IDE's extensible framework to easily extend SAP delivered applications through plugins and templates.

Use source control in your SAP Web IDE project to manage your code and improve your workflow.

Some ide and their features

Microsoft Visual Studio

Microsoft Visual Studio is a premium IDE ranging in price from$699 – $2,900 depending on the edition and licensing. The many editions of this IDE are capable of creating all types of programs ranging from web applications to mobile apps to video games. This series of software includes tons of tools for compatibility testing so that you can see how your apps run on more than 300 devices and browsers. Thanks to its flexibility, Visual Studio is a great tool for both students and professionals.

Languages Supported: ASP.NET, DHTML, JavaScript, JScript, Visual Basic, Visual C#, Visual C++, Visual F#, XAML and more

Notable Features:

A massive library of extensions that is always growing

IntelliSense

Customizable dashboard and dock able windows

Straightforward workflow and file hierarchy

Insights for monitoring performance in real time

Automation tools

Easy refactoring and code snippet insertion

Split screen support

Error list that allows debugging while building

Approval checks when deploying apps via Click Once, Windows Installer or Publish Wizard

Drawbacks: Because the Visual Studio is a heavyweight IDE, it takes considerable resources to open and run, so making simple edits may be time consuming on some devices. For simpler task, it may be easier to use a lightweight editor

NetBeans

NetBeans is a free and open-source IDE. Ideal for editing existing projects or starting from scratch, NetBeans boasts a simple drag-and-drop interface that comes with a myriad of convenient project templates. It is primarily used to develop Java applications, but you can download bundles that support other languages.

Languages Supported: C, C++, C++11, Fortan, HTML 5, Java, PHP and more

Notable Features:

Intuitive drag-and-drop interface

Dynamic and static libraries

Multi-session GNU debugger integration with code assistance

Allows for remote development

Compatible with Windows, Linux, OS X, and Solaris platforms

Supports Qt Toolkit

Supports Fortan and Assembler files

Supports a number of compilers including CLang/LLVM, Cygwin, GNU, MinGW and Oracle Solaris Studio

PyCharm

PyCharm is developed by the folks over at Jet Brains and provides users a free Community Edition, 30-day free trial for the Professional Edition, $213 – $690 for an annual subscription. Comprehensive code assistance and analysis make PyCharm the best IDE for Python programmers of all ability levels. PyCharm also supports other languages and works on multiple platforms, so practically anyone can use it.

Languages Supported: AngularJS, Coffee Script, CSS, Python, HTML, JavaScript, Node.js, Python, TypeScript and template languages

Notable Features:

Compatible with Windows, Linux, and Mac OS

Comes with Django IDE

Easy to integrate with Git, Mercurial and SVN

Customizable interface with VIM emulation

JavaScript, Python and Django debuggers

Supports Google App Engine

XCode

XCode IDE is free, open-source, and part of XCode, which is a collection of tools for making apps for Apple devices such as the iPad, iPhone and Mac. Integration with Cocoa Touch makes development in the Apple environment a breeze, and you can enable services such as Game Center or Passbook with a single mouse click. Built-in communication with the developer’s website helps users produce fully functioning apps on the fly.

Languages Supported: AppleScript, C, C++, Java, Objective-C

Notable Features:

UI controls can be easily connected with implementation code

Apple LLVM compiler scans code offers advice for addressing performance issues

Assistant function allows for split-code workspace

Jump bar permits quick navigation

Interface Builder lets user build prototypes without writing any code

UI and source code can be graphically connected to sketch complex interface prototypes in just minutes

Version Editor includes log files and commit timeline

Branch and merge for distributed teams

Test Navigator lets you quickly test applications at any point during development

Automatically builds, analyzes, tests, and archives projects thanks to Integration with OX X server

Workflow is highly customizable with Tabs, Behaviors, and Snippets

Instrument library and asset catalog

2.3 Write small snippets of code as example for the above three programming paradigms using a suitable programming language(s) and critically evaluate their structure and the characteristics

2.3.1 Python Procedural Programming

Example:

Simple code:

Python code for procedural programming

Figure 21 Python simple code Procedural Programming

Out put for procedural programming

Figure 22 Output for procedural programming

2.3.2 Object-Orientated Programming

Python code for object-orientated programming

Figure 23 Python code for object-orientated programming

Output for object-orientated programming

Figure 24 Output for object-orientated programming

2.3.3 Even driven programming

C# code for Even driven programming

Figure 25 C# code for Even driven programming

Output for Even driven programming

Figure 26 Output for Even driven programming

Task 3: Implement basic algorithms in code using an IDE (LO3)

3.1 Design suable algorithms for vehicle tariff calculation for rents and hires

Ideally 3 functions should be developed for this purpose as follows:

Function 1: Rent calculation.

Return the total rent_value when rented_date, return_date, with_driver parameters are sent in. with_driver parameter is set to true or false depending whether the vehicle is rented with or without driver.

3.1.1 Pseudocode for rent calculation

Function 1 rent calculation (rented_date, return_date, is driver)

Begin

Total rent = 0

Total days = return days-started date

If is driver=true

Driver amount = total day * per driver day

While total day = 0

If total day > = 30

Total rent + = monthly rent

Total days - = 30

Else total day > = 7

Total rent + = weekly rent

Total day - = 7

Else

Total rent + = (day rent*total days)

Total days = 0

End while

Total amount + = total driver amount

Return total amount

End

Function 2: Day tour - hire calculation.

Calculate total hire_value when start_time, end_time, start_km_reading,

end_km_reading parameters are sent in. Should return base_hire_charge, waiting_charge and extra_km_charge as output parameters.

3.1.2 Pseudocode for day tour-hire calculation

Function 2day tour hire calculation (start_time, end_time, start_km, end_km,):

Begin

Basic hire charge: calculation based on vehicle type and package type

Tot_hours=end_time-start_time

Total_kms=end_km-start_km

If tot_hours>allocated_hours then

Waiting_charge=(total_kms_allocated_hours) *extra 1 hour’s charge

End if

If total_kms>allocated kms then

Extra_km_charge=(total_kms_allocated_kms) *extra_1km_charge

End if

End

Function 3: Long tour - hire calculation.

Calculate total hire_value when start date, end date, start_km_reading, end_km_reading parameters are sent in. Should return base_hire_charge, overnight_stay_charge and extra_km_charge as output parameters

3.1.3 Pseudocode for long tour-hire calculation

Function long_tour_hire (start_date, end_date, start_km, end_km): base_hire_charge, over_night_charge

Begin

Basic hire charge = calculation based on vehicle type and package

Tot_days=end_date-start_date

Tot_kms=end_km - start_km

If tot_kms>allocated_kms

Extra km charge=(tot_kms_allocated_kms) *extra_1hour_charge

If tot_days>=2 than

Total_driver_charge=(tot_days-1) *1_day_driver_over night_charge

Total_overnight_park_charge=(tot_days-1) *1_day_overnight_park_charge

Overnight charge=total_driver_charge+total_overnight_park_charge

End if

3.2 Implement the above algorithms using visual studio IDE (using C#.net) and design the suitable database structure for keeping the tariffs for vehicle types and different packages which must be used for implementing the above functions

Main form

Figure 27 Main form for calculation

Main form coding

Figure 28 Main form coding

3.2.1 Rent calculation

Figure 29 Rent calculation

Rent calculation coding

Figure 30 Rent calculation coding

With driver (rent calculation) out put

Figure 31 With driver (rent calculation) out put

Without driver (rent calculation) out put

Figure 32 Without driver (rent calculation) out put

3.2.2 Day tour calculation

Figure 33 Day tour calculation form

Day tour calculation coding

Figure 34 Day tour calculation coding

Day tour calculation out put

Figure 35 Day tour calculation out put

3.2.3 Long tour calculation

Figure 36 Long tour calculation

Long tour calculation coding

Figure 37 Long tour calculation coding

Long tour calculation out put

Figure 38 Long tour calculation out put

3.3 What is the purpose of using an IDE in application development? Evaluate the use of the Visual Studio IDE for your application development contrasted with not using an IDE.

3.3.1 Purpose of Using an IDE in Application Development?

Project File Organization

An IDE organizes projects you work on (VS makes projects part of solutions, doesn’t matter much about nomenclature)

This also should include version control of source files - todays standard would mean handling a git repository.

Editor
Typically at least an editor with syntax highlighting of at least one programming language, typically supporting more, especially in the case of web development.

Runtime environment and Debugger

If an IDE isn’t runtime environment and has a debugger inside, it’ll at least be able to configure all that and allow single stepping through code. Typical web development IDEs will provide an express local webserver other than your companies IIS or your hosters Apache or nginx, online IDEs might attach to that, should rather have a dev variant anyway, because you don’t develop in production environment, that’s only our final release target after testing and stabilizing a new version or fix.

Compiler/Linker
At least for languages other than HTML/CSS/JS/PHP/PERL/PYTHON the IDE can generate EXE, DLL (Assembly or cdecl or resource DLL)

Profiling

Good IDEs ahould also allow you profiling of performance of your application. Another feature to enhance debugging and testing.

More

An IDE should be a test environment, too, not only in terms of debugging, also in terms of tests, mainly component and unit tests. Enabling to verify functionality with specified test calls and results, enabling to test components with the help of mockups and stubs simplifying dependencies.

The purpose of an IDE is just that--an Integrated Development Environment. its purpose is to make tasks quicker and centralized, basically.

why use vim when you can use 'echo my code > file.c'? because vim is specialized for the specific task of text editing and is much easier than using echo >/>> each time you want to write something. IDEs try to make everything simple by allowing you to view, edit, debug, and compile code in one interface.

one downside to IDEs I have found (or at least popular ones such as Visual Studio .NET and Eclipse, which are both excellent by the way) is the extra garbage it creates. by garbage I mean all the extra files and folders. for example, a simple hello world c++ program written in Visual Studio .NET would be a few megabytes, with the .cpp file being 1kb.

at school I use a command window and the history (2 commands--cc, /filename), and a GUI text editor. we have eclipse installed on our Unix terminals at school but due to the incredible load of the servers, it freezes often so its quickest to use a simple editor and command window for compiling.

if you find using the command line-based tools is working smoothly and efficiently for you then i wouldn’t see a need to use an IDE.

IDE" is such a loose terminology. If you're using some of Vim's external-integration features, like the: make command and :cn and :cl to step through compiler errors, you're using an IDE in some sense. As such, I consider the differentiation between a sufficiently advanced editor (Vim, Emacs, edit, but not Notepad or the like) and an IDE completely irrelevant and a matter only of what words you prefer to use

That said, the software that most people consider IDEs (Eclipse, JBuilder, Visual Studio) I consider bloatware. They eat resources and produce worthless extraneous files and features, and they over-complicate the already difficult task of programming. You'd be better off understanding your code, how its inter-related, and how to build it manually than to rely on some magical tool. In my opinion, of Assignment. I'm sure my myriads of professors who have insisted on JBuilder and Eclipse for everything would disagree.

So, my advice is, use the integrating features of your particular favorite editor, be it Vim or Emacs or what-have-you, to interact with the standard CLI tools you need, like make or gdb or ant. That way you will understand what's happening "under the hood" with your project, and have the full flexibility of the underlying tools at hand, but still be able to work quickly from within one environment. Of Assignment, I believe in Emacs, but Vim works very well right out of the box as well, you've just got to learn the editor's features.

The purpose of an IDE is to tie together various programming tools with GUI widgets to make it easier for some folks to use those tools.

If you're comfortable with the various command line tools (editor, debugger, some sort of code structure browser), then an IDE will be of no use to you.

Best bet is to start with an editor (I recommend GNU Emacs), then learn the command line tools as you need them, *then* try an IDE if you want.

Using an IDE on day one may not serve you best in the long run.

3.3.2 Visual Studio IDE

Figure 39 Visual Studio IDE

Put simply Visual Studio is a tool for writing code. As others have mentioned, it supports writing code in all kinds of languages including non-Microsoft languages.

Of Assignment, you can also write code with notepad, or notepad++ or sublime text (my favorite one). These are text editors. Text editors are lightweight and fast but they offer few helps for writing your code. (Although sublime text supports some extensions that help a little bit.)

A bit up the scale is Visual Studio Code which is a fairly new lightweight, open-source editor that is multi-platform (runs on Windows, Mac, and Linux) is extensible, offers a lot of helps (intelligence, debugging, basic refactors, etc. ) but does not do as much for you as full Visual Studio. It is like a powerful text editor.

On the other end of the scale is full Visual Studio. This level of editor is called an Integrated Development Environment or IDE. It is important to note that Visual Studio is a COMPLETELY DIFFERENT product from Visual Studio Code despite sharing the name. It only runs on Windows and there are multiple SKUs. One of the SKUs is free (Community Edition…CE) but still very powerful. The others are not free (and in fact, quite expensive) but give you increasingly powerful features.

One fact about ALL of the SKUs (including CE) is that they all support the use of Xamarin, a powerful tool for creating cross-platform mobile application with code-sharing even when targeting iOS and Android.

Microsoft also very recently released a new IDE, Visual Studio for Mac, but I know very little about it except to say it is an excellent choice for doing cross-platform Xamarin development. (Compiling iOS apps with Xamarin requires a Mac. And you can still use your Mac to do Android development).

IDEs offer a huge number of features to support software development but are NOT lightweight. The IDE loads slow, and opening projects tend to be slow, too. But once loaded, you get a ton of features to aid your development (Intelligence, Code Completion, Refactoring, Snippets, Project Templates, Solution Templates, Database integration, builds, deployments, and extensibility to make it even more powerful with third party plug-ins, called extensions.

3.3.2 Evaluate the use of the Visual Studio IDE

IDE Basics

The following image shows the Visual Studio IDE with an open project, and the Solution Explorer window for navigating in the project files, and the Team Explorer window for navigating source control and work item tracking. The features in the title bar that are called out are explained below in more detail.

Figure 40 Editor visual studio ide

Solution Explorer lets you view, navigate, and manage your code files. Solution Explorer can help organize your code by grouping the files into solutions and projects.

The editor window, where you'll likely spend a majority of your time, shows your code and enables you to edit source code and design a UI.

The Output window is where Visual Studio sends its notifications, such as debugging and error messages, compiler warnings, publishing status messages, and more. Each message source has its own tab.

Team Explorer (VSTS) lets you track work items and share code with others using version control technologies such as Git and Team Foundation Version Control (TFVC).

Designing the user interface

A designer is an intuitive tool that enables you to create a user interface without writing code. You can drag UI controls such as list boxes, calendars, and buttons from the Toolbox window onto a design surface that represents the window or dialog box. You can resize and rearrange the elements without writing any code. Designers are included for any project type that has a user interface.

If your project has a XAML-based user interface, the default designer is Blend for Visual Studio, a sophisticated graphics tool that works seamlessly with Visual Studio.

Figure 41 visual studio ide user interface

Writing, navigating and understanding code

If you are a developer, the editor window is where you will probably spend most of your time. Visual Studio includes editors for C#, C++, Visual Basic, JavaScript, XML, HTML, CSS, and F#, and third parties offer plug-in editors (and compilers) for many other languages.

You can edit individual files in the text editor by clicking File | Open | File. To edit files in an open project, click on the file name in Solution Explorer. The code is colorized, and you can personalize the color scheme by typing “Colors” in Quick Launch. You can have lots of text editor tabbed windows open at once. You can split each window independently. You can also run the text editor in full-screen mode.

Figure 42 The text editor for C#

The text editor is highly interactive (if you want it to be) with many productivity features that help you write better code faster. The features vary by language, and you don’t have to use any of them (Type "Editor" in Quick Launch) to turn features on or off: Some of the common productivity features are:

Refactoring includes operations such as intelligent renaming of variables, moving selected lines of code into a separate function, moving code to other locations, reordering function parameters, and more.

IntelliSense is an umbrella term for a set of popular features that display type information about your code directly in the editor and, in some cases, write small bits of code for you. It’s like having basic documentation inline in the editor, which saves you from having to look up type information in a separate help window. IntelliSense features vary by language. For more information, see Visual C# IntelliSense, Visual C++ Intelligence, JavaScript IntelliSense, Visual Basic-Specific IntelliSense. The following illustration shows some IntelliSense features at work:

Figure 43 IntelliSense C#

Squiggles alert you to errors or potential problems in your code in real time as you type, which enables you to fix them immediately without waiting for the error to be discovered during compilation or run time. If you hover over the squiggle, you see additional information about the error. A light bulb may also appear in the left margin with suggestions for how to fix the error. For more information, see Perform quick actions with light bulbs.

Figure 44 Squiggles C#

Bookmarks enable you to navigate quickly to specific lines in files that you are actively working on.

The Call Hierarchy window can be invoked in the text editor context menu to show the methods that call, and are called by, the method under the carpet.

Code Lens enables you to find references and changes to your code, linked bugs, work items, code reviews, and unit tests, all without leaving the editor. For more information, see Find code changes and other history.

The Peek to Definition window shows a method or type definition inline, without navigating away from your current context. This window now works for XAML, too.

Figure 45C# Edit menu

Most of the items on the Edit menu and View menu relate to the code editor in some way. For more information about the editor, see Writing Code and Editing Your Code.

Compiling and building your code

To build a project means to compile the source code and perform whatever steps are necessary to produce the executable. Different languages have different build operations, and regular websites don't build at all. Regardless of the project type, the Build menu is the standard location for these commands. To compile and run your code with a single keystroke, press F5. Every compiler is completely configurable through the IDE. The Build toolbar enables you to specify whether to build a debug version of your program, with symbols and extra error checking enabled to support breakpoints and single stepping in the debugger, or a release build, which is what you will ultimately give to customers. You can configure more build settings and many other settings on the property page for a project. Right-click on the project node in Solution Explorer and choose Properties. You can also run builds from the command line.

Figure 46 building code

Debugging your code

Visual Studio’s state-of-the-art debugger enables you to debug code running in your local project, on a remote device, or on an emulator such as the ones for Android or Windows Phone. You can step through code one statement at a time and inspect variables as you go, you can step through multi-threaded applications, and you can set breakpoints that are only hit when a specified condition is true. All of this can be configured in the code editor itself, so that you don't have to leave the context of your code.

Figure 47 Debugging code

The debugger itself has multiple windows that enable you to view and manipulate local variables, the call stack, and other aspects of the runtime environment. You can find these windows on the Debug menu.

The Immediate Window enables you to type in an expression and see its result immediately.

The IntelliTrace window records each method call and other events in a running .NET program and can help you to quickly locate where a problem originates.

For more information, see Debugging in Visual Studio.

Testing your code

Visual Studio includes a unit test framework for managed code (.NET) and one for native C++. To create unit tests, simply add a Test Project to your solution, write your tests, and then run them from the Test Explorer window. For more information, see Unit Test Your Code.

Figure 48 Testing code

Analyzing code quality and performance

Visual Studio includes powerful tools for static and runtime analysis. The static analysis tools help you identify potential Performance testing, or profiling, involves measuring how your program runs. You access these tools from the Analyze menu. For more information, see Tools. Errors in design, globalization, interoperability, performance, security, and other categories.

Connecting to cloud services and databases

The Server Explorer window in Visual Studio shows the resources in all the accounts managed under your personalization account (the one you logged in with), including SQL Server instances, Azure, Salesforce.com, Office 365, and websites.

Figure 49 SQL Server Data Tool IN C#

Visual Studio includes Microsoft SQL Server Data Tools (SSDT), which enable you to build, debug, maintain, and refactor databases. You can work with a database project, or directly with a connected database instance on- or off-premises.

The SQL Server Object Explorer in Visual Studio offers a view of your database objects similar to SQL Server Management Studio. SQL Server Object Explorer allows you to do light-duty database administration and design work, including editing table data, comparing schemas, and executing queries by using contextual menus right from the SQL Server Object Explorer. SSDT also includes special project types and tools for developing SQL Server 2012 Analysis Services, Reporting Services, and Integration Services Business Intelligence (BI) solutions (formerly known as Business Intelligence Development Studio).

Figure 50 SQL Server Object Explorer in Visual Studio

Deploying your finished application

When your application is ready to deploy to customers, Visual Studio provides the tools to do that, whether you’re deploying to the Windows Store, to a SharePoint site, or with InstallShield or Windows Installer technologies. It's all accessible via the IDE. For more information, see Deploying Applications, Services, and Components.

Architecture and modeling tools (Enterprise only)

You can use Visual Studio architecture and modeling tools to design and model your app. These tools help you to visualize the code's structure, behavior, and relationships. You can create models at different levels of detail throughout the application lifecycle as part of your development process. You can track requirements, tasks, test cases, bugs, and other work associated with your models by linking model elements to Team Foundation Server work items and your development plan. For more information, see Design and model your app.

Visual Studio creates the project. It's a simple "Hello World" application that calls the Console. WriteLine ()method to display the literal string "Hello World!" in the console window

Figure 51 Visual Studio creates the project

Task 4: Determine the debugging process and explain the importance of a coding standard (LO4).

Design and build a complete system for the vehicle reservation and billing for Ayubo drive. This includes the completing the database design started in 3.2 and designing the suitable interfaces for vehicle and package additions and reservation handling and customer billing

4.1 What is debugging an application? Explain the importance of the debugging facility in Visual studio IDE. Debug your source code by putting few debugging points in your application.

4.1.1 Debugging

Debugging, in computer programming and engineering, is a multistep process that involves identifying a problem, isolating the source of the problem, and then either correcting the problem or determining a way to work around it. The final step of debugging is to test the correction or workaround and make sure it works.

Developing software programs undergo heavy testing, updating, troubleshooting and maintenance. Normally, software contains errors and bugs, which are routinely removed. In the debugging process, complete software programs are regularly compiled and executed to identify and rectify issues. Large software programs, which contain millions of source code lines, are divided into small components. For efficiency, each component is debugged separately at first, followed by the program as a whole.

Debuggers can help me do ad hoc inspection or alteration of variables, code, or any other aspect of the runtime environment, whereas manual debugging requires me to stop, edit, and re-execute the application (possibly requiring recompilation).

Debuggers can attach to a running process or use a crash dump, whereas with manual debugging,

"steps to reproduce" a defect are necessary.

Debuggers can display complex data structures, multi-threaded environments, or full runtime stacks easily and in a more readable manner.

Debuggers offer many ways to reduce the time and repetitive work to do almost any debugging tasks.

Visual debuggers and console debuggers are both useful and have many features in common.

A visual debugger integrated into an IDE also gives you convenient access to smart editing and all the other features of the IDE, in a single integrated development environment (hence the name).

One of the key features of Visual Studio Code is its great debugging support. VS Code's built-in debugger helps accelerate your edit, compile and debug loop.

In addition to debugging a program, VS Code supports running the program. The Debug: Start Without Debugging action is triggered with Ctrl+F5 and uses the currently selected launch configuration. Many of the launch configuration attributes are supported in 'Run' mode. VS Code maintains a debug session while the program is running and pressing the Stop button terminates the program.

Tip: The Run action is always available, but not all debugger extensions support 'Run'. In this case 'Run' will be the same as 'Debug'.

Breakpoints can be toggled by clicking on the editor margin. Finer breakpoint control (enable/disable/reapply) can be done in the Debug view's BREAKPOINTS section.

Breakpoints in the editor margin are normally shown as red filled circles.

Disabled breakpoints have a filled gray circle.

When a debugging session starts, breakpoints that cannot be registered with the debugger change to a gray hollow circle. The same might happen if the source is edited while a debug session without live-edit support is running.

The Reapply All Breakpoints command sets all breakpoints again to their original location. This is helpful if your debug environment is "lazy" and "misplaces" breakpoints in source code that has not yet been executed.

Log points

A Log point is a variant of a breakpoint that does not "break" into the debugger but instead logs a message to the console. Log points are especially useful for injecting logging while debugging production servers which cannot be stopped.

A Log point is represented by a "diamond" shaped icon. Log messages are plain text but can include expressions to be evaluated within curly braces ('{}').

Debuggers can help me do ad hoc inspection or alteration of variables, code, or any other aspect of the runtime environment, whereas manual debugging requires me to stop, edit, and re-execute the application (possibly requiring recompilation).

Debuggers can attach to a running process or use a crash dump, whereas with manual debugging, "steps to reproduce" a defect are necessary.

Debuggers can display complex data structures, multi-threaded environments, or full runtime stacks easily and in a more readable manner.

Debuggers offer many ways to reduce the time and repetitive work to do almost any debugging tasks.

Visual debuggers and console debuggers are both useful, and have many features in common.

A visual debugger integrated into an IDE also gives you convenient access to smart editing and all the other features of the IDE, in a single integrated development environment (hence the name).

The Visual Studio debugger helps you observe the run-time behavior of your program and find problems. The debugger works with all Visual Studio programming languages and their associated libraries. With the debugger, you can break execution of your program to examine your code, examine and edit variables, view registers, see the instructions created from your source code, and view the memory space used by your application.

For a quick introduction to debugging and diagnostics in Visual Studio, see Debug, Profile, and Diagnose.

What’s New for the Debugger in Visual Studio 2015 Describes new functionality in Visual Studio 2015.

Windows Lists the different debugger windows.

Debugger Basics Discusses the fundamentals of using the Visual Studio debugger. Topics include debugging basics, execution control, attaching to a running program, Just-In-Time debugging, launching the debugger automatically, dumps, breakpoints, inspecting your program, handling exceptions, Edit and Continue, and using expressions in the debugger.

Features Describes different debugging features.

Remote Debugging Describes how to set up and use remote debugging.

Debug Multithreaded Applications Describes how to debug multithreaded applications.

IntelliTrace Describes the IntelliTrace feature.

Debugging Applications Describes how to debug different kinds of applications.

Debugging User Interface Reference Provides reference information on the windows and dialog boxes you use when debugging your application. These topics are also available when you press F1 while you have focus on a debugging user interface element, such as the Breakpointswindow.

Debug Interface Access SDK Describes the Microsoft Debug Interface Access Software Development Kit (DIA SDK). The DIA SDK provides access to debug information stored in program database (.pdb) files generated by Microsoft post compiler tools.

Example of debugging

Figure 52 debugging coding

4.2 Implement the above functionalities using the IDE while adopting the coding standards to improve maintainability of the code. Explain the coding standards used in your code in the written report

Native Datatype

Always use native datatype instead of .NET CTS type. For example, use int instead of Int32 or Int64.

Example

{`//Good `}

private int _salary = 100;

{`//Bad`}

private Int16 _salary = 100;

private Int32 _salary=100;

Class

Always use Pascal Case for class names. Try to use noun or noun phrase for class name.

Methods

Always use Pascal Case for method names. Use maximum 7 parameter for a method.

public string Get Posts (string post Id)

1. publicstring Get Posts (string post Id)
2. {
3. {`//...`}
4. }

Note: Don't use name as all character in CAPS.

Arguments and Local Variable

Always use camelCase with method arguments and local variables. Don't use Hungarian notation for variables.

1. public string Get Posts (string post Id
2. {
3. int number Of Post = 0;
4. }

Note: Don't use abbreviations for any words and don't use underscore (_) in between any name.
Property
Use Pascal Case for property. Never use Get and Set as prefix with property name.

1. private int _salary = 100;
2. public int Salary
3. {
4. get
5. {
6. return _salary;
7. }
8. set
9. {
10. _salary = value;
11. }
12. }

Note: Don't use name with start with numeric character.

Interface
Always use letter "I" as prefix with name of interface. After letter I, use Pascal Case.

1. publicinterface I User
2. {
3. {`/// <summary>`}
4. {`/// Check user is existing or not`}
5. {`///`} </summary>
6. {`///`} <returns>return bool value</returns>
7. bool Validate User ();
8. }

Private Member Variable

Always try to use camelCase terminology prefix with underscore (_).

private int _salary = 100;

Public Member Variable

Always use Pascal Case for public member variable,

public int Salary = 100;

Member variable

Declare member variable at the top of the class, if class has static member then it will come at the top most and after that other member variable.

1. publicclass Account
2. {
3. public static string Bank Name;
4. public static decimal Reserves;
5. public string Number
6. {
7. get;
8. set;
9. } 00A0
10. publicDate Time Date Opened
11. {
12. get;
13. set;
14. }
15. publicDate Time Date Closed
16. {
17. get;
18. set;
19. }
20. publicdecimal Balance
21. {
22. get;
23. set;
24. }
25. {`// Constructor`}
26. publicAccount ()
27. {
28. {`// ...`}
29. }
30. }

Enum
Always usesingular noun to define enum.

1. enum Mail Type
2. {
3. Html,
4. Plaintext,
5. Attachment
6. }

Namespace

Always use Pascal Case for namespace.

namespace Next Programming Domain

Standard Abbreviation for Standard Controls.

Table 6 meaning full name for coding

4.3 Evaluate how you used the debugging process to develop more secure, robust application with examples

4.3.1 Debugger Security

The ability to debug another process gives you extremely broad powers that you would not otherwise have, especially when debugging remotely. A malicious debugger could inflict widespread damage on the machine being debugged.

However, many developers do not realize that the security threat can also flow in the opposite direction. It is possible for malicious code in the debuggee process to jeopardize the security of the debugging machine: there are a number of security exploits that must be guarded against.

There is an implicit trust relationship between the code you are debugging, and the debugger. If you are willing to debug something, you should also be willing to run it. The bottom line is that you must be able to trust what you are debugging. If you cannot trust it, then you should not debug it, or you should debug it from a machine that you can afford to jeopardize, and in an isolated environment.

In order to reduce the potential attack surface, debugging should be disabled on production machines. For the same reason, debugging should never be enabled indefinitely.

Local debugging is generally safer than remote debugging. Remote debugging increases the total surface area that can be probed.

The Visual Studio Remote Debugging Monitor (msvsmon.exe) is used in remote debugging, and there are several security recommendations for configuring it. The preferred way to configure the authentication mode is Windows Authentication, because No Authentication mode is insecure.

Figure 53 C# debugging monitor

When using Windows Authentication mode, be aware that granting an untrusted user permission to connect to msvsmon is dangerous, because the user is granted all your permissions on the computer.

Do not debug an unknown process on a remote machine: there are potential exploits that might affect the machine running the debugger, or that might compromise msvsmon.exe, the Visual Studio Remote Debugging Monitor. If you absolutely must debug an unknown process, try debugging locally, and use a firewall to keep any potential threats localized.

4.3.2 The debugging processes

In software development, debugging involves locating and correcting code errors in a computer program. Debugging is part of the testing process and is an integral part of the entire software development lifecycle. The debugging process starts as soon as code is written and continues in successive stages as code is combined with other units of programming to form a software product. In a large program that has thousands and thousands of lines of code, the debugging process can be made easier by using strategies such as unit tests, code reviews and pair programming.

Once an error has been identified, it is necessary to actually find the error in the code. At this point, it can be useful to look at the code's logging and use a stand-alone debugger tool or the debugging component of an integrated development environment (IDE). Invariably, the bugs in the functions that get most use are found and fixed first. In some cases, the module that presents the problem is obvious, while the line of code itself is not. In that case, unit tests -- such as JUnit and unit, which allow the programmer to run a specific function with specific inputs -- can be helpful in debugging.

The standard practice is to set up a "breakpoint" and run the program until that breakpoint, at which time program execution stops. The debugging component of an IDE typically provides the programmer with the capability to view memory and see variables, run the program to the next breakpoint, execute just the next line of code, and, in some cases, change the value of variables or even change the contents of the line of code about to be executed.

4.3.3 Common debugging tools

Source code analyzers, which include security, common code errors and complexity analyzers, can also be helpful in debugging. A complexity analyzer can find modules that are so intricate as to be hard to understand and test. Some tools can actually analyze a test run to see what lines of code were not executed, which can aid in debugging. Other debugging tools include advanced logging and simulators that allow the programmer to model how an app on a mobile device will display and behave.

Finding and removing

software errors.

Some tools, especially open source tools and scripting languages, do not run in an IDE and require a more manual approach to debugging. Such techniques include dropping values to a log, extensive "print" statements added during code execution or hard-coded "wait" commands that simulate a breakpoint by waiting for keyboard input at specific times.

The use of the word bug as a synonym for error originated in engineering. The term's application to computing and the inspiration for using the word debugging as a synonym for troubleshooting has been attributed to Admiral Grace Hopper, a pioneer in computer programming, who was also known for her dry sense of humor. When an actual bug (a moth) got caught between electrical relays and caused a problem in the U.S. Navy's first computer, Admiral Hopper and her team "debugged" the computer and saved the moth. It now resides in the Smithsonian Museum

4.3.4 robust application

The word robust, when used with regard to computer software, refers to an operating system or other program that performs well not only under ordinary conditions but also under unusual conditions that stress its designers' assumptions.

Software is typically buggy (i.e., contains errors) and fragile, and thus not robust. This is in large part because programs are usually too big and too complicated for a single human mind to comprehend in their entirety, and thus it is difficult for their developers to be able to discover and eliminate all the errors, or to even be certain as to what extent of errors exist. This is especially true with regard to subtle errors that only make their presence known in unusual circumstances.

A major feature of Unix-like operating systems is their robustness. That is, they can operate for prolonged periods (sometimes years) without crashing (i.e., stopping operating) or requiring rebooting (i.e., restarting). And although individual application programs sometimes crash, they almost always do so without affecting other programs or the operating system itself.

Robustness is something that should be designed into software from the ground up; it is not something that can be successfully tacked on at a later date. The lack of advance planning for robustness is a major factor in the numerous security and stability problems that plague some non-Unix-like operating systems.

The Rule of Robustness in the Unix philosophy states that robustness results from transparency and simplicity. Software is transparent when a skilled programmer can examine its source code (i.e., the original version written by a human in a programming language) and soon comprehend how it works. It is simple when its operation is sufficiently uncomplicated that a programmer can visualize with little effort all of the potential situations that it might encounter. The more that programs have both of these qualities, the more robust they will be.

Another important tactic for creating robust software is to write general code that can accommodate a wide range of situations and thereby avoid having to insert extra code into it just to handle special cases. This is because code added just to accommodate special cases is often buggier than other code, and stability problems can become particularly frequent and/or severe from the interactions among several such sections of code.

Linux and other open source software, i.e., software for which the source code is freely available, has a major advantage over closed source software, i.e., software for which the source code is secret (as is the case for most commercial, or proprietary, software) as far as robustness is concerned. It is that the source code can be reviewed by a large number of highly diverse programmers at their leisure via the Internet, and thus it is easier to find and correct errors than when the code is reviewed only by in-house programmers who are often under pressure from deadlines and who might not have strong incentives to find and eliminate all the bugs.

Applying the Unix Philosophy's Rule of Composition (i.e., to design programs so that they can be connected to other programs) also helps result in robust software. This is because it leads to small, modular programs that are easier to comprehend and to correct than are larger ones that attempt to do many things. It is also because input received from other programs (as contrasted to that from humans) can be particularly effective for stress-testing software and thus for helping to provide tolerance for unusual and large inputs.

The robustness of Unix-like operating systems is also the result of several additional deliberate design concepts. One, which has been adopted increasingly by other operating systems as well, is the providing of each application program with its own area of memory and preventing it from interfering with the memory areas for other applications or the kernel (i.e., the core of the operating system).

Another is the system of permissions that are required for accessing all objects (i.e., files and directories) on the system. This system, when administered correctly, can make it difficult for sloppy or malicious (e.g., viruses, worms and trojans) code to affect key parts of the system.

Robust programming, also called bomb-proof programming, is a style of programming that prevents abnormal termination or unexpected actions. Basically, it requires code to handle bad (invalid or absurd) inputs in a reasonable way. If an internal error occurs, the program or library terminates gracefully, and provides enough information so the programmer can debug the program or routine.

This handout discusses the principles of bomb-proof coding, and gives you a detailed example of how to do it right. Our example is library for managing queues (FIFO lists) of numbers. This allows the example to consider parameters and global variables. The principles apply to programs, also; specifically, input and parameters are equivalent, and the environment is like global variables.

Principles of Robust Programming

A robust program differs from a non-robust, or fragile, program by its adherence to the following four principles:

Paranoia. Don't trust anything you don't generate! Whenever someone uses your program or library routine, assume they will try to break it. When you call another function, check that it succeeds. Most importantly, assume that your own code will have problems, and program defensively, so those problems can be detected as quickly as possible.

Stupidity. Assume that the caller or user is an idiot, and cannot read any manual pages or documentation. Program so that the code you write will handle incorrect, bogus, and malformed inputs and parameters in a reasonable fashion, "reasonable" being defined by the environment. For example, if you print an error message, the message should be self-explanatory and not require the user to look up error codes in a manual. If you return an error code to the caller (for example, from a library routine) make the error codes unambiguous and detailed. Also, as soon as you detect the problem, take corrective action (or stop). This keeps the error from propagating.

Part of the problem is that in a week, you most likely will have forgotten the details of your program, and may call it incorrectly or give it bogus input. This programming style is also a form of defensive programming.

Dangerous Implements. A "dangerous implement" is anything that your routines expect to remain consistent across calls. For example, in the standard I/O library, the contents of the FILE structure for allocated files is expected to remain fixed across calls to the standard I/O library. That makes it a "dangerous implement." Don't let users gain access to these! They might accidentally (or deliberately) modify the data in that data structure, causing your library functions to fail - badly. Never return pointers or indices into arrays; always hide the true addresses (or indices) by using something called a "token."

Hiding data structures also makes your program or library more modular. For example, the queue manager uses arrays to represent queues. This gives them a maximum size. You might decide that linked lists would be more suitable and want to rewrite the routines. If you have properly designed the interface and hidden as much information and data as possible, the calling program need not be changed; however, if you neglected this style of information hiding and information abstraction, programs that correctly function with the current representation might break if you changed that representation (because the caller assumed that the queue elements are in sequential integer locations, for example).

Can't happen. As the old saw goes, "never say `never.'" Impossible cases are rarely that; most often, they are merely highly unlikely. Think about how those cases should be handled, and implement that type of handling. In the worst case, check for what you think is impossible, and print an error message if it occurs. After all, if you modify the code repeatedly, it is very likely that one modification will affect other parts of the code and cause inconsistent effects, which may lead to "impossible" cases occurring.

4.3.5 Example of a Robust application

The queue structure is to be unavailable to the caller, so we need to define two items: the structure itself, and an interface to it. We deal with the interface first. The object that the caller uses to represent a queue will be called a token.

In addition, we must prevent a "dangling reference" problem (in which a program references queue A after that queue is deleted). Suppose a programmer uses the library to create queue A. Queue A is subsequently deleted and queue B created; queue B happens to occupy the same slot in the array of queues as queue A did. A subsequent reference to queue A by token will get queue B. To avoid this problem, we associate with each queue a unique integer (called a nonce) and merge this into the token. In the above example, queue might have nonce 124 and queue B might have nonce 3086. The token for queue A is f (7, 124) and the token for queue B is f(7, 3085). As these values differ, the reference to queue A will be detected and rejected.

We choose as our function the following:

f (index, nonce) = ((index + 0x1221) <<16) | (nonce + 0x0502)

where << and | are the usual C operators. We emphasize, however, that any function invertible in either argument is acceptable. In the above,

index = (f (index, nonce) >> 16) & 0xffff

and

nonce = f (index, nonce) & 0xffff

where & and >> are the usual C operators.

This simplifies the interface considerably, but at the cost of assuming a 32-bit quantity (or greater). Fortunately, most systems have a datatype supporting integers of this length. So, in the header file, we put:

{`/* queue identifier; contains internal index and nonce mashed together */`}

typedef long int qticket;

With this token defined, calling routines need know nothing about the internal structures.

Don't hand out pointers to internal data structures; use tokens instead.

The second issue is errors; how to handle them? We can print error messages (and take action, possibly even terminating), we can return error results and allow the caller to handle the error, or we can set up special error handlers (if the language supports these; they are typically written as trap or exception handlers). Unfortunately, C does not provide exception handlers for errors. The method of returning error codes to the caller allows much greater flexibility than handling the error in the routine, and is equally simple to perform. The complication is that a set of error codes must indicate the errors that could occur. So, as we proceed through our library, we shall track errors and define error codes.

Examples

{`/* * error return values * all the queue manipulation functions return these; * you can interpret them yourself, or print the error * message in qe_errbuf, which describes these codes */#define QE_ISERROR(x) ((x) < 0) /* true if x is a qlib error code */#define QE_NONE 0 /* no errors *//* * the error buffer; contains a message describing the last queue * error (but is NUL if no error encountered); not cleared on success */extern char qe_errbuf [256];`}

Like the UNIX system variable errno(3), qe_errbuf is set on an error but not cleared on success. The buffer will contain additional information (such as in which routine the error occurred and relevant numbers). The following macros aid this process:

{`/* macros to fill qe_errbuf */#define ERRBUF (str) (void) strncpy (qe_errbuf, str, size of(qe_errbuf))#define ERRBUF2(str, n) (void) sprintf(qe_errbuf, str, n)#define ERRBUF3(str, n, m) (void) sprintf(qe_errbuf, str, n, m)`}

These are defined in qlib.c because they format messages placed in qe_errbuf; the functions that call the library have no use for them.

4.4 Explain the coding standards you have used in your application development. Critically evaluate why a coding standard is necessary in a team as well as for the individual.

4.4.1 Definition of coding stranded

Coding standards define a programming style. A coding standard does not usually concern itself with wrong or right in a more abstract sense. It is simply a set of rules and guidelines for the formatting of source code.

Coding standards, sometimes referred to as programming styles or coding conventions, are a very important asset to programmers. Unfortunately, they are often overlooked by junior as well as some program developers due to the fact that many of the recommended coding standards do not actually affect the compilation of the code itself, a concept that we will focus on later. This report shall try to demonstrate the importance of coding standards, and why they have already become a common practice for businesses and programming language developers alike.

I shall begin with a definition of coding standards. In general they are a set of standards and guidelines which are/should be used when writing the source code for a program. Standards are rules which a developer is expected to follow. However these rules, such as “the compiled file must have the extension .h” are often apparent are followed anyway. Guidelines however are much less well followed. They are stylistic measures which have no direct affect on the compilation of the guide, and exist only to make the source code more humanly readable. They are optional, but highly recommended.

An important thing to remember about coding standards that many programmers seem to forget is that coding standards are not an abstract idea. In fact, for many companies and practically all programming languages, a coding standard is a physical document, and is vital for producing uniform code.

Coding standards vary in importance between companies and programming languages. For the COBOL programmer for example, commenting code (an area of coding standards which will be explained later) would be significantly less important than in other languages, as it is possible to make COBOL self-documenting. It also may not be important for a company that is not going to be continually producing software and it may be more time consuming than just building the software without. However, in open source software, the importance of coding standards cannot be emphasized enough. The most prominent example of this is Mozilla Firefox, the open source internet browser which makes all its code freely available online. This is so other developers can look over the source code, possibly identifying possible security flaws/bugs in the code as well as extending the code. It would be extremely difficult for other developers to identify potential flaws in the program if it did not follow a particular style convention. Also, Firefox has a huge database of extensions, some of which it created itself but many of which were created by external developers. External extensions would be very difficult to understand and integrate into Firefox if they did not follow a coding standard, and Firefox may not have been such a popular internet browser as it is today.

Coding standards, when implemented correctly, can provide huge advantages to the produced code and the companies implementing them. They can make a great difference when maintaining software. Maintenance is arguably the most important step in the Software Development Life Cycle (SDLC) and is definitely the most recurring. When the developers who are responsible for maintaining the code are different from the ones who produced it, it relies on them understanding code developed by another developer. With the lack of a coding standard, this task would be extremely different because the majority of programmers have their own programming style which is often difficult to follow by anyone with the exception of the original developer. Having a coding standard however, means that all software programmers will be easily able to read and understand all the code for a program, as long as it conforms to the coding standard and the developer who is maintaining the code is familiar with it, making it easily maintained and modify if needed.

Software that complies with a pre-existing coding standard has also been proven to contain fewer bugs and generally be of a higher quality. This is because the software is much easier to test, and any potential errors or problems with the code can be fixed in the development process of the program. Since the cost of fixing a bug in a program increases exponentially over time it is important to catch such bugs in the early development process to save money. This is, however, not the only way having a coding standard can save money for a company. Having a pre-existing coding standard that the developers are already familiar with can speed up the overall software development process, get the product to market faster, possibly making more money for the company. Also, as discussed earlier, software developed to a coding standard contains less bugs which means less time and money has to be spent maintaining the code.

Complying with a coding standard can also have a huge effect on teamwork. Often, programmers learn to program in different ways and have varying, often conflicting programming styles. This can cause conflict within a development team and such conflicts would certainly make the team less efficient. Having a pre-existing coding standard however means that there are no discrepancies as to how the program should be designed. Another way in which teamwork is affected is the ability to team switch i.e. have other programmers working on other projects transfer into other development groups. Having a company-encompassing coding standard means that developers can be switched from different parts of the company and require very little training to begin programming in other teams. This complements critical path analysis, a business technique which identifies the areas of a project which, if delayed, would delay the entire project. If such areas are identified, then developers can be easily assigned to such areas, ensuring the project is finished on time.

There are two main types of coding standards, coding standards written for a company, and coding standards written for a programming language. The company coding standard is what developers are expected to follow within the company, whereas the coding standard for a programming language is what the programming language developers recommend all programmers should follow. Often, both contain a lot of similar points, and for companies that only program in one language, both are often almost identical. However, for companies which develop software in a variety of languages, they often formulate their own coding standard. For example, Mozilla Firefox is written in C++, XUL, XBL, and JavaScript. Instead of inefficiently using the four separate coding standards of each language, Mozilla has created its own coding standard.

Naming Conventions

In short examples that do not include using directives, use namespace qualifications. If you know that a namespace is imported by default in a project, you do not have to fully qualify the names from that namespace. Qualified names can be broken after a dot (.) if they are too long for a single line, as shown in the following example.

You do not have to change the names of objects that were created by using the Visual Studio designer tools to make them fit other guidelines

Layout Conventions

Good layout uses formatting to emphasize the structure of your code and to make the code easier to read. Microsoft examples and samples conform to the following conventions:

Use the default Code Editor settings (smart indenting, four-character indents, tabs saved as spaces). For more information, see Options, Text Editor, C#, Formatting.

Write only one statement per line.

Write only one declaration per line.

If continuation lines are not indented automatically, indent them one tab stop (four spaces).

Add at least one blank line between method definitions and property definitions.

Use parentheses to make clauses in an expression apparent, as shown in the following code.

Commenting Conventions

Place the comment on a separate line, not at the end of a line of code.

Begin comment text with an uppercase letter.

End comment text with a period.

Insert one space between the comment delimiter (//) and the comment text, as shown in the following example.

Language Guidelines

The following sections describe practices that the C# team follows to prepare code examples and samples.

String Data Type

Use string interpolation to concatenate short strings, as shown in the following code.

To append strings in loops, especially when you are working with large amounts of text, use a String Builder object.

Implicitly Typed Local Variables

Use implicit typing for local variables when the type of the variable is obvious from the right side of the assignment, or when the precise type is not important. The following example uses implicit typing in a for statement.

Unsigned Data Type

In general, use int rather than unsigned types. The use of int is common throughout C#, and it is easier to interact with other libraries when you use int.

Arrays

Use the concise syntax when you initialize arrays on the declaration line.

Delegates

Use the concise syntax to create instances of a delegate type.

try-catch and using Statements in Exception Handling

Use a try-catch statement for most exception handling.

Simplify your code by using the C# using statement. If you have a try-finally statement in which the only code in the finally block is a call to the Dispose method, use a using statement instead.

&& and || Operators

To avoid exceptions and increase performance by skipping unnecessary comparisons, use && instead of &and || instead of | when you perform comparisons, as shown in the following example.

New Operator

Use the concise form of object instantiation, with implicit typing, as shown in the following declaration.

The previous line is equivalent to the following declaration.

Event Handling

If you are defining an event handler that you do not need to remove later, use a lambda expression.

LINQ Queries

Use meaningful names for query variables.

Use aliases to make sure that property names of anonymous types are correctly capitalized,

Use implicit typing in the declaration of query variables and range variables.

Coding standards are important for many reasons. First and foremost, they specify a common format for the source code and comments. This allows developers to easily share code, and the ideas expressed within the code and comments, between each other. It also specifies how comments (internal documentation) should be handled. More importantly, a well designed standard will also detail how certain code should be written, not just how it looks on screen.

More important than the reasons for having a standard is actually adhering to it consistently. Having a coding standard documented and available means nothing if developers are not using it consistently. If that becomes the case, it is no longer a coding standard, it has become a coding suggestion. Worse yet are the developers that do not have a style or standard at all, and think that their lack of a style/standard IS a coding style/standard!

Reference

Algorithm Definition. 2018. Algorithm Definition. [ONLINE] Available at: https://techterms.com/definition/algorithm. [Accessed 14 August 2018].

Sorting Algorithms – BetterExplained. 2018. Sorting Algorithms – BetterExplained. [ONLINE] Available at: https://betterexplained.com/articles/sorting-algorithms/. [Accessed 14 August 2018].

Sorting Algorithms – BetterExplained. 2018. Sorting Algorithms – BetterExplained. [ONLINE] Available at: https://betterexplained.com/articles/sorting-algorithms/. [Accessed 14 August 2018].

GeeksforGeeks. 2018. Binary Search - GeeksforGeeks. [ONLINE] Available at: https://www.geeksforgeeks.org/binary-search/. [Accessed 14 August 2018].

The Programming Process. 2018. The Programming Process. [ONLINE] Available at: http://www.cs.bham.ac.uk/~rxb/java/intro/2programming.html. [Accessed 14 August 2018].

Big O notation: definition and examples - yourbasic.org. 2018. Big O notation: definition and examples - yourbasic.org. [ONLINE] Available at: https://yourbasic.org/algorithms/big-o-notation-explained/. [Accessed 14 August 2018].

WPShout. 2018. The Three Development Paradigms: Procedural, Object-Oriented, and Functional | WPShout. [ONLINE] Available at: https://wpshout.com/development-paradigms-procedural-object-oriented-functional/. [Accessed 14 August 2018].

SearchSoftwareQuality. 2018. What is integrated development environment (IDE)? - Definition from WhatIs.com. [ONLINE] Available at: https://searchsoftwarequality.techtarget.com/definition/integrated-development-environment. [Accessed 14 August 2018].

ProfitBricks Blog. 2018. Top 48 Integrated Developer Environments (IDEs) & Code Editors | ProfitBricks Blog. [ONLINE] Available at: https://blog.profitbricks.com/top-integrated-developer-environments-ides/. [Accessed 14 August 2018].

Visual Studio IDE. 2018. Visual Studio IDE. [ONLINE] Available at: https://msdn.microsoft.com/en-us/library/dn762121.aspx. [Accessed 14 August 2018].

SearchSoftwareQuality. 2018. What is debugging? - Definition from WhatIs.com. [ONLINE] Available at: https://searchsoftwarequality.techtarget.com/definition/debugging. [Accessed 14 August 2018].

Debugger Security. 2018. Debugger Security. [ONLINE] Available at: https://msdn.microsoft.com/en-us/library/ms242231.aspx. [Accessed 14 August 2018].

Benefits of Coding Standards. 2018. Benefits of Coding Standards. [ONLINE] Available at: https://www.valid-computing.com/benefits-of-coding-standards.html. [Accessed 14 August 2018].

Gant chart