This is the third installment of our Intern Diaries series, wherein each week our lovely interns try to give you the inside scoop on what being a programming intern at a high-tech startup is really like. [For Part 1 and Part 2] This week Ingrid tackles what makes for great code. See what she’s discovered below.
I’ve been considering what defines well-designed code this summer both via literature and my own experiences. It’s a big question so I’ve been taking my time, and slowly amassing a list of the characteristics of awesome code. However, this past week, the list has become longer and clearer in my mind because of the introduction of three-person code reviews. At this point, I’ve decided that the seven characteristics of stellar code are:
- Simplicity: the code takes the least convoluted and shortest way to resolve the issue.
- Readability: the code is formatted so it isn’t a pain to read. For example, I can assert with confidence that the C# ? operator can be easily replaced with an if/else statement just for the readability factor.
- Flexibility: if a piece of code is repeated frequently, can it be made into a method?
- Solidity: the piece of code being added is not a weak link in your software, but is in fact a well-cemented brink in your software’s foundation.
- Efficiency: the code is logical and fast.
- Clarity: the code can be read by someone else (or even you in a couple of days) and they’ll be able to figure out what it is doing and why it is useful.
- Elegance: code is beautiful when it displays the coder’s deep understanding of the code.
I’ll be the first to admit that I have a long way to go before I can call myself an awesome coder. But I do feel that through this internship and more immediately through the addition of three-person code reviews, I am getting closer. Prior to this sprint, reviews have involved two people: the code writer and the code reviewer. In general, the code writer presents their code and the reviewer gives their feedback. Changes are made and the code is integrated.
Three-person code reviews take a different tone. The reviewer has to explain what the code is doing to a third person, the audience. This means that the code needs to be readable and clear. The reviewer and the audience point out ways it can more flexible, solid, efficient, elegant, and simpler. For example, I’ve noticed that I tend to write out long lines of code instead of creating an auto property which is a more efficient method. Because of the code reviews, prior to submitting code, I check if there are appropriate opportunities to use this lesson.
Code reviews are undoubtedly a bit nerve-wracking. But, if you are open to it, each one is a learning experience and a stepping stone to becoming a better programmer!
Follow