2 Writing code everyone can read

 

This chapter covers

  • Focusing on working code first
  • Writing code that’s understandable to the whole team
  • Ways around overengineering
  • Eliminating apparently random bugs
  • Learning about languages you don’t normally use

During your journey as a developer, one of the main activities in your day is going to be coding. Writing code needs to become part of your life, not because you want to make a living out of it, but because you’re looking to be great at it. Just as any Olympic athlete spends a portion of their day training and the rest of it thinking about their training, you need to do the same. If you’re aiming to become an Olympic coder (granted, that’s not a thing, but it should be) you need to make code your life.

I’m not asking you to forfeit time with your loved ones, but keeping code in the back of your mind is something that you’ll want to do. While that might sound a bit vague, my point is that the intrinsic logic behind the act of coding—what’s usually known as Boolean logic—should be present in all you do. That’s how, when you sit down to write some code, the logic will just flow out of your fingers.

2.1 Your code needs to work

 
 

2.1.1 Good is better than perfect

 
 
 

2.1.2 Working, then optimized

 
 

2.1.3 Sometimes terrible code actually helps

 
 

2.2 Code for people, not for the machine

 

2.2.1 Self-documenting code is a lie

 
 

2.2.2 Readable code > one-liners

 
 
 

2.3 Overengineering: The first capital sin

 
 
 
 

2.3.1 Spotting a case of overengineering

 
 
 
 

2.4 The random bug mystery

 

Summary

 
 
 
sitemap

Unable to load book!

The book could not be loaded.

(try again in a couple of minutes)

manning.com homepage