Implementing modular programming is essential in developing efficient, maintainable, and scalable software solutions across all professional fields. In Kenya's diverse sectors such as healthcare, education, finance, and agriculture, structured programming enhances code clarity and facilitates collaboration among teams. This chapter focuses on the creation and management of subroutines, a cornerstone of modular programming, enabling developers to break down complex problems into manageable components that align with user needs and organizational goals.

4.1 Creation of Subroutines

A subroutine is a named, self-contained block of code that performs one specific task and can be called from any point in a program. Creating subroutines lets a programmer split a large problem into small modules, reuse tested code, and find faults quickly. In this unit the examples are written in C, but the same ideas apply to any structured language: for instance, a stock-control program for a hardware shop may have separate subroutines to add stock, price an item and print a receipt.

4.1.1 Benefits of using subroutines (e.g., modularity, reusability)

Subroutines improve the quality of software and the productivity of the people who write it. A program built from well-named subroutines is shorter, easier to read and easier to change than one long block of statements.

Modularity

Modularity means dividing a program into separate modules, each handling one distinct function. The programmer can design, write and test one module at a time. For example, a hotel booking program may use separate subroutines for checking room availability, calculating the bill and printing a confirmation, so each can be developed independently.

Reusability

A subroutine is written once and called as many times as needed, in the same program or in other projects. This removes duplicate code and saves development time. A billing subroutine that calculates a line total from a unit price and a quantity can be reused in a point-of-sale program and in a quotation program for the same shop.

Simplified maintenance

When code is modular, an error is isolated inside one subroutine, so it is found and fixed in one place. If the rule for calculating a discount changes, only the discount subroutine is edited and every part of the program that calls it receives the correction. Other subroutines, such as the one that prints receipts, are not touched.

Improved readability and collaboration

Meaningful subroutine names such as calculateDiscount or printReceipt make the main program read almost like a plan of the solution. Several programmers can work on the same project at once, each owning different subroutines, with fewer misunderstandings about who is responsible for what.

Enhanced testing and debugging

Each subroutine can be tested on its own with chosen inputs before it is joined to the rest of the program. In a payroll program, a tax-calculation subroutine can be checked with many salary values before it is used in the full payroll run. Faults are therefore found early, when they are cheapest to correct.

4.1.2 Designing subroutines to meet user needs

Good subroutine design begins with what the user needs the software to do and ends with small, reliable components that deliver it. Each design decision below links a user requirement to a clear piece of code.

Requirement analysis

List the tasks the user needs the software to perform, then give each task to a subroutine. For a hotel management program, the user needs to book rooms, produce bills and record customer feedback, so subroutines such as bookRoom, calculateBill and recordFeedback are identified from those needs.

Clear interface definition

A subroutine must have well-defined inputs (parameters) and outputs (return value). A loan-repayment subroutine for a lending program, for example, states that it needs the loan amount, the monthly rate and the number of months, and that it returns the monthly instalment or an error code.

Single responsibility principle

Each subroutine should do one well-defined task. A records program should have separate subroutines for entering data, retrieving a record and printing a report, instead of one large subroutine that does all three. Small, focused subroutines are easier to name, test and reuse.

Error handling and validation

A subroutine should check its inputs and handle faults gracefully. A withdrawal subroutine in a wallet program should check that the amount is positive and not larger than the balance before it subtracts anything, and should return a clear error code when the check fails.

Documentation and naming conventions

Descriptive names and short comments tell other programmers what a subroutine does and how to call it. In a crop-planning program, a subroutine named calculateFertilizerNeeds shows its purpose, and a comment above it lists the meaning of each parameter and of the value returned.

4.1.3 Functions and subprograms

Functions and subprograms (procedures) are the two forms of subroutine used in structured programming. Both package a task under a name, but they differ in whether they hand a value back to the code that called them. Choosing the right form for each task keeps the program clear.

Functions and procedures compared

A function performs a calculation or operation and returns a value to the calling program, so it can be used inside an expression. For example, an interest function takes principal, rate and time and returns the interest amount. A subprogram, also called a procedure, carries out a task without necessarily returning a value, often changing program state or producing output. A procedure that updates employee records in a payroll program or prints a report is an example. In C, a procedure is written as a function whose return type is void.

4.1.3.1 In built functions

In built functions (library functions) are ready-made subroutines supplied with the programming language and its standard library. The programmer does not write their bodies; they include the correct header file and call them by name. This saves time and gives tested, efficient code, for example sqrt to find a square root or strlen to count the characters in a text.

The example below uses two in built functions in one program:

#include <stdio.h>
#include <math.h>
#include <string.h>

int main(void)
{
    double area = 78.5;
    double radius = sqrt(area / 3.14159);
    char label[] = "Invoice";

    printf("Radius: %.2f\n", radius);
    printf("Length of label: %zu\n", strlen(label));
    return 0;
}

Calculation:

radius = sqrt(area ÷ 3.14159)

