3 ms·
"would you trust a Word document or a .cpp file when everything is on fire and you need to figure out a system's behavior?" There's a bigger philosophical prob
by niggler 14y ago
"would you trust a Word document or a .cpp file when everything is on fire and you need to figure out a system's behavior?"
There's a bigger philosophical problem here. If your development cycle is code -> comment -> code -> comment ... (where you write code and then comment), then your criticism is fair. But the right way is to comment first. When you describe what you want in words, then you or anyone else can go back and evaluate if the code matches the words.
(In my experience, 90% of bugs stem from developers thinking one thing and implementing something different, and these could be avoided if you had a normative document)
It's like writing a paper: you outline, sketch out what you want to say, and then actually start crafting sentences. The outline should guide your paper, and if there's a problem you first update the outline.
- swanson 14y agoWrite a test first -> figure out how you want to interact with the code -> then actually start crafting code. And the test can actually be executed. I used to do the "sketch it out" a lot more, but I think Test-First is a better approach.
- niggler 14y agoTest-first is also broken, because you end up crafting code that suits the test coverage. https://github.com/shtylman/node-int/issues/1#issuecomment-12757935 https://github.com/shtylman/node-int/issues/1#issuecomment-1... is an example of an issue which came from an implementation without 100% test coverage. I claim that unless you know every single way in which a function is used, and even if you did, you can't design tests to cover 100% of use cases.