Write Code For The Future You
•0 likes•280 views
Report
Share
How many jobs will you have before you retire? A typical worker in the United States switches jobs every 4-5 years; in the tech industry stays are even shorter. Due to this software developers are guaranteed both to work on someone else?s code and someone will work on our code. To survive, it is critical you continue to add value by improving the quality of the code you write and/or maintain in your job as a software developer. In this session, we will define what it means to improve the quality of the code and give you practical steps towards improving it every day.
Recommended
More Related Content
More from Paul Gower
More from Paul Gower(9)
Recently uploaded
Recently uploaded(20)
Write Code For The Future You
- 2. DevSpace would like to thank our sponsors!
- 29. Describe the entity it represents
- 30. Describe the entity it represents Easy to understand and read
- 31. Describe the entity it represents Easy to understand and read Be specific as possible
- 32. Bad Names total, ct, checks, CHKTTL velt, tv, train cd, current, c, date lpp, lines Good Names runningTotal, checkTotal trainVelocity, velocityInMph currentDate, todaysDate linesPerPage
- 34. Don’t use magic numbers
- 35. Don’t use magic numbers Instead use constants, enums or config
- 36. Don’t use magic numbers Instead use constants, enums, or config Makes code more readable / self documenting
- 40. Duplication leads to maintenance issues
- 41. Duplication leads to maintenance issues Y2K Culprit?
- 42. Duplication leads to maintenance issues Y2K Culprit? “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”
- 44. Each responsibility is an axis of change
- 45. Each responsibility is an axis of change Change is going to happen
- 46. Each responsibility is an axis of change Change is going to happen Loose Coupling
- 50. Legacy Code = Code without Tests
- 51. Legacy Code = Code without Tests Great Step-by-step guide
- 52. Legacy Code = Code without Tests Great Step-by-step guide Write unit tests as you use legacy code
- 54. Author + 2 Reviewers
- 55. Author + 2 Reviewers Using “peer pressure”
- 56. Author + 2 Reviewers Using “peer pressure” Encourages collaboration
- 58. Keep a positive attitude
- 59. Keep a positive attitude Check your ego
- 60. Keep a positive attitude Check your ego Review all code
- 61. Keep a positive attitude Check your ego Review all code Code Review early and often
- 63. Give better variable names
- 64. Give better variable names Don’t use magic numbers
- 65. Give better variable names Don’t use magic numbers Keep your code DRY
- 66. Give better variable names Don’t use magic numbers Keep your code DRY Classes should do one thing
- 67. Give better variable names Don’t use magic numbers Keep your code DRY Classes should do one thing Write Unit Tests
- 68. Give better variable names Don’t use magic numbers Keep your code DRY Classes should do one thing Write Unit Tests Have regular Code Reviews
- 70. The Mythical Man Month by Frederick P. Brooks Jr (http://www.amazon.com/The-Mythical- Man-Month-Engineering-Anniversary/dp/0201835959) Code Complete by Steve McConnell (http://www.amazon.com/Code-Complete-Practical- Handbook-Construction/dp/0735619670) Clean Code by Robert C. Martin (http://www.amazon.com/Clean-Code-Handbook-Software- Craftsmanship/dp/0132350882) Working Effectively with Legacy Code by Michael Feathers (http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052) FogCreek Software Blog Effective Code Reviews - 9 Tips from a Converted Skeptic (http://blog.fogcreek.com/effective-code-reviews-9-tips-from-a-converted-skeptic/) Stop More Bugs with our Code Review Checklist (http://blog.fogcreek.com/increase- defect-detection-with-our-code-review-checklist-example/)
Editor's Notes
- First I want to tell you a little bit about my background and help you understand where I have come from and why I am excited to share with you today some of my thoughts around writing better code for your future self (or someone else). I want you to understand that I hope this talk, like my other one if you attended it earlier today, is more about starting the conversation (and I hope to give you some good tips along the way). But know that I enjoy not only discussing this topic of clean code or writing better code but I solicit your feedback or tips you might have as well. So please reach out to me on twitter to continue this discussion as we learn how to improve how we write code.
- First internship my junior year in college over the summer of 2000. I wrote a lot of perl script. I had never really written anything except C++ and some assembler up until this point. It was an interesting experience because it was my first intro to a language that had so many different ways to program a solution.
- Anyone here heard of this contest? Annual competition between 1996 and 2000 Entries were judged on incomprehensibility among other things They even had an annual contest for a few years to see how obfuscated you could write your code. I'm sure many of you who are older than me remember a similar contest around writing obfuscated c code back in the day.
- It was consider a badge of honor if you could write code in a way to “stump” a programmer who might not know perl very well. Or code that only they could figure out… We are not built to be human compilers. Let the computer do that.
- After that internship I finished college and took a job that changed my outlook on writing code forever.
- My first job right out of college was working for a big company called Alltel Information Services. Originally was a company called Systematics that was bought by Alltel and renamed to Alltel Information Services
- They started us in a 6 month training program they called Alltel Client-Server University. They wanted to train new employees in the way that they developed their software. Since it was banking software it was very complex and it was really bad if you introduced a bug and ended up losing someone’s money. People don’t like it when you lose their money.
- My first job out of college was at Alltel Information Services (sub of Alltel) A great learning experience because of the 6 month training course they did for new hires to train us to work on the complex systems they have developed. Alltel University - Instructor lecture time - lab time - code review every day Changed the trajectory of my career to be more aware of writing better readable code and less "elite code" Anyone to be able to understand my code
- I eventually changed jobs a couple of times and started working for a consulting company. After working for them for a few years, I was added to “that project”. You know the one that was starting to slip on some of their milestone dates and it was looking like the delivery date was going to slip as well. And you guessed it the project manager thought it would be a great idea to just add more people to the project to “Save” it from being late.
- On paper it looked like a good idea to the project manager to add me to the project. It appeared that I would be able to help them complete the project on time and become the “hero” for that project. Well I started on the project and ran into a really hard to find bug. It was even harder to find because it was in code I couldn’t easily understand. It was written in a way that was really hard to follow the logic of the program, etc.
- Has anyone in here had to find a bug in some code that was hard to understand? (it could be code that you had written a few months ago even) I wanted to rewrite the code instead of trying to fix the bug because it seemed like it would be easier. Can anyone relate to that? (pause) Well I eventually found the bug but the project wasn’t early or even on time due to not only this bug but also do to another thing I had learned in the Alltel Client/Server University but hadn’t seen in the real world until this project. It’s called the…
- Has anyone in here read this book or at least know the concept behind the book? Okay there are some that don’t so I’ll give you the simplest example I know even though it’s a bit contrived: The idea is you can’t always add more developers to a project to make the project finish faster. The analogy I like is: Can 9 women have a baby on 1 month rather than 9 months? Of course not that’s absurd! Well in the same light not all projects can be easily split into parts that are easily developed simultaneously. Sometimes it is just adding fuel to the fire rather than putting the fire out!
- So many developers enjoy writing new programs or starting from scratch we sometimes forget why we should care about Maintenance of our code. Who can tell us the percentage breakdown of time we spend as developers creating versus maintaining code? Barry Boehm - Software Engineering Economics, Prentice Hall Schach, R., Software Engineering, Fourth Edition, McGraw-Hill Glass, Robert, Frequently Forgotten Fundamental Facts about Software Engineering
- Who can tell us the percentage breakdown of time we spend as developers creating versus maintaining code? Barry Boehm - Software Engineering Economics, Prentice Hall Schach, R., Software Engineering, Fourth Edition, McGraw-Hill Glass, Robert, Frequently Forgotten Fundamental Facts about Software Engineering
- Who can tell me how much of our time do we spend as developers reading code vs writing code? Clean Code book
- Who can tell me how much of our time do we spend as developers reading code vs writing code? Clean Code book
- Before giving you one of my favorite quotes around why you should care who the reader of your code is, I want to give you some interesting history behind where the quote came from.
- It all started in a Comp.lang.c++ newsgroup discussion back in 1991.
- Someone asked the newsgroup why people don’t use the comma operator more often in C++. Does anyone know what the comma operator is used for in C++?
- Here’s an example of using the comma operator where you will notice that both variable assignments would take place on the same line of code. Therefore both assignments would happen if the if expression resulted in TRUE But what if a more junior developer came behind you and didn’t understand the comma operator so they decided to change it to a semicolon because they just assumed you meant to use a semicolon instead of a comma.
- I mean in reality it’s just a simple dot that is changing here, right? It’s one character changing what harm could it cause? One little dot is changed to the viewer but the meaning of the 2nd example of code is very different. In other words the comma operator can make the code harder to read. Just one dot made the anothervar = anothervalue; execute. So from this discussion is where the first time I heard one of my favorite quotes:
- This quote comes from a post John F. Woods authored back in 1991 to the comp.lang.c++ news group.
- I want to go over some tips that I find to be helpful when writing code for my future self and I hope they will help you today. Also this is a journey and I don’t know it all and this is not an exaustive list these are just some that I think will help you start writing better code for your future self. But before we get started I want to give a quick review of some of the history behind this “Clean Code” / “Better Code” / “Code Complete” movement. It obviously started for me when I went through Alltel Client/Server University but this movement has been around for a while. Here are a list of some things that I think impacted my view of how to write better code:
- Writing better code is an iterative process and we are still learning how best to do it today. 1993 Code Complete 1st edition 2004 Code Complete 2nd edition I have already discussed the impact this book has had (along with the 6 month training I received right out of college) so I won’t talk about it much more…other than to say if you haven’t read it I highly recommend it! I love Steve’s approach and how he backs everything with data and statistics...which I will show you some of them later in this presentation.
- This was a milestone to me as well. I learned a lot from the iterative approach to writing software the agile way. It also reminds me that even in my “writing better code” approach I need to be open to change and not fight against it. It helps me remember that the end goal is to make the best process we can use to write better code and that ‘my way’ could be improved upon as we learn more. I am a big fan of keeping the feedback loop as tight as possible so we are delivering exactly what our clients need us to deliver. I could talk a lot longer about this but we need to keep moving.
- Uncle Bob has written a few books on writing “Clean Code” or “Clean Coder”. He is also another “great leader” in the movement of writing “better” or “clean code”. Now I want to discuss a few tips (6 to be exact) on how you can start writing better code today. Speaking of one of my favorite books this first tip comes from Code Complete.
- Tips for writing better code that is easier to maintain. The most important consideration in naming a variable is that the name fully and accurately describe the entity the variable represents. An effective technique for coming up with a good name is to state in words what the variable represents.
- You want your variables easy to read and understand. Again we don’t need to compile code in our head we should be able to read it like prose.
- The more specific you can be the easier it will be to understand what the variable represents when you look at it 3-6 months from now. Here are some examples of both bad names and good names.
- Running total of checks written to date Velocity of a bullet train Current Date Lines per page Now on to our next tip…Magic Numbers
- Who knows what I mean when I say: “Magic Number”? Ok, good. Well some don’t so let me explain. It’s where you use a specific number in an expression in your code rather than a variable or constant value.
- Rule #1: Just don’t use them!
- Instead of commenting around the magic number use a constant, enum or some configuration file or setting in your program
- Having a constant or some variable (if named properly like we discussed already) can make the code easier to read. For example, something like “MAX_LENGTH_OF_PASSWORD” than a number 8.
- Tips for writing better code that is easier to maintain. The most important consideration in naming a variable is that the name fully and accurately describe the entity the variable represents. An effective technique for coming up with a good name is to state in words what the variable represents.
- Tips for writing better code that is easier to maintain. The most important consideration in naming a variable is that the name fully and accurately describe the entity the variable represents. An effective technique for coming up with a good name is to state in words what the variable represents. Now on to our next tip…D.R.Y.
- Duplication (inadvertent or purposful duplication) can lead to maintenance nightmares, poor factoring, and logical contradictions. One could argue that most of the diffculty in Y2K remediation is due to the lack of a single date abstraction within any given system. DRY is more than not duplicating code. Dave Thomas interview: DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation. Given all this knowledge, why should you find one way to represent each feature? The obvious answer is, if you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other. Even if they don't, you're guaranteeing yourself the headache of maintaining them in parallel whenever a change occurs. And change will occur. DRY is important if you want flexible and maintainable software.
- Duplication (inadvertent or purposeful duplication) can lead to maintenance nightmares, poor factoring, and logical contradictions.
- One could argue that most of the difficulty in Y2K remediation is due to the lack of a single date abstraction within any given system. They had multiple representations of the “DATE” class in their programs and due to this technical debt when the 2-digit year became an issue it wasn’t as simple as changing the code in one place.
- Dave Thomas interview: DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation. Given all this knowledge, why should you find one way to represent each feature? The obvious answer is, if you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other. Even if they don't, you're guaranteeing yourself the headache of maintaining them in parallel whenever a change occurs. And change will occur. DRY is important if you want flexible and maintainable software.
- Here are some tips to help us write clean code. Classes – should have a single responsibility This is the S in the SOLID principles you may have heard of before. If not I recommend you go google SOLID principles and read about them be
- Why is it important to separate responsibilities among classes and or methods in programming? In Uncle Bob’s book “Clean Code” he says “Because each responsibility is an axis of change.”
- You are going to miss something. Requirement, or bug in your code…or even a new feature is going to be added to the program at some point. Change usually happens in responsibility or axis
- Loose Coupling – Classes should not have direct knowledge of each other. This helps with being able to change as little code as possible when a change does need to happen. Here is an example albeit contrived but it still drives home the point.
- Rectangle class has 2 methods which are 2 different responsibilities. Provide mathematical model of the geometry of the rectangle Render the rectangle on a graphical user interface 2 applications use the rectangle class If area method changes then both applications have to recompile.
- Single Responsibility Pattern – S in SOLID principals See how we split the rectangle’s responsibilities into 2 Now if Area method changes just the geometric rectangle changes.
- Tips for writing clean code or easier to maintain code. What is legacy code you might ask? One of the best definitions I have found that describes Legacy code is…Code w/out tests
- The average software project was written under some aspect of code-and-fix without automated unit tests. And we can’t just throw this code away. In “Working Effectively with Legacy Code” Michael Feathers provides step-by-step instructions on how to deal with code to get it better with unit tests. He provides specific advice for several situations and rules that help you recognize Next time you use a method you will want to write a unit test for it.
- In “Working Effectively with Legacy Code” Michael Feathers provides step-by-step instructions on how to deal with code to get it better with unit tests. He provides specific advice for several situations and rules that help you recognize Next time you use a method you will want to write a unit test for it.
- Next time you use some legacy code why not try and write a unit test to test the code you just wrote or changed in a legacy method? What harm could it do?
- Tips for writing clean code or easier to maintain code. Should involve programmer and at least 2 reviewers. This means there are at least 3 people reading your code. Use “peer pressure” to your advantage (or motivation for you if you’re the programmer).
- Tips for writing clean code or easier to maintain code. Should involve programmer and at least 2 reviewers. This means there are at least 3 people reading your code. Use “peer pressure” to your advantage (or motivation for you if you’re the programmer).
- Tips for writing clean code or easier to maintain code. Should involve programmer and at least 2 reviewers. This means there are at least 3 people reading your code. Use “peer pressure” to your advantage (or motivation for you if you’re the programmer).
- Tips for writing clean code or easier to maintain code. Should involve programmer and at least 2 reviewers. This means there are at least 3 people reading your code. Use “peer pressure” to your advantage (or motivation for you if you’re the programmer).
- We as developers are really good at finding issues or being critical; however, remember just because someone didn’t do something how you would have done it doesn’t necessarily mean it is wrong.
- We as developers are really good at finding issues or being critical; however, remember just because someone didn’t do something how you would have done it doesn’t necessarily mean it is wrong.
- Both for the reviewer and the submitter it is good to check your ego at the door. Code review is not the time to show your amazing coding prowess nor is it a time to get defensive.
- No code is too short or too simple to review. It builds a habit of always reviewing code
- The effectiveness of your reviews decreases after an hour so don’t put off code reviews. It’s good to set aside time during the day to coincide with breaks so you don’t disrupt your own flow.
- We discussed 6 main tips that I want to go over quickly again… Name variables better. They need to describe the entity it represents and be easy to understand and readable.
- Name variables better. They need to describe the entity it represents and be easy to understand and readable. Ban magic numbers
- Ban magic numbers 1 logical representation of each concept in your code along side not repeating code when possible.
- 1 logical representation of each concept in your code along side not repeating code when possible. Methods should do one thing and one thing well. Each responsibility is an axis of change
- Methods should do one thing and one thing well. Each responsibility is an axis of change Stop writing legacy code and start writing unit tests
- Stop writing legacy code and start writing unit tests Have regular code reviews with at least 2 reviewers and the programmer should be present
- Have regular code reviews with at least 2 reviewers and the author
- Questions? Comments?