752 reads

Why Do You Care About Conciseness of The Code?

by Oleksii FedorovOctober 2nd, 2018

Too Long; Didn't Read

Debby and Walter are working as software engineers on the same team. The other day, they had this awesome conversation about the conciseness of the code.

Company Mentioned

featured image - Why Do You Care About Conciseness of The Code?

Debby and Walter are working as software engineers on the same team. The other day, they had this awesome conversation about the conciseness of the code.

TL;DR

Less code to do the job.
Reduces the pain of useless repetition that you can’t remove.
When you can’t work with concise code (because your programming language is not brief by design), then your sense of duplication/repetition becomes too numb. That affects noticing duplicate code and noticing repeating actions people (and you!) perform, that should be automated. Thus becoming numb to duplication/repetition makes for a worse programmer.
When there is too much boilerplate, then it is harder to understand (and find bugs in) the core logic of the code. It serves as noise and distraction.
When you are accustomed to filtering out the noise like boilerplate, then it becomes harder to see mistakes in said boilerplate.
If you can optimize your readability/understandability without sacrificing the easiness of writing — by all means, do!
Conciseness can be overdone to the point where it harms readability, understandability, and ease of writing. Make sure to maintain a right healthy balance.

The dialogue itself

Debby: Hey Walter!Walter: Hi Debby!

Debby: So, why do you care about concise syntax so much?Walter: Concise syntax allows me to write much less code to achieve the same task.

Debby: I cannot argue with that. It is by definition so. Anything more?Walter: Concise syntax reduces the pain of useless repetition.

Debby: Why useless repetition is painful for you?Walter: One of the main pillars of the programmer’s job is to eliminate/automate repetitive tasks. If your job is to reduce repetition, then you notice repetition where other people would not. If you see repetition, and your job is to eliminate it, then you are going to feel the pain when you notice it.

Debby: And what do you do if your programming language itself has a lot of uselessly repetitive constructs that you can’t do anything about?Walter: If your code itself has repetition on the language level, and you can’t do anything about it, then you are likely to feel such a pain every time you write such a statement in the code.

Debby: Interesting. Can’t you make yourself numb to that pain just by ignoring the repetition for enough time?Walter: Yes you can. And let’s re-examine what will happen in this case. Given that the job of a programmer is to eliminate useless repetition. Then what will happen if they become numb to some type of redundancy?

Debby: If they become numb to a single type of repetition, then such programmer is likely to become numb to other kinds of redundancy, as well.Walter: And what that implies, given that detecting the repetition is one of the programmer’s job pillars?

Debby: If the programmer is numb to more types of repetition, and if their job is to detect and eliminate such duplication, then they must have become a worse programmer.Walter: Exactly.

Debby: Alright. Point taken. Anything more on why do you care about concise syntax?Walter: Well, concise (to an extent) code is easier to read and understand.

Debby: Why concise code is easier to read and understand?Walter: If you remove all the boilerplate (useless repetition, and such) from the piece of code, then what do you have left?

Debby: What is essential to read and understand.Walter: So what would happen if we did have a lot of boilerplate? Would it be easy or hard to find what is important about this piece of code?

Debby: If we have a lot of boilerplate, then we will have to concentrate hard enough to find what is hidden in it. In some cases, it will be like looking for a needle in the haystack.Walter: Exactly my point.

Debby: Would you agree that it is possible to become accustomed to the same kinds of boilerplate over time and filter them out automatically when reading the code?Walter: I certainly agree. And I think it will still cause some mental load. Additionally, if you are conditioned to filter the boilerplate, and the bug you are trying to fix is hiding in the boilerplate, then it would be much harder to find it.

Debby: Interesting point. Sometimes the boilerplate is forced on us programmers, right? Like what do I do in Java to avoid useless and obvious boilerplate?Walter: When I have to use Java, I usually use Lombok compiler plugin/library to reduce the useless boilerplate to a minimum. On other projects, where I have a choice, Kotlin worked quite well. If you want to get started with Kotlin, read this tutorial.

Debby: Thank you for the link. I’ll take a look later! Anyways, would you agree then that the code with too much boilerplate has more possibilities for bugs?Walter: Certainly. It can have bugs in what is important — the core logic of the piece of the code. And it can have flaws in the boilerplate that is accompanying the piece of code. If that is true, then the piece code without boilerplate can have bugs only in its core logic.

