6 ms·

it seems that in real life, a really high-quality codebase is hard to come by I think a common misconception amongst mid-experienced programmers is that they c

it seems that in real life, a really high-quality codebase is hard to come by I think a common misconception amongst mid-experienced programmers is that they confuse look with quality. Reading clean written code gives you a feeling of control and also the feeling that someone must have thought about that program. It's reassuring. You have in front of you a code that gives you trust. When in fact, that code can be complete garbage. The look of the code doesn't matter, what matters is the program. In the abstract meaning of the term. You don't judge a code by reading it, but by running it in your head. Granted you have to understand it in order to do that. Once you understand the code, you run it in your head and that's when quality enter the scene because running it in your head is what you do all day when you code. Some says that you spend most of your time reading code. That's simply not true, the effort is definitely not in reading but in running the code in your head. Basically what I'm describing is a 2 by 2 matrix where there is one column for look bad, one for look good, one row for runs badly in the head and one for run smoothly in the head. Granted, the best may be when both the code looks right and runs right, but don't be mistaken, the real important and difficult part is whether or not it runs well in the head. A poor quality program may look good, but don't run well in the head. It's too complex or too confusing (in terms of logic, not in terms of presentation) or convoluted or simply wrong in terms of what it's supposed to do. On the other hand good quality code is code that surprises you by the way it runs. It's beautiful in terms of simplicity, it delivers a lot, it's small so that it fits well in the coder's head. And it may look like garbage which is not so important. You may wonder how to know very quickly the quality of a code base. Run part of it in your head. Contemplate the machinery. Try not to think to much about the language and how it's constructed in this language, try instead to contemplate it in an abstract manner. Be critic, and critic your critics.

Yajirobe 7y ago
dont u mean a 2x2 matrix
Izkata 7y ago
> by running it in your head. I have encountered far too many people who don't even realize this is a thing. I figure they must be doing it in some limited form and just aren't recognizing it as a skill that can be trained up, otherwise I'm not sure how they can do any development, but...
- penguat 7y ago
  I don't always run the code in my head exactly - i do something more important, which is consider the set of possible situations the code can be in, and look for problems.
- fiddlerwoaroof 7y ago
  I generally intentionally avoid running the program in my head because that requires too much context: I prefer to think about the change I want to make and the minimal set of preconditions that make the change valid.
- ThisIs_MyName 7y ago
  Running non-trivial code in your head is far too tedious for daily use. I'd much rather add debug checks for invariants when I want to confirm that the code works the way I expect it to.
  - AtlasBarfed 7y ago
    The human brain has, what, about 7 registers in medium term memory?
    - Izkata 7y ago
      5±3, if I remember right, but of indeterminate size. You can expand it to a couple dozen by moving up and down abstraction levels. An exercise: I have 36 letters for you to memorize, in order and without mistakes: "The quick brown fox jumped over the lazy dog" The sentence as a whole only uses 1 of those memory slots. As necessary, you can jump down one abstraction level to get 9 words, or again on a word-by-word basis to get the full 36 letters. Code is the same. For example, use multiple slots to understand loop conditions, then file it away in a single slot as the whole conceptual loop. Use multiple slots to understand the loop body, in the context of one element; file it away as well. Combine them into a one-slot conceptual understanding of the whole loop. So on and so forth. As you work with the conceptual models, you'll also end up with them in long-term memory and not have to do this reconstruction each time. This pattern can continue indefinitely, with conceptual models of whole packages and systems. Most will do it unconsciously at that level as they become familiar with a codebase, but it works at every level, and is the basis of "running code in your head".
namelosw 7y ago
> by running it in your head This is probably related to a factor named 'local reasoning', procedural programing tried to encourage this through procedure, OO tried to encourage this through encapsulation, and FP encourage this through purity. Basically the goal is when anyone look into a function, the reader can easily make sense of the code without moving around. For pure functional programming, to make sense of a function is to make sense of the branch under the acyclic calling tree of the function. The caller and sibling branches are always completely irrelevant. So that it will be much easier to run in people's head.
dfischer 7y ago
I love this description. Thank you.
0mbre 7y ago
I'd be curious to see an example of code that looks bad but yet is easy to grasp mentally. I do think these 2 features that you describe "easy to run mentally" and "look good" are correlated.
- quadcore 7y ago
  At least, I may agree with the following: bad program infers bad presentation but bad presentation does not infer bad program. In my career, I've seen many times peer programmers laugh at me when looking at my code and subsequently keep laughing, but in the other direction, as we were rolling over our competitors. Once, at a FANG, I've had the perfect setup where our team was doing the same project than another team. We did it in 12 month with 8 people, it took them 4 years with 18. Both projects started from scratch. Follows an example of code of my own. This is the perfect example because it looks like complete utter garbage and you will think I'm a beginner and I've never seen any good designed code. You are gonna laugh. While it is certainly not flawless, I'm pretty sure you would like to be on my team with that code if you'd knew more. All the features, to the tiniest nice subtlety are there, it has almost no bug and it's dead simple. Really dead simple. Please note that I code with sublime text which has multi cursor making duplicated code not so bad. So there is a lot of duplicated code. Again, I'm not saying the following code is flawless, I'm saying that despite its flaws, or even because of them, from my experience you'd prefer to be in my team. https://github.com/IndieRobert/example_code/blob/master/src/tr.cpp#L9877 https://github.com/IndieRobert/example_code/blob/master/src/...

