Bad Programming Practices 101 (eBook)

Karl Beecher is a British writer, software developer and teacher based in Berlin, Germany. He specializes in taking meaty, complex ideas and presenting them in ways that are easy to understand.

Chapter 1: Fundamentals of BadnessHow best to approach programming, in particular how to learn it, how to choose your tools wisely, and how tothink of programming as problem solving. Bad ways to learn programming Bad tooling Bad ways to approach a solution (or: programming is really problem-solving)Chapter 2: Layout and StructureShow the reader the consequences of a program’s appearance and overall structure. Make indentation and spacing poor and inconsistent Avoid structured programming, use lots of gotos Nest deeply - programmers like solving intricate puzzles Have lots of paths through a subroutine Clutter the code with extraneous tokens Avoid comments - code should be hard to read!Chapter 3: VariablesExplain poor use of variables in programs. Use obscure names - thinking up meaningful labels isn't worth the effort Consider declaration a waste of time Use global variables Thoroughly abuse the type systemChapter 4: ConditionalsDiscuss bad habits and common mistakes when using conditionals. Use long, complex expressions Forget the else clause - the computer will figure it out Mix up nominal cases with errors cases Make sure the cases overlap or have gapsChapter 5: LoopsDiscuss bad habits and common mistakes when using loops. Make 'em looooong! Give loops lots of exit points Avoid iterators - loop counters help make code convoluted and insecure Infinite loops are funChapter 6: SubroutinesShow the consequences of poorly-written subroutines. Write monolithic programs - after all, someone else will do the maintenance Make subroutines long and complex Use lots of local variables Use inconsistent return values to keep your colleagues on their toesChapter 7: Error-handlingExplain how poor error-handling makes for unstable programs. Never check inputs - users don't make mistakes Don't handle errors - just assume everything will always go well Don't check for null pointers If you must check values, do it as late as possible (a.k.a. defensive programming is for wimps)Chapter 8: ModulesDiscuss bad practices to follow when dividing a large program into pieces. Make modules big and hefty Ensure they expose their inner workings Give them rigid designs to prevent others from writing their pesky extensions Make them specific to one problem - why should others benefit from your work? Import all the things!Chapter 9: ObjectsDiscuss bad practices related specifically to object-oriented programming. Expose a class's internals - why should we have secrets? Put unrelated stuff together Objects are not independent - make them follow orders Keep coupling tight Favour deep inheritance hierarchies Avoid polymorphism - abstract code is harder to 'get' than abstract art Give classes multiple parents (a.k.a. classes shouldn't reproduce asexually)Chapter 10: Bugs and debuggingShow how to carry out ineffectual and inadequate ways to locate bugs and mitigate their effects. Write really unfriendly error messages - users shouldn't understand them anyway Don't discriminate between exception types Litter code with print messages Don't use debug levelsChapter 11: TestingShow how to carry out ineffectual and inadequate testing. Ignore the requirements when testing Leave testing until the very end Keep code coverage low Testing once is enough Avoid test automation tools