3 ms·

This whole "read code" thing ("write code that's easy to read", "learn to read code") is imprecise at best. Whats important is to learn code. You want to learn

This whole "read code" thing ("write code that's easy to read", "learn to read code") is imprecise at best. Whats important is to learn code. You want to learn to write code that's easy to learn (not easy to read). And you want to learn to learn code. If you write code that's easy to learn, and if you learn to learn code, you'll simply remember more code. The more code you know, the more productive you gonna be. That's because at one end of the spectrum, you know nothing about the code and you simply cant do nor solve anything. And at the other end of the spectrum, you know all the code, in which case you gonna be able to do whatever you want by definition: analyse it, expand it, rewrite it, refactor it, talk about it, fix it, etc. This also explains why you want to write code with fewer lines of code (or fewer AST nodes): the more lines (or AST nodes), the more you have to learn. The more you have to learn, the less you know, the less you know, the closer you are from the bad end of the spectrum.

tiogemini 9y ago
Any tips on how to learn code?
- unoti 9y ago
  Some ideas: Spend time learning how to do thenusers jobs, understanding how thenusers use the system. Go into the code, pick one spot, and understand what it does very well. For that one spot, make a list of all the external things it uses that you don't know about. Go to each spot in that list and make notes about how that thing works, indented under the list item. Repeat that process recursively for a level or two, or as many as you have patience for. Pair program with someone else who knows the system. Write unit tests.
- corysama 9y ago
  The way I make myself familiar with new code is to find some process of interest and write out a psuedo code stack trace from the trigger through execution. So, function names, relevant params, leave out error handling and irrelevant branches. If a step is async, reset indentation and annotate the "stack" with "and later..." This process can collapse large amounts of code into a hopefully a single page of text that can be well understood. Without it, I find it very difficult to keep all of the relevant code in my head when it's spread across the code base.
  - tiogemini 9y ago
    I like it! I'll have to try that the next time I encounter some new code. A few questions: * Do you worry about file names? * Do you use names from the code or your own shorthand? * How do you handle conditionals?
    - corysama 9y ago
      No filenames. Just functions. Collapsing info from multiple files is a big part of the goal. IDE search works well enough that I rarely know what file I'm in. I use names from the code. I do want to be able to locate the code later. I try to omit most conditionals. The goal is to show the path of interest, not all possible paths. Some conditionals are interesting though --very likely errors, process cancellations, scary bug-tempting edge cases.
- motet_a 9y ago
  Reading automated tests and doing extensive searches in the codebase (with recursive `grep`s) is often helpful. If you use an IDE with a go-to-definition function, it can replace grep.

tiogemini 9y ago

Any tips on how to learn code?

unoti 9y ago
Some ideas: Spend time learning how to do thenusers jobs, understanding how thenusers use the system. Go into the code, pick one spot, and understand what it does very well. For that one spot, make a list of all the external things it uses that you don't know about. Go to each spot in that list and make notes about how that thing works, indented under the list item. Repeat that process recursively for a level or two, or as many as you have patience for. Pair program with someone else who knows the system. Write unit tests.
corysama 9y ago
The way I make myself familiar with new code is to find some process of interest and write out a psuedo code stack trace from the trigger through execution. So, function names, relevant params, leave out error handling and irrelevant branches. If a step is async, reset indentation and annotate the "stack" with "and later..." This process can collapse large amounts of code into a hopefully a single page of text that can be well understood. Without it, I find it very difficult to keep all of the relevant code in my head when it's spread across the code base.
- tiogemini 9y ago
  I like it! I'll have to try that the next time I encounter some new code. A few questions: * Do you worry about file names? * Do you use names from the code or your own shorthand? * How do you handle conditionals?
  - corysama 9y ago
    No filenames. Just functions. Collapsing info from multiple files is a big part of the goal. IDE search works well enough that I rarely know what file I'm in. I use names from the code. I do want to be able to locate the code later. I try to omit most conditionals. The goal is to show the path of interest, not all possible paths. Some conditionals are interesting though --very likely errors, process cancellations, scary bug-tempting edge cases.
motet_a 9y ago
Reading automated tests and doing extensive searches in the codebase (with recursive `grep`s) is often helpful. If you use an IDE with a go-to-definition function, it can replace grep.