1 / 18

PHILOSOPHY OF CODING

PHILOSOPHY OF CODING. An untidy room is like bad code: you spend hours in finding things and when you try to add something you are just adding mess. A tidy room is like good code: you immediately find things, and you can easily change the way they are organized.

hawa
Download Presentation

PHILOSOPHY OF CODING

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PHILOSOPHY OF CODING

  2. An untidy room is like bad code: you spend hours in finding things and when you try to add something you are just adding mess.

  3. A tidy room is like good code: you immediately find things, and you can easily change the way they are organized.

  4. The speed of development is related to costs. The speed of development can increase over time as you indulge in bad practices. It can improve with refactoring.

  5. The speed of development is not just the time you spend to develop a certain functionality, but the time others will spend in adding functionalities to your code.

  6. A maintainable code can easily be changed, reduce the costs, has a limited number of bugs, and... make the developers more happy!

  7. The big question How to write maintainable code?

  8. Remember: smart is the one who can see far away, but in the only direction allowed by the blinders. Wise is the one who can turn his head 360 degrees. • Don't be intelligent when you code. Be wise!

  9. First principle: design before coding. • The more time you spend on design, the less time you will spend on debugging.

  10. Second principle: understand the functionality before coding or bug fixing. • If you understand the functionality, the code will be an open book.

  11. Third principle: be simple! • Find the simplest solution for the complexity you have to deal with. Complex solutions or not normalized schemas will add complexity exponentially along the development process. When you have to change something unnecessarily complex, you will resort to a quadratic complex trick.

  12. Fourth principle: separation of concerns to avoid spaghetti code. • Separation of concerns is mainly achieved by encapsulating. • When a change affect only one part of your code, it's easy to add functionalities. • Spaghetti code means that when you touch something, the entire castle of cards collapse on itself.

  13. When you puncture a tire, you can easily substitute it. With spaghetti-code, you would have to buy a new car.

  14. Indicator of a good code (not spaghetti-code style!) • The time spent in reading and understanding the code or the time spent in bug fixing should be low, compared to the time spent in coding.

  15. Fifth principle: code reuse. • "One of the attributes that most strongly distinguishes expert programmers from less experienced ones is that experts strive for and usually achieve a high degree of code reuse" (by Joshua Bloch, Effective Java) • That include writing atomic functions, which promotes code reuse.

  16. Good code is always maintainable, bad code is always unmaintainable.

  17. The pyramid of good coding

  18. Final truth • The universe is actually terribly simple, unfortunately explaining things in a complex way is just as easy.

More Related