目次

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