The document discusses best practices for writing code that is easy for others to read and understand. It recommends writing code with short, clearly named methods; consistent formatting; necessary but not redundant comments; and avoiding issues like deeply nested code, long methods, and unnecessary complexity. The goal is to write code that other programmers can easily and enjoy reading to understand the program's logic and functionality.

1. Writing Code For Others
amol.pujari@gslab.com
http://www.codinghorror.com/blog/

2. Why
Writing Code For Others
http://www.makinggoodsoftware.com/

3. why do we write code?
•to get it executed by a machine
•the machine understands 0s and 1s only
•then why do we use high level languages like c,
java, or ruby
•did the machine request us to use c or ruby?
http://sourcemaking.com/

4. we use high level languages so
humans can understand code by
reading it
http://www.makinggoodsoftware.com/2009/07/07/5-top-non-technical-mistakes-made-by-

5. how do others find reading your code?
•do they find it helpful in understanding your
program
–the optimizations you’ve done
–your naming conventions, your coding style
–how long they should take to do it
–more importantly, would they like looking at your
code
–would they love the way you code
•or do they simply find it quite boring
http://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-

6. you can help others to quickly
read your code and understand it
http://www.joelonsoftware.com/articles/Wrong.html

7. characteristics of good code
•easy to read
•easy to use
•clean, simple, straight forward
•easy to make any changes
•self explanatory
•short methods, clear names
•consistent coding standards
http://www.thoughtclusters.com/2010/09/characteristics-of-great-programmers/

8. writing necessary comments
http://www.makinggoodsoftware.com/2009/09/01/programmers-top-10-sentences/

9. writing necessary comments
•let’s define “necessary” comments
http://en.wikipedia.org/wiki/Code_smell

10. writing necessary comments
•should not tell us how code works
•but why code works
•convert your comments into variable names or
function names, constants
http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns

11. follow same indentations
•different people love different editors
•tab is treated differently by different editors
•define tab = 2 or 4 spaces
•good if entire team follows same definition of
tab
http://www.makinggoodsoftware.com/2011/05/23/top-7-programmers-bad-habits/

12. more than indentations
http://www.makinggoodsoftware.com/2010/05/27/10-things-they-never-teach-in-college-

13. more than indentations
http://www.makinggoodsoftware.com/2010/03/13/my-ten-development-principles/

14. write working pseudo code
•write a program
•given a number
•print “divisible by 3” if it is divisible by 3
•print “divisible by 5 if it is divisible by 5
•print “divisible by 15” if it is divisible by 15
http://www.codinghorror.com/blog/2009/05/pseudocode-or-code.html

15. write working pseudo code
•write a program
•given a number
•print “divisible by 3” if it is divisible by 3
•print “divisible by 5 if it is divisible by 5
•print “divisible by 15” if it is divisible by 15
http://www.codinghorror.com/blog/2009/05/pseudocode-or-code.html

16. write working pseudo code
•you might have simply optimized
•reducing one divide operation

17. write working pseudo code
•write a program
•given a number
•print “divisible by 3” if it is divisible by 3
•print “divisible by 5 if it is divisible by 5
-a change request
print “divisible by 15” if it is divisible by 15
print “divisible by 17” if it is divisible by 17
http://stackoverflow.com/questions/84556/whats-your-favorite-programmer-cartoon

18. write working pseudo code
•If pseudo code would have been followed
•without optimizations

19. nested if-else
http://tinyletter.com/codereading

20. nested if-else
•avoid nested if-else chain
•use switch or multiple returns
•same follows for iterators while, for
http://inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer

21. god class
•a file or class or a module
•knows too much or does too much
•contains more than 1000 or 5000 loc
•class with a large number of attributes,
operations, or both
•uses heavy encapsulation
http://www.dehora.net/journal/2005/06/writing_code_for_others_that_use_it.html

22. long methods
•would you like to read and understand a
function which is of 300 lines or say 1000 lines
•or would you like to understand functions with
10 lines, 20, say 30 lines at the most
http://www.dmst.aueb.gr/dds/pubs/jrnl/2003-ACMQ-CR/html/article.html

23. one function one responsibility
http://www.skorks.com/2010/05/why-i-love-reading-other-peoples-code-and-you-should-too/

24. one function one responsibility
http://rubylearning.com/blog/2010/11/08/how-does-your-code-smell/

25. long parameters list
http://www.codinghorror.com/blog/2006/05/code-smells.html

26. more coding horrors
•uncommunicative name - naming functions and
variables
•magic numbers, hardcoded values
•data clumps
•feature Envy
•middle man …and more
http://www.codinghorror.com/blog/2006/05/code-smells.html

27. characteristics of a good code
•easy to read
•easy to understand
•easy to make any changes
•clean, simple
•looks straight forward
•self explanatory
•short methods, clear names
http://www.perlmonks.org/?node_id=592616

28. characteristics of good code
•easy to read
•easy to use
•clean, simple, straight forward
•easy to make any changes
•self explanatory
•short methods, clear names
•consistent coding standards
http://www.thoughtclusters.com/2010/09/characteristics-of-great-programmers/

29. characteristics of a good coder
•likes to read code written by well known
programmers
•likes to do code review of junior or senior
colleagues
•participates in pair programming
•learns new things weekly w.r.t. coding
•does not make unnecessary complex
optimizations
•does not refractor working code again and
again
http://sourcemaking.com/refactoring

30. enjoy coding
http://www.artima.com/intv/ruby.html