Download presentation
Presentation is loading. Please wait.
1
Coding Concepts (Standards and Testing)
Topic 2: Programming Coding Concepts (Standards and Testing)
2
Programming Standards
Whenever we program in specific languages, there are always standards we can try and stick to These standards describe What capitalisation to use for variables/functions/classes Where to make curly braces What comments to include We don’t have to adhere to these standards at all However, they do make program code easier to read for other programmers Programming: Coding Concepts (Standards and Testing)
3
Programming Standards: Python
Python is the easiest to understand standards for It has one rule All variable/function names are in lower case, and use underscores between words Programming: Coding Concepts (Standards and Testing)
4
Programming Standards: C#
In C#, we have one key standard for variable/function names Each word in the name starts with a capital letter However, local variables in C# (i.e. ones made in a function) start with a lower-case letter Then use capital letters for every word thereafter Functions in C# skew this standard slightly And always start with a capital letter They call this naming standard CamelCase Programming: Coding Concepts (Standards and Testing)
5
Programming Standards: Java
Java and C# are nearly identical in the standards department The only difference is that both variables and functions in Java use the ‘lower-case first letter’ naming standard Programming: Coding Concepts (Standards and Testing)
6
Programming Standards
Another thing to note about names of functions/variables Try and make their names descriptive Do NOT use i, x, y, and so on for variable names They need to describe, at least a little, what the variable is used for For example, if a variable is being used as the index in an array, use currentIndex/current_index instead of i Programming: Coding Concepts (Standards and Testing)
7
Programming: Coding Concepts (Standards and Testing)
Comments The other thing we can do to make our work more readable and understandable is to add comments Comments can help explain why a certain sequence was used, or what parts of the program do in general Whenever we create a program, we should always comment our work But not over comment it Programming: Coding Concepts (Standards and Testing)
8
Programming: Coding Concepts (Standards and Testing)
Comments First, we need to see how we can add comments In C# and Java, we can include two different types of comment Inline comments (using //) Block comments (using /* to start, and */ to end) We’d use inline comments to explain why certain expressions/sequences were used in a function We’d use block comments to explain what a function/program does Programming: Coding Concepts (Standards and Testing)
9
Programming: Coding Concepts (Standards and Testing)
Comments In Python, we use # for inline comments Also, technically block comments don’t exist in Python If we really want them, we can use multi-line strings Started with “““ and ended with ””” Programming: Coding Concepts (Standards and Testing)
10
Programming: Coding Concepts (Standards and Testing)
Find two programs that you have made previously Add inline/block comments to describe/explain What the program does What certain sequences are doing Why certain values were used Try and make your comments descriptive! Also, change any variable names used if they are not descriptive Programming: Coding Concepts (Standards and Testing)
11
Programming: Coding Concepts (Standards and Testing)
Debugging Programs Programmers are not infallible We very often make mistakes Some small, some big Whenever we make a mistake in a program, one of two errors can happen Syntactical errors: these stop the program from running Also known as compile-time errors Semantic errors: these cause the program to crash/behave oddly while it is running Also known as runtime errors Programming: Coding Concepts (Standards and Testing)
12
Programming: Coding Concepts (Standards and Testing)
Debugging Programs When creating programs, we will need to deal with these issues regularly The easiest one to deal with is the syntactical/compile-time error Depending on the Integrated Development Environment (IDE) we use, we may be shown ‘hints’ of where the error is Usually appear as red underlines Some IDEs even show a hint of the exact problem when we hover over it Programming: Coding Concepts (Standards and Testing)
13
Programming: Coding Concepts (Standards and Testing)
Debugging Programs Whenever we see these, we need to work out what went wrong Common problems are Missing semi-colons (for C# and Java) Incorrect indentation (for Python) Missing/too many brackets The program won’t run unless all these errors are gone Programming: Coding Concepts (Standards and Testing)
14
Programming: Coding Concepts (Standards and Testing)
Debugging Programs Semantic/runtime errors are a little trickier to deal with That’s because they don’t show up as red underlines in the program code The error happens while the program is running There are two ways in which these errors manifest Bugs in the program (meaning the program doesn’t crash) Program crashes (where the program stops completely) Programming: Coding Concepts (Standards and Testing)
15
Programming: Coding Concepts (Standards and Testing)
Debugging Programs Program crashes are a lot easier to deal with Depending on the IDE, a message can appear in the console area This message may include detailed comments on What the error is Where the error happened Programming: Coding Concepts (Standards and Testing)
16
Programming: Coding Concepts (Standards and Testing)
Debugging Programs If the program crashes completely, we should see something called a stack trace This is the stack of current functions being executed We’ll also see the specific runtime error near the top Common ones include StackOverflow, ArrayIndexOutOfBounds, and NullPointer The name of the error usually gives us a hint as to what went wrong ArrayIndexOutOfBounds: we used an index for an array that wasn’t valid StackOverflow: a recursive function is running itself too much NullPointer: we haven’t given a variable a value yet Programming: Coding Concepts (Standards and Testing)
17
Programming: Coding Concepts (Standards and Testing)
Debugging Programs If the program didn’t crash, but behaved oddly, then we have a bug on our hands These are trickier to deal with, as we won’t often be told why the bug is there The best thing to do is work through the program code with a trace table and see if it shows where the error is Programming: Coding Concepts (Standards and Testing)
18
Programming: Coding Concepts (Standards and Testing)
Testing Programs The final thing we should be able to do with our programs is test them We’ve seen testing before Using a trace table If we have the program at hand, we can just run it using different values of input However, when testing programs, we need to test every possible location where input is allowed Not just the start of the program Programming: Coding Concepts (Standards and Testing)
19
Programming: Coding Concepts (Standards and Testing)
Testing Programs When testing programs, we can use three different sets of data Normal Data: the usual, valid data we may input Boundary Data: valid data, but the absolute smallest/highest/most extreme accepted value Erroneous Data: data that is invalid We need to use each type of data when testing programs To ensure the program behaves correctly for each one Programming: Coding Concepts (Standards and Testing)
20
Programming: Coding Concepts (Standards and Testing)
Testing Programs To test the program, we come up with a test plan This plan lists All the possible places where input is accepted The normal, boundary, and erroneous data to test with The expected output of using each piece of data The actual output from using each piece of data The result of the test (e.g. PASS or FAIL) Programming: Coding Concepts (Standards and Testing)
21
Programming: Coding Concepts (Standards and Testing)
Testing Programs This test plan can be written in a table form Like the example below Program asks user if they would like to play another game Test Data Input Value Expected Outcome Actual Outcome Result When asking user if they want to play another game Normal “yes” Program continues FAIL Boundary “no” Program stops Erroneous “25” Asks question again Programming: Coding Concepts (Standards and Testing)
22
Programming: Coding Concepts (Standards and Testing)
Create a test plan for the programs you commented earlier Find every possible place where input is accepted Come up with a test for all types of data Normal, boundary, and erroneous Make sure to state the expected outcome and the actual outcome as well Programming: Coding Concepts (Standards and Testing)
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.