Start working on COR notes#35
Conversation
tekknolagi
commented
Jan 31, 2024
- Some edits for lecture 1
- Add Falsehoods
- wip
| have received, injuring several people and killing several people. | ||
|
|
||
| On a less serious note, bugs can lead to revenue loss, or wasting people's | ||
| On a less serious note, bugs can lead to data loss, or revenue loss, or wasting people's |
| happy little accidents. You won't always be writing code for small projects, | ||
| though. | ||
| though. You might be writing video game software and [accidentally delete | ||
| people's home |
There was a problem hiding this comment.
This kind of code is hard to test so I wonder if it is worth writing a "don't just look where the light is" kind of suggestion here... but I don't know what the point is
| directories](https://github.com/valvesoftware/steam-for-linux/issues/3671). | ||
| That would be a huge problem. | ||
|
|
||
| So let's assume we want to reduce the quantity of bugs as much as possible. The |
There was a problem hiding this comment.
"want to end up with as few bugs as possible" flows better, I think.
|
|
||
| Some time ago, Patrick McKenzie wrote a blog post called [Falsehoods | ||
| Programmers Believe About | ||
| Names](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/). |
There was a problem hiding this comment.
nit: make this (and the one below) named links so they don't disrupt text flow?
| Names](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/). | ||
| In it, he lists common but false assumptions about names that lead to bugs in | ||
| software. Bad name handling is especially tricky because it can disenfranchise | ||
| entire classes of people. Imagine not being able to sign up for a service |
There was a problem hiding this comment.
| entire classes of people. Imagine not being able to sign up for a service | |
| entire groups of people. Imagine not being able to sign up for a service |
| of domains and common problems in software. While they are probably not all | ||
| worth reading and understanding in totality, it is certainly worth becoming | ||
| more mindful about the assumptions you bring to the table and accidentally bake | ||
| into software. |
There was a problem hiding this comment.
I think this can be shortened and made more direct, but I'm struggling to suggest how. Will come back to it.
| } | ||
| ``` | ||
|
|
||
| This function alone had several cases: the node is `NULL`; the root has the |
There was a problem hiding this comment.
s/had several cases/must tolerate several different inputs/ or something? I think we should be more precise about what we mean by a "case".
| expected value; the node has no children; the node has one child; the node has | ||
| two children. Even though you probably should write unit tests, that's a | ||
| manageable number of cases to test manually. | ||
| manageable number of cases to test manually... for now. Are you going to |
There was a problem hiding this comment.
Replace "Even though…" with "It might be tempting to test those inputs manually: there aren't that many, and writing tests takes time. But are you going …"? Just rewording to flow better, no technical complaints with existing wording.
| all*[^tdd-orthodoxy]. What do you type first? | ||
|
|
||
| [^tdd-orthodoxy]: This is what the Test Driven Development orthodoxy preaches. | ||
| I have my personal opinions about that---I think starting test first |
There was a problem hiding this comment.
| I have my personal opinions about that---I think starting test first | |
| I have my personal opinions about that---I think starting test-first |
|
|
||
| ### What even is a specification? | ||
|
|
||
| We're probably going to start some fights by saying this, but a *specification* |
There was a problem hiding this comment.
If you say it'll start fights, you should explain why.
| Neat. The tests passed. But what does that *mean*? | ||
|
|
||
| Ignore the particulars of the syntax and the names of things for a moment. | ||
| Focus on the function calls to `isEven`. |
There was a problem hiding this comment.
| Focus on the function calls to `isEven`. | |
| Focus on the function calls to `isEven()`. |
I tend to use parens to disambiguation function names from symbol names, but feel free to ignore if that's not your precedent here.
| standard that allows the two compilers to implement a behavior differently. | ||
| of writing code, the world changes. Time passes, bits rot, and people die, no | ||
| matter how much we try to stop it. Take a moment to call your loved ones and | ||
| tell them how much they mean to you. |
|
|
||
| ## Lecture 4.5 | ||
|
|
||
| ### Strategies for isolating units |
There was a problem hiding this comment.
If we talk about mocking here, let's speak critically about it. It has its uses, but it's not a magic bullet---and in Tom's opinion, most real-world implementations are quite lacking and often require the programmer to make non-test code harder to read.