7 ms·

Clean code is code that does what you expect it to do without many surprises. It is simple, not clever. Effortless to follow. Each part handles one idea at a ti

Clean code is code that does what you expect it to do without many surprises. It is simple, not clever. Effortless to follow. Each part handles one idea at a time, at the same abstraction level. Doesn't force you to mentally juggle many balls at the same time. The code often tells you a story, it communicates how the programmer (author) described the problem, the solutions and the trade-offs. Very similar to writing. Maybe it is a vague term. But it is not an excuse to write "bad" code. Perhaps every team need to have a "definition of clean code" for themselves.

brianmcc 5y ago
>> It is simple, not clever. Effortless to follow. This is the crux of it for me. I want to read code not solve code. If I have to "figure out what's going on" then it's not great code.
- RangerScience 5y ago
  YES. An older Rubyist once told me: "Code is programmers communicating with other programmers."
- andruby 5y ago
  Exactly. “Write code for humans first”.
- smaudet 5y ago
  An entirely subjective measure. I want to solve problems, not read code. I can read your code and understand it, but then still have to solve it to understand what problem you are solving.
theonething 5y ago
In my work history, I've never come across code like this, especially "effortless to follow". All the codebases I've worked with have been head scratch causing balls of mud. Am I unlucky or is what you are describing the rare exception?
- EduardoBautista 5y ago
  Most large software projects have some bad code in it. If it’s all bad, then there is probably an architectural problem, poor code review practices, and/or corners are being cut to meet deadlines.
- RangerScience 5y ago
  Both. Head-scratching balls of mud is, IMO, below average; but that lofty height of code described is an extreme rarity. 100% recommend having your own hobby project so you can reach it.
  - bryanrasmussen 5y ago
    >but that lofty height of code described is an extreme rarity. I would say lofty height only possible in following conditions: A model of reality / problem domain that the company has created themselves that does not have to integrate with any other company, or have to follow any laws or regulations. For example let us suppose you create a company for users to send messages to each other using your app. You can totally control everything in your environment - just your app, your definition of users, you definition of messages. But once you need to connect your app to other apps doing similar things but differently than your model you are going to hit edge cases, and if you have to think about making your app work on multiple environments and there are problems as there generally are you will start to be less lofty, and then after you have been going a while you try to enter a market with regulations, or regulation is handed down affecting your app. Things are getting less lofty quickly at that point. on edit: grammar
- antris 5y ago
  There definitely are codebases that are easy to follow. But it requires a team that is committed to aggressively refactoring even the smallest of code smells, usually before even committing it. It also requires a team that is dedicated to its professionalism and not bend into a manager's will of refactoring being a time waste. But when your team is committed to code quality, holy hell is it satisfying, easy and fast to work with. It really is like night and day. If you have not experienced the difference - I'm sorry to say - then you've just not worked with a high-quality team.
usrbinbash 5y ago
> The code often tells you a story It sure does. Unfortunately, the genre is quite often Lovecraftian Horror.
tehnub 5y ago
What you can easily follow though is largely a function of your programming background. An experienced Haskell programmer will have no issue following all kinds of “.” and “$” usages, but one who is not experienced with Haskell, even if they learn what the syntax means, will have trouble following it.
- autoexec 5y ago
  I think how clearly you write and comment can matter just as much. I'm proud to say I've had situations where people with near zero programing experience were able to make some quick changes to get programs I'd written in perl working again following sudden changes. I think the more you know the easier it gets, but a reasonably capable end user with little to no experience in programing can surprise you if you take the time to try keeping things as easy to follow as possible. I do it because I can't trust myself to remember what I was doing even with projects completed only a few months ago.
andruby 5y ago
“Effortless to follow” is eloquently put. When I interview candidates during recruiting I often ask the open ended question “what is good code for you” as it gets people talking. There is rarely a wrong answer. Usually, there is a difference in answers between more junior and more senior programmers. More senior candidates focus more on the readability & maintainability, while more junior programmers focus on accuracy, speed, following style-guides etc. For me “good code” is code that is easy to change. Most things follow from that: easier to understand makes it easier to change. Do 1 thing (SRP), makes it easier to change, etc..
- baobabKoodaa 5y ago
  > When I interview candidates during recruiting I often ask the open ended question “what is good code for you” as it gets people talking. There is rarely a wrong answer. I don't mean to be snarky, but if there is rarely a wrong answer to this question, then it doesn't sound like a good interview question to me. Having been through a bunch of interviews, I don't understand the obsession over clean code. I would understand it better if these questions helped pass/fail candidates or rank candidates (to help decide salary or position inside company). But it doesn't seem to be the case. It seems like the feel-good talky-talk over clean code in interviews is nothing but a waste of time (with "rarely a wrong answer").
  - andruby 5y ago
    > I don't mean to be snarky No worries. I should’ve included it more clearly in my comment. I use the question to gauge seniority and experience to help determine salary proposal. As I mention, there is typically a difference in the answer of a junior programmer (or someone who’s used to being a solo-dev) vs a senior dev that worked on larger projects with bigger teams. Moreover, the question is about _good_ code, not clean code.
gopher_space 5y ago
> Perhaps every team need to have a "definition of clean code" for themselves. All of these concepts are attempts to codify practices that worked really well for specific people in specific circumstances. Like Egg Shen, we take what we want and leave the rest.
klabb3 5y ago
Agree with everything. > Doesn't force you to mentally juggle many balls at the same time. Coincidentally, this is how I define complexity colloquially for my own purposes. It is extremely general, stupidly practical, and literally rooted in brain chemistry. Applying this to programming is still a delicate art, since it depends on what the reader of the code wants to do. Most people focus on clean modules (e.g. a 100 LOC unit testable data structure), but that's only helpful when the next person wants to modify or replace a single module, which is generally the easy part. Most times when I'm groking a new code base is spent understanding data flow across a complex hierarchy of modules – usually, the dumber and flatter, the easier this task becomes.

