Bad Programming Practices 101: Become a Better Coder by Learning How (Not) to Program - Couverture souple
Synopsis
Chapter 1: Fundamentals of Badness
How best to approach programming, in particular how to learn it, how to choose your tools wisely, and how to
think 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 Structure
Show 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: Variables
Explain 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 system
Chapter 4: Conditionals
Discuss 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 gaps
Chapter 5: Loops
Discuss 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 fun
Chapter 6: Subroutines
Show 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 toes
Chapter 7: Error-handling
Explain 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: Modules
Discuss 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: Objects
Discuss 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 debugging
Show 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 levels
Chapter 11: Testing
Show how to carry o
Les informations fournies dans la section « Synopsis » peuvent faire référence à une autre édition de ce titre.
