I worked for a job that taught me how to document. I was actually a coder who fixed bugs for auto body software. What made my job easier was probably knowing what the file I was -- what exactly it was doing. I didn't love doing the job, but it taught me what I needed to know.<p>As I began developing for myself, I would often just not document my code, thinking the best: "Oh I'll know what this does when I see it." Add a dozen projects into the mix: "Yeah, I remember that.. what did it do?" I knew I had to start documenting again. I also figured: Why not document? If I ever need to go back to it or hire someone to work on something, I -- and they -- will not be so lost when looking at it.<p>So, how I document my code is by adding this template at the top of every page.<p><pre><code> // FILENAME: dashboard.php
// STATUS: ACTIVE
// PURPOSE: Shows basic information when user logs in
// NOTES: Dashboard will display the most recent transactions
</code></pre>
FILENAME lets me know what file I am in.<p>STATUS lets me know if this file is actively being used; or INACTIVE, for not being used at all, or SEMI-ACTIVE (usually for TEST files)<p>PURPOSE lets me know what exactly is the function of this file within the program I've built.<p>NOTES are optional, but these just let me know if there is any additional information I need.. such as "Admin use only" meaning this file is used by administrations, not regular users.<p>Those four keywords give me everything I should probably know about the file. You can add additional lines too, such as one that I might sometimes use: LOGIC. LOGIC explains exactly what the code is doing and how it works in more technical terms. (Grab user input, add to database, update Table1, Table2, and Table3 of database, return user back to Dashboard)<p>Before you even begin writing code in your file, you should start off with this template. It will keep you organized and make you feel more in control of your code. I mean, I've developed a few programs that have hundreds of files each, and the very first program I wrote: Very little documentation.<p>You feel like your code is going to crash, burn, and you won't be able to figure it out. By documenting, even if there are issues, you can pinpoint what it is doing and where, and that should lead you to the file you need to focus on.<p>The rest of the file is usually optional for commenting, though it is great practice to keep at it. If you think you can't pick up something from the code by reading about the file, than you may want to continue documenting throughout the file. I only document the remainder of the file if there is some complicated code in it.<p>I mean, after writing something that connect to the same database 100 times, I may have only documented the most used files that use that code. For smaller files, if I forget, I can always revert back to the major files to remind myself of what this code is doing.<p>Anyways, its up to you, but it also helps that if you ever decide to sell your code or someone wants to buy it from you, you've already done the work for them, and imo, it adds a lot of value to your code.