Debby: And that means that it will be easier to debug because we have fewer possibilities.Walter: Exactly.

Debby: Alright. We are talking so much about reading and understanding of the code now. But programmers job is to write code. Is that true?Walter: Yes, technically.

Debby: Then why is it essential to have the code easy to read and understand? Wouldn’t it be much better to have the code easy to write?Walter: Wonderful question! Before any programmer writes the code, they always have to read and understand the existing code. The only exception is “day zero” of the new code base when there is no code written yet.

Debby: So what is more critical then: ease of reading or writing the code?Walter: Okay. Let’s do a thought experiment. Let’s assume that we have a piece of the code that is hard to read and understand. How easy or hard would it be to make a change to it (technically, write the code)?

Debby: Well, as you said, if programmers have to read the code before they can write it, and if the code is hard to understand, then it must be hard to make a change (or hard to write the code).Walter: That’s right! Now let’s imagine a slightly different situation. Let’s assume that we have a piece of the code that is easy to read and understand. How easy or hard would it be to code the change in it?

Debby: I am not sure.Walter: Why are you not sure? Tell me what you are thinking and what assumptions are you making.

Debby: Okay. If programmer need to read and understand the code before writing, and it is easy to read and understand the piece of the code in question, then the difficulty of writing the code is not bound by reading and understanding, but it is bound by the process of writing itself. And I don’t have enough information to say if that process will be hard or easy. That is why I said, “I am not sure.”Walter: You are right! If the code is hard to read and understand, then, no matter how hard or easy the change that is needed, it will be tough to do. And if the code is easy to read and understand, then it all depends on the kind of change that is needed.

Debby: So if in this particular case the change was really simple, then the difficult to understand code would have made it a difficult change, and the easy to understand code would have kept the change easy. Fascinating idea.Walter: And if in this particular case the change was hard to make, then the hard to read code would only make things worse, and easy to understand code would have kept the change as hard as it is.

Debby: I conclude that the hard to read and understand code is always making the job of a programmer harder. Now I see why you are making it a priority over easiness of writing the code.Walter: That is not everything!

Debby: Yeah? Go on.Walter: In my experience, I write 5–15 times less code than I read. So readability and understandability have much higher priority.

Debby: I see. You said the phrase “concise to an extent.” What do you mean by that?Walter: In the source code it is easy to make some code much more concise at the expense of readability and understandability.

Debby: Oh, and that would conflict with the original premise of making the code easier to read and understand, wouldn’t it?Walter: It certainly would.

Debby: Can you expand “concise to an extent?” What can I trim from the code to make it more concise, and what can I not?Walter: Since we want to communicate the core logic of the piece of code effectively, then we shouldn’t trim any of parts of such logic. And we should cut everything else, what is obvious, what is repetitive, and what is boilerplate.

Debby: Any more reasons why you care about conciseness?Walter: I think that about covers it, or at least I can’t think of anything more right now.

Debby: Alright. Thank you, now I understand the value of the concise code.Walter: You are welcome. Goodbye.Debby: Goodbye.

Conclusion

Why should you care about the conciseness of your code?

Less code to do the job.
Reduces the pain of useless repetition that you can’t remove.
When you can’t work with concise code (because your programming language is not brief by design), then your sense of duplication/repetition becomes too numb. That affects noticing duplicate code and noticing repeating actions people (and you!) perform, that should be automated. Thus becoming numb to duplication/repetition makes for a worse programmer.
When there is too much boilerplate, then it is harder to understand (and find bugs in) the core logic of the code. It serves as noise and distraction.
When you are accustomed to filtering out the noise like boilerplate, then it becomes harder to see mistakes in said boilerplate.
If you can optimize your readability/understandability without sacrificing the easiness of writing — by all means, do!
Conciseness can be overdone to the point where it harms readability, understandability, and ease of writing. Make sure to maintain a right healthy balance.

In the recent years, I think I’ve found the programming language that strikes a right balance of being concise, simple to read/understand, and easy to write in.

This language is Kotlin. And I’ve written 350-pages hands-on tutorial as a 4-part e-book. If you are curious to learn it, download the Ultimate Tutorial: Getting Started With Kotlin.

Thank You

Thank you for reading! Tell me in the comments what do you think about this blog post: about how it is written and which ideas it contains.

If you want to make me happy, then you can give me claps on Medium (did you know you can give multiple?) and share it with your friends, on social networks, hacker news, Reddit, etc.