Bad Programming 101 - Part 2 Become a Better Coder by Learning How (Not) to Program

  • Karl Beecher

Your browser needs to be JavaScript capable to view this video

Try reloading this page, or reviewing your browser settings

You're watching a preview of subscription content. Log in to check access

Learn to avoid bad programming practices that create low-quality code that is difficult to maintain or test, and exhibits properties such as brittleness, low comprehensibility, and high defect density. This video takes a humorous slant on the typical programming practice manual by reversing the usual approach. Its approach is to jokingly assume that you wish to be an agent of chaos and sneak bad code into a software project in order to ruin its chances of success, or frustrate your colleagues by producing unreadable, error-prone garbage. Under this pretense, the video teaches how to avoid the kind of bad habits that introduce bugs or cause code contributions to be outright rejected.

The bad practices are organised into topics that form the basis of programming (layout, variables, loops, etc.). At the end of each topic, a more serious voice chimes in temporarily to explain why the ‘advice’ just given is actually poor and suggests some better alternative practices. By sourcing classic programming guidebooks, empirical studies, and a range of coding conventions from some of the most successful software projects, this video explains the reasoning behind good programming practices.

These topics form the basis of good programming style and are important for anyone embarking on a career in professional programming or wishing to contribute to a software project. Normally, beginner programmers learn these good practices by going through a period of making mistakes and learning from them. This video helps to shorten that learning process by teaching a core of good practices and will enable you to become a productive programmer faster.

This video – Part 2 of the series – focuses on coding practices at the ‘modular scale’, i.e. at the level of organisational building blocks such as subroutines and classes.

What You Will Learn

  • Become a better coder by learning how (not) to program

  • Choose your tools wisely

  • Think of programming as problem solving

  • Discover the consequences of a program’s appearance and overall structure

  • Avoid bad habits and common mistakes

  • See how poor error-handling makes for unstable programs

Who This Video Is For

You should have some practical programming knowledge (i.e. you can program in at least one programming language), but little to no professional experience. You are either still undergoing training in software development, or are at the beginning of your programming career. You have, at most, 1-2 years of professional experience.

Bad Programming 101 - Part 2 is a video that takes a humorous slant on the typical programming practice manual by reversing the usual approach.

About The Author

Karl Beecher

Karl Beecher lives a double life as a writer and software specialist. When being a writer, he focuses on science and technology. He likes to take meaty, complex ideas and present them in ways that are easy to understand. As a software specialist, Karl has worked as a software engineer, earned a PhD in computer science, and co-founded a company specializing in open source software. Karl has produced other videos for Springer, including a three-video series into open source software (“A Beginner’s Guide to Open Source”, “Moving to an Open Source World”, and “Free Everyday Software Alternatives”), and a two-video series on Git (“Getting Started with Git”, and “Going Further With Git”).

 

About this video

Author(s)
Karl Beecher
DOI
https://doi.org/10.1007/978-1-4842-7153-7
Online ISBN
978-1-4842-7153-7
Total duration
1 hr 15 min
Publisher
Apress
Copyright information
© Karl Beecher 2021

Related content

Video Transcript

[MUSIC PLAYING]

This is the second video in the two-part series Bad Programming Practices 101. It’s a series which tells you not so much which good practices to follow, but rather which bad practices to avoid. Let’s remind ourselves of the video’s rather unusual approach. This video doesn’t focus on how you should program. Instead, it advises you how not to program.

In fact, it takes that mission to its logical extreme and positively encourages you to be a bad programmer, just to drive home what the consequences might be. The result is a tongue-in-cheek style. From now on, whatever advice I give assumes that the viewer is seeking to become a failure, a programmer who ignores the rules, disrespects their colleagues, follows the worst practices, someone whose contributions are regularly rejected or, on the rare occasions they make it through review, create nasty bugs in once-functioning software.

Pardon me for interrupting, but throughout all the bad advice you’ll be getting, this more reasonable voice will occasionally interject and explain why a particular practice is viewed as a bad one in the real world. It might be because of a consensus among professional programmers or because of some empirical research. I might even suggest a few good practices you could consider instead. In any case, my voice appears in sections entitled Let’s Be Serious.

In the previous video, we looked at the topics of layout, variables, conditions, and loops, whereas in this video, we’re going to focus on the following topics– error handling and how you can ignore, suppress, and avoid responsibility for errors, how to produce monolithic, overly complex, and poorly structured subroutines, how you can spoil large-scale program structure by making modules difficult to understand, reuse, and test, and with classes and objects, we’re going to look at how to misapply object-oriented programming by designing classes inappropriately, misusing polymorphism, and abusing inheritance.