3.5. Paint Pot Refactoring and Procedural Abstraction¶
Time Estimate: 45 minutes
3.5.1. Introduction and Goals¶
|
In this lesson we won’t add new functionality to the Paint Pot app. Instead, we will revise the code, leaving the app’s behavior unchanged. This process is called refactoring and programmers do this to improve the quality of their code in various ways -- e.g., to simplify its design, make it easier to read, and easier to maintain.
In this case we will introduce the concept of a programmer-defined procedure that will help reduce the complexity of our code and make it easier to read and maintain. This is an example of procedural abstraction, a very important concept and practice in programming. |
|
 |
Learning Objectives: I will learn to
Language Objectives: I will be able to
|
3.5.2. Learning Activities¶
Refactoring to Improve Code
Open MIT App Inventor with the Paint Pot Refactor template in a separate tab and follow along with the video tutorial. After the project opens, use the Save As option to rename your project PaintPotWithProcedure.
Procedural Abstraction
In this lesson, we learned how to create procedures in MIT App Inventor to refactor our code and reduce its complexity. Procedural abstraction, the ability to name a block of code in a procedure and call it whenever needed, is a very important concept in programming. We are abstracting away from the details of that block of code and just using its name to do its job. We only need to know what it does, not how it does it.
Procedural abstraction allows modularity where a solution to a large problem can be found by creating procedures to solve each of the subproblems. This modularity serves to organize our code by function and reduce its complexity. In addition, it helps with debugging, code readibility, and maintenance since changes to that block of code only need to happen in one place. Procedural abstraction allows us to reuse code that is already written instead of rewriting the code and repeating it. And it allows programmers to change the internals of the procedure (to make it faster, more efficient, use less storage, etc.) without needing to notify users of the change as long as what the procedure does is preserved. In Unit 5 in Logo part 2, you will learn to make procedures even more powerful and more abstract by adding parameters to the procedure.
In the College Board AP exam and Create Performance Task, you will be asked to identify and use procedural abstraction. The following AP pseudocode is used for procedures compared to MIT App Inventor code:
| AP Text Pseudocode | AP Block Pseudocode | MIT App Inventor Block |
PROCEDURE name()
{
instructions
}
|  |
Documenting Code by Adding Comments
Programmers should document a program throughout its development. That is, a programmer should keep detailed documentation while they are developing a program. An important feature of most programming languages, including MIT App Inventor, is the ability to add comments internally to the code. A comment is a non-executable block of text that can be added to a program to provide clarification and documentation of the code. Adding comments to one’s code is a standard practice that programmers employ to help others (and themselves) understand their code.
In MIT App Inventor, each non-collapsed block comes with the capability of having a comment
added to it. To access this capability you must right-click on the block and choose the
Add Comment option. This will add a small comment icon, a blue circle with a question mark,
to block (as shown here).
To add or edit the comment, simply click on the comment icon and type in your comment, as shown here:
In some programming languages, a form of external documentation may be used, especially if it is not possible to comment directly inside the program code. Some examples of external documentation include using a Google or text document for tracking development, a webpage, or a program index or glossary. MIT App Inventor has external documentation on Built-in Blocks and on Components. It may be helpful to reference these when building your own apps.
A good commenting practice to follow is to provide comments in the following situations.- To document every procedure that you define, as shown in this example here.
- To clarify a complex algorithm that isn’t clearly obvious.
- To acknowledge code segment(s) used in a program that were written by someone else or are from another source. In this case, the acknowledgement should include the origin source and/or the original author’s name.
- To acknowledge code segment(s) created collaboratively.
Debugging
As your programs get larger, you will run across more bugs (errors in your program) and you will have to spend more time debugging the programs to remove the bugs. Debugging takes a lot of time in text-based languages like Java because the programmer needs to type in everything exactly in the right case, with the right spelling, and with the right punctuation. MIT App Inventor removes all syntax errors like this because the code is already written for you in the blocks. You do not need to type in any of the code. However, you can still make other errors that you will need to correct. For example, your code might not do what you want it to do. This is a runtime or semantic error. Here are some debugging tips.- Pretend you are the computer and step through the program line by line and carefully record what happen to see if you can spot the error. This is called tracing the code.
- Put in a Notifier block in the UI and then use Notifier.ShowAlert in the blocks to print out the values of different variables to see what they are as you are running the program. Or you could print out the values of variables in a label in your UI.
- Look for error messages that pop up in the blocks editor or on your screen and for red X's in the code that indicate you have errors there. Test your code on specific test-cases that might cause errors.
- Right click on a get block and choose Do It to see its value while it is running. Watch the video below on Do It and see MIT App Inventor Tips on Debugging.
3.5.3. Summary¶
In this lesson, you learned how to:
3.5.4. Self-Check¶
Vocabulary
Here is a table of the technical terms we've introduced in this lesson. Hover over the terms to review the definitions.
| comment
computer bug debugging |
procedural abstraction
refactoring |
Check Your Understanding
Complete the following self-check exercises.
- Restructuring a program to make it behave differently.
- This will be a challenging concept to learn, but we can all reach this goal. Refactoring does not involve changing a program's basic behavior.
- Changing the way the program behaves.
- This will be a challenging concept to learn, but we can all reach this goal. Refactoring does not involve changing a program's basic behavior.
- Revising a program to remove bugs.
- This will be a challenging concept to learn, but we can all reach this goal. Removing bugs would be called debugging.
- Restructuring a program without changing its basic behavior.
- Right. A good reason to refactor is to provide a better organization to the code or make it more readable or make it more efficient.
Q-2: What does refactoring mean?
3.5.5. Reflection: For Your Portfolio¶
Answer the following portfolio reflection questions as directed by your instructor. Questions are also available in this Google Doc where you may use File/Make a Copy to make your own editable copy.