Fundamentals 6 min read

Why the 80‑by‑24 Rule Can Make Your Code More Readable

The article explains how limiting functions to roughly 24 lines and keeping each line under 80 characters improves code readability, aligns with human memory limits, and works across languages, while offering practical tips, examples, and tooling advice for developers.

ITPUB
ITPUB
ITPUB
Why the 80‑by‑24 Rule Can Make Your Code More Readable

01 Small Code Segments

Drawing on Miller's 7±2 memory limit, the author argues that writing code in small, self‑contained pieces—functions, features, or programs—helps developers process information more effectively. He introduces the “80/24 rule”, recommending that a function stay around 24 lines long, with each line no longer than 80 characters.

02 Shorten Line Width

While many languages allow multiple statements per line, cramming code defeats the purpose of the rule. Keeping line width to 80 characters, a long‑standing industry convention, enhances readability, especially when reviewing diffs, working on small screens, or collaborating via screen sharing.

Common issues with overly wide code include difficulty comparing changes, unreadable lines on small devices, visual strain for older developers, and challenges during mob programming, remote screen sharing, or presentations.

Developers can enforce the limit with editor extensions; for example, Visual Studio’s “Editor Guidelines” can display a red line at column 80.

03 Traditional Terminal Devices

The 80‑by‑24 dimensions trace back to the 1970s VT100 terminal, which displayed 80 columns by 24 rows. This historic size still offers a comfortable reading experience for many programmers.

Conclusion

Applying the 80/24 rule, similar to the 80/20 principle, helps keep code concise and maintainable. The exact numbers may vary by language; for C# the author finds 24 lines and 80 characters per line to be a comfortable sweet spot.

var foo = 32; var bar = foo + 10; Console.WriteLine(bar);
public ActionResult Post(ReservationDto dto)
{
    var validationMsg = Validator.Validate(dto);
    if (validationMsg != "")
        return BadRequest(validationMsg);

    var reservation = Mapper.Map(dto);
    var reservations = Repository.ReadReservations(reservation.Date);

    var accepted = maîtreD.CanAccept(reservations, reservation);
    if (!accepted)
        return StatusCode(
            StatusCodes.Status500InternalServerError,
            "Couldn't accept.");

    var id = Repository.Create(reservation);
    return Ok(id);
}
return StatusCode(
    StatusCodes.Status500InternalServerError,
    "Couldn't accept.");
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Software Engineeringcoding standardscode readability80/24 ruleC#
ITPUB
Written by

ITPUB

Official ITPUB account sharing technical insights, community news, and exciting events.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.