Op werkdagen voor 23:00 besteld, morgen in huis Gratis verzending vanaf €20

Bad Programming Practices 101

Become a Better Coder by Learning How (Not) to Program

Paperback Engels 2018 9781484234105
Verkooppositie 2618
Verwachte levertijd ongeveer 8 werkdagen


This book takes a humorous slant on the programming practice manual by reversing the usual approach: under the pretence of teaching you how to become the world’s worst programmer who generally causes chaos, the book teaches you how to avoid the kind of bad habits that introduce bugs or cause code contributions to be rejected.

Why be a code monkey when you can be a chaos monkey? OK, so you want to become a terrible programmer. You want to write code that gets vigorously rejected in review. You look forward to reading feedback plastered in comments like "WTF???". Even better, you fantasize about your bug-ridden changes sneaking through and causing untold chaos in the codebase. You want to build a reputation as someone who writes creaky, messy, error-prone garbage that frustrates your colleagues. Bad Programming Practices 101 will help you achieve that goal a whole lot quicker by teaching you an array of bad habits that will allow you to cause maximum chaos.

Alternatively, you could use this book to identify those bad habits and learn to avoid them. The bad practices are organized into topics that form the basis of programming (layout, variables, loops, modules, and so on). It's been remarked that to become a good programmer, you must first write 10,000 lines of bad code to get it all out of your system. This book is aimed at programmers who have so far written only a small portion of that. By learning about poor programming habits, you will learn good practices. In addition, you will find out the motivation behind each practice, so you can learn why it is considered good and not simply get a list of rules.

What You'll 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
- Explain poor use of variables in programs
- Avoid bad habits and common mistakes when using conditionals and loops
- See how poor error-handling makes for unstable programs
- Sidestep bad practices related specifically to object-oriented programming
- Mitigate the effects of ineffectual and inadequate bug location and testing

Who This Book Is For
Those who have some practical programming knowledge (can program in at least one programming language), but little or no professional experience, which they would like to quickly build up. They are either still undergoing training in software development, or are at the beginning of their programming career. They have at most 1-2 years of professional experience.


Aantal pagina's:221
Hoofdrubriek:IT-management / ICT


Wees de eerste die een lezersrecensie schrijft!

Geef uw waardering

Zeer goed Goed Voldoende Matig Slecht


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 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

Alle 100 bestsellers


Populaire producten



        Bad Programming Practices 101