Functions, objects and version control ideas

Dez Okafor-Laine has a confession for the cert club. His kiosk check script, which Noor read in lesson 1, started as twenty lines and is now nearly four hundred, and the same block that sends an email appears in it six times, each copy slightly different. Last month he changed the mail server name in five of the copies and missed the sixth. "That is the problem functions solve," Lorna says, "and the reason the script should be in version control, so we can see exactly what changed and when." This lesson covers the ideas that keep code organized as it grows: functions with parameters and return values, objects with properties and methods, and version control. Tech+ asks you to explain what each is for rather than to write them from scratch.

Functions

A function is a named block of code that performs one task and can be used, or called, from anywhere in a program. Instead of copying the email-sending steps six times, Dez can write them once in a function called send_report and call send_report wherever an email is needed. If the mail server changes, he edits one place. Functions make code shorter, easier to read, easier to test and easier to reuse in other programs. Some languages call them procedures, subroutines or methods, depending on the context, but the idea is the same.

Functions usually take inputs and give back a result. The inputs are called parameters when the function is defined and arguments when it is called: in a function defined as late_fee(days_late, daily_rate), days_late and daily_rate are the parameters, and in the call late_fee(4, 0.25), the numbers 4 and 0.25 are the arguments. The result the function hands back is its return value. A function that calculates a late fee returns the fee; a function that checks whether a patron may borrow a laptop returns true or false. Some functions return nothing and simply do something, such as print a receipt.

MAX_FEE = 5.00

def late_fee(days_late, daily_rate):
    """Return the fee for an overdue item, capped at MAX_FEE."""
    if days_late <= 0:
        return 0.0
    fee = days_late * daily_rate
    return min(fee, MAX_FEE)

for days, rate in [(0, 0.25), (4, 0.25), (10, 0.25), (30, 0.50)]:
    print(f"{days} days at {rate:.2f} a day -> fee {late_fee(days, rate):.2f}")

0 days at 0.25 a day -> fee 0.00
4 days at 0.25 a day -> fee 1.00
10 days at 0.25 a day -> fee 2.50
30 days at 0.50 a day -> fee 5.00

Programming languages also come with many built-in functions, and libraries add thousands more. In the example, min is a built-in function that returns the smaller of two values. A spreadsheet's SUM and AVERAGE are functions in the same sense: you pass them arguments, a range of cells, and they return a value. When documentation describes a function, it lists its name, its parameters and their types, and what it returns, which is often called the function's signature. Reading a signature is a practical skill when a vendor's support article says "the export function requires a start date and an end date."

Variables created inside a function usually exist only while the function runs and cannot be seen from outside it; this is called local scope. Variables created outside any function, at the top level of the program, have global scope. Keeping variables local stops one part of a program accidentally changing a value another part depends on, which is another reason long scripts become fragile when everything lives at the top level.

Comments and documentation

The line in quotation marks just under def late_fee is a docstring: a short description built into the function that tools can display when someone uses it. Lines beginning with # in Python, or // in many other languages, are comments, which the computer ignores entirely and which exist only for people. Good comments explain why the code does something, such as "fees are capped by board policy," rather than repeating what each line plainly says. They matter to support staff as much as to programmers, because the comment at the top of an old script is often the only record of what it was meant to do and who to ask about it. Small, well-named functions with a one-line description each are also far easier to test: you can call late_fee with a handful of known inputs and confirm it returns the expected fees, without running the whole program.

Objects and object-oriented programming

Object-oriented programming, often shortened to OOP, organizes code around objects that represent things, such as a library item, a patron or a printer. An object bundles together data about the thing and the actions it can perform. Its data are called properties or attributes: a library item has a title, a barcode, a due date and a status. Its actions are called methods, which are functions that belong to the object: an item can be checked out, renewed or returned. Tech+ treats property and attribute as near-synonyms; some languages distinguish them, but the exam focuses on the idea that objects hold data and behaviour together.

A class is the template from which objects are made, and each object built from it is an instance. The class LibraryItem describes what every item has and can do; the copy of a particular novel at Northgate with barcode 31234000456789 is one instance, and the same title at another branch is a different instance with its own due date. Writing the logic once in a class and creating as many instances as needed is the object-oriented equivalent of writing a function once and calling it many times.

class LibraryItem:
    def __init__(self, title, barcode):
        self.title = title          # properties
        self.barcode = barcode
        self.status = "available"
        self.renewals = 0

    def check_out(self):            # methods
        self.status = "on loan"

    def renew(self, limit=2):
        if self.status != "on loan":
            return "not on loan"
        if self.renewals >= limit:
            return "renewal limit reached"
        self.renewals += 1
        return f"renewed ({self.renewals} of {limit})"

book = LibraryItem("The Northern Shore", "31234000456789")
book.check_out()
for attempt in range(3):
    print(book.title, "->", book.renew())
print("Status:", book.status, "| Renewals used:", book.renewals)

The Northern Shore -> renewed (1 of 2)
The Northern Shore -> renewed (2 of 2)
The Northern Shore -> renewal limit reached
Status: on loan | Renewals used: 2

OOP is often described with a few more terms that appear in study guides. Encapsulation means an object keeps its internal details to itself and other code works with it only through its methods, so the renewal count cannot be changed by accident from somewhere else. Inheritance means a new class can be based on an existing one, so a class for laptops in the lending program could build on LibraryItem and add a battery-check method. Polymorphism means different classes can respond to the same method name in their own way. Tech+ concentrates on objects, properties, attributes and methods, but recognizing these words helps when reading documentation.

Version control

Version control is a system that records every change to a set of files over time, so you can see who changed what, when and why, compare versions and go back to an earlier one. It is used for source code above all, but also for scripts, configuration files and documentation. Git is the most widely used version control system, and services such as GitHub, GitLab and Azure DevOps host Git repositories online. Without version control, people fall back on file names like kiosk_check_final_v2_REALLY_FINAL.ps1, which is exactly what Dez found on the shared drive.

A few terms cover the essentials. A repository, or repo, is the stored project with its full history. A commit is a saved snapshot of changes with a short message explaining them, such as "Move mail server name into a constant." A branch is a separate line of development, so someone can work on a new feature without disturbing the working version, which usually lives on a branch called main. Merging brings the changes from one branch back into another. When two people change the same lines differently, the system reports a merge conflict, and a person decides which version to keep. Cloning copies a repository to your own computer; pushing sends your commits back to the shared copy, and pulling fetches other people's.

For a support technician, the practical value of version control is the history. When the kiosk report breaks on a Tuesday, the first question is "what changed?", and a repository answers it in seconds: the log shows a commit on Monday afternoon that changed the list of kiosk addresses. Rolling back to the previous commit restores the working version while the team works out what went wrong. Configuration files for routers, firewalls and servers benefit from the same discipline, and many IT teams now keep them in Git for that reason.

Hana Petrovic, the security and accounts lead, adds a warning from her side of the team: a repository remembers everything, so passwords and keys must never be committed to it, even briefly. Deleting a password in a later commit does not remove it from the history. Settings that are secret belong in a password vault or a protected configuration store, which the security lessons return to.