radius = sqrt(78.5 ÷ 3.14159) = sqrt(24.9873)

radius = 4.9987, displayed as 5.00

The label "Invoice" has 7 characters, so strlen returns 7. On some systems the maths library must be linked with the option -lm when compiling.

4.1.3.2 User defined functions

A user defined function is a subroutine written by the programmer to solve a task that no in built function covers. It has a return type, a name, a parameter list in brackets and a body in braces. Writing user defined functions turns repeated logic, such as pricing an order line, into a single named unit.

The steps to create and use a user defined function are:

1. Decide the task the function performs and give it a descriptive name, such as lineTotal.
2. Decide the inputs it needs and their data types, for example a unit price (double) and a quantity (int).
3. Decide what it returns and choose the return type, for example double, or void if nothing is returned.
4. Write the function prototype before main so the compiler knows the function exists: double lineTotal(double unitPrice, int quantity);
5. Write the function definition with its body, ending with a return statement when a value is returned.
6. Call the function from main or another function, passing arguments that match the parameters in number, order and type.
7. Test the function with several sets of values and confirm that each result is correct.

#include <stdio.h>

double lineTotal(double unitPrice, int quantity);   /* prototype */

int main(void)
{
    double total = lineTotal(250.0, 4);
    printf("Total: Ksh %.2f\n", total);
    return 0;
}

double lineTotal(double unitPrice, int quantity)    /* definition */
{
    return unitPrice * quantity;
}

Calculation:

total = unit price × quantity

total = 250.00 × 4

total = Ksh 1000.00

4.1.3.2.1 Function parameters

Parameters are the variables listed in a function's brackets that receive the data the function works on. They form the function's input interface, so the calling code and the function agree on what is exchanged. A shop program that updates stock might pass the product code and the quantity sold as parameters.

• Formal parameter: the variable declared in the function definition, such as unitPrice in lineTotal. It exists only inside the function.
• Actual argument: the value or variable supplied by the caller, such as 250.0 in lineTotal(250.0, 4). Its value is copied into the formal parameter.
• Pass by value: a copy of the argument is given to the function, so changes to the parameter do not affect the caller's variable. This is the default in C and is the safest choice.
• Pass by reference: the address of the caller's variable is given (in C, through a pointer), so the function can change the original. It is used when a function must update data or return more than one result.
• Matching rules: arguments must match the parameters in number, order and data type, otherwise the compiler reports an error or the result is wrong.
• Array parameters: an array is passed by giving its name and usually its size; the function works on the original array elements.

#include <stdio.h>

void applyDiscount(double *price, double percent)
{
    *price = *price - (*price * percent / 100.0);
}

int main(void)
{
    double price = 2000.0;
    applyDiscount(&price, 10.0);
    printf("New price: Ksh %.2f\n", price);
    return 0;
}

Calculation:

new price = price − (price × percent ÷ 100)

new price = 2000.00 − (2000.00 × 10 ÷ 100)

new price = 2000.00 − 200.00 = Ksh 1800.00

Because price was passed by reference, the variable in main now holds 1800.00. Had it been passed by value, main would still hold 2000.00.

4.1.3.2.2 Function return types

The return type, written before the function name, states what kind of value the function gives back to the caller. The return statement sends that value back and ends the function. Choosing the correct return type ensures the caller receives the result in a usable form, for example a decimal amount for money or a whole number for a count.

A function can return only one value directly. To give back several results, the programmer passes pointers as parameters or returns a structure. The example below returns a status code that the caller can test:

int isValidQuantity(int quantity)
{
    if (quantity > 0 && quantity <= 1000)
        return 1;     /* valid */
    return 0;         /* invalid */
}

A call such as isValidQuantity(50) returns 1, while isValidQuantity(-3) returns 0. The returned value must match the declared type; a void function must not return a value.

Scope and lifetime of variables

Variables declared inside a function are local: they exist only while the function runs and cannot be seen by other functions. This prevents one function from accidentally changing data that belongs to another, which is important in a program that calculates several students' marks or several customers' bills in turn. A global variable, declared outside all functions, is visible everywhere and should be used sparingly because any function can change it.

4.1.4 Design and implement a subroutine library for common tasks

A subroutine library is a collection of tested subroutines for tasks that many programs need, kept in one place so that every project can use the same code. It improves development speed and consistency because programmers stop rewriting the same validation, formatting and calculation routines. In C, a library is normally made of a header file (.h) holding the declarations and a source file (.c) holding the definitions.

Identifying common tasks

Study the programs being developed and list operations that appear in more than one of them. Data validation, date formatting, percentage calculation, rounding and writing messages to a log file are common examples for a billing program, a booking program and a payroll program alike. Only tasks that are genuinely shared should enter the library.

Standardising subroutine interfaces

Use uniform parameter orders, naming style and return conventions across the library. For instance, every validation function can return 1 for valid and 0 for invalid, and every function can use camelCase names such as isPositive and percentageOf. Programmers then predict how an unfamiliar library subroutine behaves.

