A Question about planning

So, Q2 in the Mid-term Quiz that follows this video (SPOILER ALERT) says something like "Before we even touch the keyboard, what is the minimal planning required"
Is this not better served by a bunch of comments on the front page of the Solution? then you can build the code around the comments, and not mislay Requirement files / bits of paper?
Also having the NO list in the solution itself would help if you want to do a v2 of the game.

I often find when I’m designing circuits that a Design Doc that is constantly updated, and therefore shows the iterations of what you’re trying to achieve is at least as valuable as the final schematic.


I’m not sure what you mean about the “front page of the Solution”, but I think you mean the main.cpp file. If that’s the case, then you do not want requirements stated in your code. Your code should only be the functionality of your program, that’s it. When you write comments in the code, is to provide a higher level view of the logic or functionality of the actual code.

It’s better to have requirements in a separate document, like your Design Doc, to keep it updated and review it from time to time. You can’t start a game without setting yourself an objective of what you are trying to achieve. By having clear what your requirements and limitations are, it is easier to write your code.

An analogy would be that you probably label a physical circuit just to identify it but you don’t actually write what the purpose of that circuit is all over it, the description just wouldn’t fit. Well, in order to keep your code clean and concise, you just describe what a particular piece of code does, but the purpose of the program as a whole is defined in the requirements.

ok, so what I’m getting at is just an extended use of the TODO statements that we’ve been using. If it’s good enough for breaking down sub-tasks, and we’ll be doing it anyway, then it’s good enough to break down the main task.
Using your analogy, it’s like drawing a block diagram before the design starts - a not uncommon procedure on complex circuits / systems
My main point was that then you wouldn’t lose bits of paper, or links to files (if say your internet was down).
Any changes that you make to the project then can be documented inside the project (I guess it’s even easier to follow if you use the Version Control stuff from Section 3)

Privacy & Terms