This chapter discusses best practices for coding, including avoiding programming by coincidence, estimating algorithm speeds using Big O notation, refactoring code when needed to improve design, writing code that is easy to test with unit tests, and avoiding using code you don't understand from "wizards". It provides tips such as programming deliberately with a plan, testing assumptions, refactoring early and often, designing code to be testable, and understanding all code used. The chapter contains five sections on these topics.

1. CHAPTER 6
WHILE YOU ARE CODING

2. Zeynep DÜZYURT
i2i Systems – Summer Intern
zeynep.duzyurt@ext.i2i-systems.com

3. While You Are Coding
This chapter includes «While You Are Coding» approach in five
sections:
• Programming by Coincidence
• Algorithm Speed
•Refactoring
•Code that’s Easy to Test
•Evil Wizards

4. Programming by Coincidence
We should avoid programming by
coincidence—relying on luck and accidental
successes— in favor of programming
deliberately.
Tip 1: Don't Program by Coincidence

5. How to Program Deliberately
Always be aware of what you are doing.

6. How to Program Deliberately
•Don't code blindfolded.

7. How to Program Deliberately
Proceed from a plan !

8. How to Program Deliberately
Rely only on reliable things.

9. How to Program Deliberately
Document your assumptions.

10. How to Program Deliberately
Don’t just test your code, but test your assumptions as well.

11. How to Program Deliberately
Prioritize your effort. Spend time on the important aspects; more
than likely, these are the hard parts.

12. How to Program Deliberately
Don't be a slave to history. Don't let existing code dictate future code

13. Algorithm Speed
Pragmatic Programmers estimate the resources that algorithms use—time,
processor, memory, and so on.
Use: Big O Notation
O(1): Constant (access element in array, simple statements)
O(n): Linear: Sequential search
O(n²): Square law (selection and insertion sorts)
O(logn): Logarithmic (binary search) lg(n) = lg2(n)

14. Algorithm Speed

15. Algorithm Speed

16. Algorithm Speed

17. Algorithm Speed

18. Algorithm Speed

19. Common Sense Estimation
Simple loops: O(n)
Nested loops: O(n²)
Binary chop: O(log(n))
Divide and conquer: O(n lg(n)). Algorithms that partition their input, work on the two halves
independently, and then combine the result.
•Tip 3 : Test your estimates•Tip 2: Estimate the Order
of Your Algorithms

20. Refactoring
.Code needs to evolve; it's not a static thing.

21. When You Should Refactor ?
Duplication. You've discovered a violation of the DRY principle (The Evils of
Duplication).
Nonorthogonal design. You've discovered some code or design that could be
made more orthogonal (Orthogonality).
Outdated knowledge. Things change, requirements drift, and your knowledge
of the problem increases. Code needs to keep up.
Performance. You need to move functionality from one area of the system to
another to improve performance.
Tip 4: Refactor Early,
Refactor Often

22. How Do You Refactor?
Don't try to refactor and add functionality at the same time.
Make sure you have good tests before you begin refactoring.
Take short, deliberate steps.

24. Code That's Easy to Test
Build testability into the software from the very beginning, and test each piece
thoroughly before trying to wire them together.

25. Testing Against Contract
This will tell us two things:
Whether the code meet the contract
Whether the contract means what we think it means.
Tip 5: Design to Test

26. Writing Unit Tests
Examples of how to use all the functionality of your module
Make easier to validate any future changes to the code
By making the test code readily accessible, you are providing developers who
may use your code with two invaluable resources:

27. A Culture of Testing
Test your software or users do it

28. Evil Wizards
Tip 6: Don't Use Wizard
Code You Don't
Understand
If you do use a wizard, and you don't understand all the code that it
produces, you won't be in control of your own application.