brianmcc 5y ago

>> It is simple, not clever. Effortless to follow. This is the crux of it for me. I want to read code not solve code. If I have to "figure out what's going on" then it's not great code.

RangerScience 5y ago
YES. An older Rubyist once told me: "Code is programmers communicating with other programmers."
andruby 5y ago
Exactly. “Write code for humans first”.
smaudet 5y ago
An entirely subjective measure. I want to solve problems, not read code. I can read your code and understand it, but then still have to solve it to understand what problem you are solving.

theonething 5y ago

In my work history, I've never come across code like this, especially "effortless to follow". All the codebases I've worked with have been head scratch causing balls of mud. Am I unlucky or is what you are describing the rare exception?

EduardoBautista 5y ago
Most large software projects have some bad code in it. If it’s all bad, then there is probably an architectural problem, poor code review practices, and/or corners are being cut to meet deadlines.
RangerScience 5y ago
Both. Head-scratching balls of mud is, IMO, below average; but that lofty height of code described is an extreme rarity. 100% recommend having your own hobby project so you can reach it.
- bryanrasmussen 5y ago
  >but that lofty height of code described is an extreme rarity. I would say lofty height only possible in following conditions: A model of reality / problem domain that the company has created themselves that does not have to integrate with any other company, or have to follow any laws or regulations. For example let us suppose you create a company for users to send messages to each other using your app. You can totally control everything in your environment - just your app, your definition of users, you definition of messages. But once you need to connect your app to other apps doing similar things but differently than your model you are going to hit edge cases, and if you have to think about making your app work on multiple environments and there are problems as there generally are you will start to be less lofty, and then after you have been going a while you try to enter a market with regulations, or regulation is handed down affecting your app. Things are getting less lofty quickly at that point. on edit: grammar
antris 5y ago
There definitely are codebases that are easy to follow. But it requires a team that is committed to aggressively refactoring even the smallest of code smells, usually before even committing it. It also requires a team that is dedicated to its professionalism and not bend into a manager's will of refactoring being a time waste. But when your team is committed to code quality, holy hell is it satisfying, easy and fast to work with. It really is like night and day. If you have not experienced the difference - I'm sorry to say - then you've just not worked with a high-quality team.

usrbinbash 5y ago

> The code often tells you a story It sure does. Unfortunately, the genre is quite often Lovecraftian Horror.

tehnub 5y ago

What you can easily follow though is largely a function of your programming background. An experienced Haskell programmer will have no issue following all kinds of “.” and “$” usages, but one who is not experienced with Haskell, even if they learn what the syntax means, will have trouble following it.

autoexec 5y ago
I think how clearly you write and comment can matter just as much. I'm proud to say I've had situations where people with near zero programing experience were able to make some quick changes to get programs I'd written in perl working again following sudden changes. I think the more you know the easier it gets, but a reasonably capable end user with little to no experience in programing can surprise you if you take the time to try keeping things as easy to follow as possible. I do it because I can't trust myself to remember what I was doing even with projects completed only a few months ago.

andruby 5y ago

“Effortless to follow” is eloquently put. When I interview candidates during recruiting I often ask the open ended question “what is good code for you” as it gets people talking. There is rarely a wrong answer. Usually, there is a difference in answers between more junior and more senior programmers. More senior candidates focus more on the readability & maintainability, while more junior programmers focus on accuracy, speed, following style-guides etc. For me “good code” is code that is easy to change. Most things follow from that: easier to understand makes it easier to change. Do 1 thing (SRP), makes it easier to change, etc..

baobabKoodaa 5y ago
> When I interview candidates during recruiting I often ask the open ended question “what is good code for you” as it gets people talking. There is rarely a wrong answer. I don't mean to be snarky, but if there is rarely a wrong answer to this question, then it doesn't sound like a good interview question to me. Having been through a bunch of interviews, I don't understand the obsession over clean code. I would understand it better if these questions helped pass/fail candidates or rank candidates (to help decide salary or position inside company). But it doesn't seem to be the case. It seems like the feel-good talky-talk over clean code in interviews is nothing but a waste of time (with "rarely a wrong answer").
- andruby 5y ago
  > I don't mean to be snarky No worries. I should’ve included it more clearly in my comment. I use the question to gauge seniority and experience to help determine salary proposal. As I mention, there is typically a difference in the answer of a junior programmer (or someone who’s used to being a solo-dev) vs a senior dev that worked on larger projects with bigger teams. Moreover, the question is about _good_ code, not clean code.

gopher_space 5y ago

> Perhaps every team need to have a "definition of clean code" for themselves. All of these concepts are attempts to codify practices that worked really well for specific people in specific circumstances. Like Egg Shen, we take what we want and leave the rest.

klabb3 5y ago

Agree with everything. > Doesn't force you to mentally juggle many balls at the same time. Coincidentally, this is how I define complexity colloquially for my own purposes. It is extremely general, stupidly practical, and literally rooted in brain chemistry. Applying this to programming is still a delicate art, since it depends on what the reader of the code wants to do. Most people focus on clean modules (e.g. a 100 LOC unit testable data structure), but that's only helpful when the next person wants to modify or replace a single module, which is generally the easy part. Most times when I'm groking a new code base is spent understanding data flow across a complex hierarchy of modules – usually, the dumber and flatter, the easier this task becomes.