Modular implementation and documentation

Each library subroutine should do one job, be tested independently and carry a comment that states its purpose, parameters, return value and an example call. For a hotel booking library, functions for room availability, booking confirmation and cancellation are each documented with a usage example.

Version control and maintenance

Keep the library under version control so every change is recorded and earlier versions can be recovered. A new interest calculation method can be added as a new function while the old one remains for programs that still depend on it. Changes should never alter the behaviour of an existing function without a new version number.

Distribution and access control

Decide who may use the library and who may change it. Programmers may be allowed to read and link the library freely, while only designated team members approve changes, which protects the quality of code that many programs depend on.

Library files and tools

Procedure for building and using the library

1. List the common tasks and decide the name, parameters and return type of each function.
2. Create utils.h with an include guard and a prototype for every function.
3. Create utils.c, include utils.h, and write the definition of each function.
4. Compile the library file on its own to check for errors: gcc -c utils.c
5. Create main.c, add the line #include "utils.h" and call the library functions.
6. Compile and link the program with the library object file: gcc main.c utils.o -o app
7. Run the program with test values and compare the output with the expected results.
8. Record a version number and a short description of the change in the library documentation.

utils.h:

#ifndef UTILS_H
#define UTILS_H

int isPositive(double value);
double percentageOf(double amount, double percent);

#endif

utils.c:

#include "utils.h"

int isPositive(double value)
{
    return value > 0;
}

double percentageOf(double amount, double percent)
{
    return amount * percent / 100.0;
}

main.c:

#include <stdio.h>
#include "utils.h"

int main(void)
{
    double amount = 5000.0;
    if (isPositive(amount))
        printf("16 percent of Ksh %.2f is Ksh %.2f\n", amount, percentageOf(amount, 16.0));
    return 0;
}

Calculation:

result = amount × percent ÷ 100

result = 5000.00 × 16 ÷ 100

result = Ksh 800.00

4.1.5 Program to create subroutines based on given specifications

Writing a subroutine from a specification means turning a written description of inputs, outputs and rules into working, tested code. Following a fixed sequence of activities prevents omissions and keeps the result aligned with what the user asked for.

Understanding specifications

Read the requirements carefully and identify the purpose, the inputs, the outputs and any constraints. A retail business may specify a billing subroutine that calculates a discount from the customer's loyalty status and the purchase amount. Any unclear point must be clarified before coding starts.

Defining the subroutine interface

Choose the name, parameters and return type that match the specification. A subroutine calculating fertiliser dosage for a crop-planning program might accept the soil type and crop variety as parameters and return the quantity in kilograms as a double.

Writing the subroutine code

Implement the logic with suitable selection, calculation and error handling. A tax subroutine might include conditional checks for exemptions before applying a rate. Keep the body short and the variable names meaningful.

Testing and debugging

Run test cases covering valid data, boundary values and invalid data, then compare the actual output with the expected output. An examination-marks subroutine, for example, is tested with a normal mark, the lowest and highest allowed marks, and a negative mark. Any mismatch is traced and corrected.

Integration and documentation

Add the subroutine to the main program, call it with real data and document its purpose, parameters, return value and limits. A booking subroutine in a hotel management program is documented so that other programmers know how to call it.

Optimisation and refactoring

Review the working subroutine for repeated calculations, unclear names and unnecessary complexity, and improve them without changing the result. A loan-approval subroutine that calculates the same value twice can store it in a local variable and use it twice, which makes the code faster and easier to read.

Worked example from a specification

Specification: write a function amountPayable that takes the purchase amount (double) and the membership status (int, 1 for member, 0 for non-member). A member whose purchase is Ksh 5000 or more receives a 5 percent discount. Anyone else pays the full amount. A negative purchase amount returns -1.

double amountPayable(double purchase, int isMember)
{
    if (purchase < 0)
        return -1.0;
    if (isMember && purchase >= 5000.0)
        return purchase - (purchase * 0.05);
    return purchase;
}

Calculation for the first test:

payable = purchase − (purchase × 0.05)

payable = 6000.00 − (6000.00 × 0.05)

payable = 6000.00 − 300.00 = Ksh 5700.00

Chapter Summary

This chapter explored the implementation of modular programming through the creation of subroutines, emphasizing their benefits such as modularity and reusability. It covered how to design subroutines that effectively meet user needs, distinguishing between built-in functions and user-defined functions, and the development of subroutine libraries to handle common programming tasks. The application of data structures was demonstrated in the context of looping through arrays within functions, highlighting the use of various looping control structures including for loops, while loops, and do-while loops. Techniques and tools for debugging programs were examined to equip learners with strategies for identifying and correcting errors. Finally, the process of compiling programs was discussed, including exercises using programs with intentional errors to understand and interpret compiler error messages. This comprehensive approach provides a solid foundation for writing, testing, and maintaining modular, efficient, and error-free code.