Yajirobe 7y ago

dont u mean a 2x2 matrix

Izkata 7y ago

> by running it in your head. I have encountered far too many people who don't even realize this is a thing. I figure they must be doing it in some limited form and just aren't recognizing it as a skill that can be trained up, otherwise I'm not sure how they can do any development, but...

penguat 7y ago
I don't always run the code in my head exactly - i do something more important, which is consider the set of possible situations the code can be in, and look for problems.
fiddlerwoaroof 7y ago
I generally intentionally avoid running the program in my head because that requires too much context: I prefer to think about the change I want to make and the minimal set of preconditions that make the change valid.
ThisIs_MyName 7y ago
Running non-trivial code in your head is far too tedious for daily use. I'd much rather add debug checks for invariants when I want to confirm that the code works the way I expect it to.
- AtlasBarfed 7y ago
  The human brain has, what, about 7 registers in medium term memory?
  - Izkata 7y ago
    5±3, if I remember right, but of indeterminate size. You can expand it to a couple dozen by moving up and down abstraction levels. An exercise: I have 36 letters for you to memorize, in order and without mistakes: "The quick brown fox jumped over the lazy dog" The sentence as a whole only uses 1 of those memory slots. As necessary, you can jump down one abstraction level to get 9 words, or again on a word-by-word basis to get the full 36 letters. Code is the same. For example, use multiple slots to understand loop conditions, then file it away in a single slot as the whole conceptual loop. Use multiple slots to understand the loop body, in the context of one element; file it away as well. Combine them into a one-slot conceptual understanding of the whole loop. So on and so forth. As you work with the conceptual models, you'll also end up with them in long-term memory and not have to do this reconstruction each time. This pattern can continue indefinitely, with conceptual models of whole packages and systems. Most will do it unconsciously at that level as they become familiar with a codebase, but it works at every level, and is the basis of "running code in your head".

namelosw 7y ago

> by running it in your head This is probably related to a factor named 'local reasoning', procedural programing tried to encourage this through procedure, OO tried to encourage this through encapsulation, and FP encourage this through purity. Basically the goal is when anyone look into a function, the reader can easily make sense of the code without moving around. For pure functional programming, to make sense of a function is to make sense of the branch under the acyclic calling tree of the function. The caller and sibling branches are always completely irrelevant. So that it will be much easier to run in people's head.

dfischer 7y ago

I love this description. Thank you.

0mbre 7y ago

I'd be curious to see an example of code that looks bad but yet is easy to grasp mentally. I do think these 2 features that you describe "easy to run mentally" and "look good" are correlated.

quadcore 7y ago
At least, I may agree with the following: bad program infers bad presentation but bad presentation does not infer bad program. In my career, I've seen many times peer programmers laugh at me when looking at my code and subsequently keep laughing, but in the other direction, as we were rolling over our competitors. Once, at a FANG, I've had the perfect setup where our team was doing the same project than another team. We did it in 12 month with 8 people, it took them 4 years with 18. Both projects started from scratch. Follows an example of code of my own. This is the perfect example because it looks like complete utter garbage and you will think I'm a beginner and I've never seen any good designed code. You are gonna laugh. While it is certainly not flawless, I'm pretty sure you would like to be on my team with that code if you'd knew more. All the features, to the tiniest nice subtlety are there, it has almost no bug and it's dead simple. Really dead simple. Please note that I code with sublime text which has multi cursor making duplicated code not so bad. So there is a lot of duplicated code. Again, I'm not saying the following code is flawless, I'm saying that despite its flaws, or even because of them, from my experience you'd prefer to be in my team. https://github.com/IndieRobert/example_code/blob/master/src/tr.cpp#L9877 https://github.com/IndieRobert/example_code/blob/master/src/...