Write Code For The Future You

Many believe the days of staying at a job long enough to retire is gone. A typical worker in the United States switches jobs ever 4-5 years and in the tech industry it is even shorter. Due to this there is an even greater need now to improve the quality of the code you write and / or maintain in your job as a software developer. In this session, we will discuss what it means to improve the quality of the code and how you can work towards improving it every day. Also we will go over a few practical tips you can start using today to improve the quality of your code.

Transcript

1. Write Code For The Future You Paul Gower @paulmgower
2. Full Disclosure… u First Internship writing Perl script, summer 2000 u Obfuscated Perl Contest u Annual competition between 1996 and 2000 u Entries were judged on incomprehensibility among other things u Mentality was to write “elite code” that was hard to understand
3. First Job u First job out of college, 2001 u Alltel Client/Server University u 6 month training class u 8a to 5p every day u Textbook: Code Complete u Lecture u Lab u Code Reviews
4. Why Worry about Maintenance? Development Time 30% Maintenance Time 70%
5. Why Write Code for Reader? Writing Code 10% Reading Code 90%
6. Why Write Code for Reader? u Sept 1991, Comp.lang.c++ newsgroup discussion u Why not use comma more? u Like this: if (condition) var = value, anothervar = anothervalue; u However consider this: if (condition) var = value; anothervar = anothervalue;
7. Food for thought “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live” John F. Woods
8. Power in Variable Names u Describe the entity it represents u Easy to understand and read u Be specific as possible
9. Variable Name Examples Bad Names u total, ct, checks, CHKTTL u velt, tv, train u cd, current, c, date u cnt, ct, lpp Good Names u runningTotal, checkTotal u trainVelocity, velocityInMph u currentDate, todaysDate u linesPerPage
10. Don’t Repeat Yourself (DRY) u Duplication leads to maintenance issues “Every piece of knowledge must have a single, unabiguous, authoritative representation within a system” u Y2K Culprit?
11. Stop Writing Legacy Code u Legacy Code = Code without Tests u Great Step-by-step guide u Write Unit Test as you use legacy methods
12. Code Reviews u Should involve the programmer and at least 2 reviewers. u Using “peer pressure” u Encourages collaboration
13. Code Reviews Tips u Keep a positive attitude u Check your ego u Review all code u Code Review early and often
14. Final Review u Give better variable names u Keep your code DRY u Write Unit Tests u Have regular Code Reviews
15. Questions? Paul Gower @paulmgower lunamark.com Please Rate My Talk: http://bit.ly/wcfy-memtc2015
16. Resources u Code Complete by Steve McConnell (http://www.amazon.com/Code-Complete-Practical- Handbook-Construction/dp/0735619670) u Clean Code by Robert C. Martin (http://www.amazon.com/Clean-Code-Handbook-Software- Craftsmanship/dp/0132350882) u Working Effectively with Legacy Code by Michael Feathers (http://www.amazon.com/Working-Effectively-Legacy- Michael-Feathers/dp/0131177052) u FogCreek Software Blog u Effective Code Reviews - 9 Tips from a Converted Skeptic (http://blog.fogcreek.com/effective-code-reviews-9-tips-from-a- converted-skeptic/) u Stop More Bugs with our Code Review Checklist (http://blog.fogcreek.com/increase-defect-detection-with-our- code-review-checklist-example/)