Once again, started programming at an early age, developed certain habits. I don’t actually know where these habits came from. They might well have come from me getting fed up with writing a couple thousand lines of HTML to encompass all my various fan postings and whatever else I was working on at the time. I was fourteen, and it was probably X-Files related. The habits I am about to describe to you are not necessarily either best or worst practices, but they are my practices, and if you find them useful feel free to adopt them and work them into your own coding life and habits.
Commenting! I am assured by my mother, who has been programming for almost as long as I’ve been alive (as of this writing), that commenting your code is a good and helpful thing to do. Since people who are not me are now looking at my code I’ve toned down the editorializing a bit but you may still occasionally see an f-bomb in my code comments. A helpful comment both to Future You and to other people who may have reason to take a look at your code is one that concisely and clearly explains what the preceding line does. For preceding line you may also substitute preceding method, preceding block. You might also put a line of comment or three at the top of a file indicating what the file does. Basically, what I do is read over my code and after every couple sentences of saying “this code does this” I write a comment to that effect. This also helps by doing half your rubber duck debugging for you; you can read along with your comments and make sure that line, block, or piece of code does what you said it does. F-bombs and editorializing like “Once you put it in it stays in the act forever” are optional, just don’t put in so much of them that it crowds out the code and the useful comments.
Scrap files! The tricky part to scrap files is remembering what they were in the first place. In some projects I have only a file called “scrapcode.txt”, so it doesn’t interfere with the running of any of the parts of the project. I surround each portion of code I paste in there with something nice and eye catching, like a row of &’s or #’s, and label it. This might be “Capybara Doesn’t Like This”, or “Potential Method For Adding Object1 to Object2”; the purpose of the label is to remind me why this is there in the first place. This is a common theme in my habits, I need to be able to read, immediately, why this thing is here. Conciseness and clarity of language will come with time though.
Scrap files are useful because you might want to test out a different way to achieve a result, but you don’t want to lose the code. And you don’t necessarily want to paste it in a notepad or text file elsewhere on your computer, because what if your computer shuts down abruptly? Or what if you have to leave your desktop, you come back, you finish up what you were working on and start closing windows and come across this now orphaned text file with a bit of code in it? Did you need that? Did it serve its purpose? You may not remember! And this is vastly annoying, so I get around it (mostly) with a scrap file. I have to periodically go through it to discard pieces of code that have definitely served their purpose, but it helps keep it all in one place and relatively neat.
Dev Logs! Pretty much what it says on the tin. Having never worked as a programmer officially I can’t say if this is a required practice in most places or not, but as I’m working my way through school and the projects therein and thereof, I can say it’s very useful to me as a programmer and developer. It helps me both to figure out where I am in the process and what I’ve done, and also works as a larger medium in which to write down everything that’s happened in every version. For example, if I don’t want to write out everything I did on May 20th but I don’t want that git commit to go naked and uncommented, I can simply say “see dev log” and then I will know I wrote down an expanded list of updates, debugging, attempts or cleanups or whatever else I did.
Project Notes! This is different from dev logs mainly in that dev logs are for the day to day log of things, and that only. Project notes get cluttered enough on their own, it’s helpful to me to separate them into two files, usually md files at this point although in the past they were text files. In the old, pre 2nd millennium days. Project notes usually contain project objectives, stretch goals, if it’s an assigned project it will have the assignment requirements, if it’s an independent project I’m working on with other people it might have point of contact or contact information, it’ll have a Bug Hunt list (although if the whole thing gets to be too big, Bug Hunt definitely goes in its own file too) (we hope there aren’t that many bugs but it happens to everyone). It might also have links to specific pages that have documentation I know I’m going need later, or a rough text-based sketch of a project map.
Non computer related habits I try to get into include keeping a water bottle on my desk, taking a sip from it when I feel like it. It doesn’t have to be filled with water, obviously, but water is my drink of preference so I have a liter of it by my desk at all times. And it’s in a spout bottle because the last thing you want is to spill beverage all over your keyboard when you’re in the coding zone. In order to be kinder to my circulatory system I try to get up every time I get frustrated with my code, walk around the area or (since I’m working from home, I don’t advise this in an office setting unless they’re one of those places with ping pong tables in the work area that I’ve heard so much about) do some exercise, lift some free weights. Sometimes moving around and changing your visual perspective can also change your perspective on your code, jar something loose. Sometimes exercise increasing the blood flow can also increase the blood flow to the brain for a positive effect, and it doesn’t have to be anything a personal trainer would formally recognize as exercise. It could be putting on some music and dancing. Related to that, try not to code on an empty stomach. That doesn’t mean always be eating, but definitely remember when the last time you had a food was, and if it was more than five hours ago that’s too long. The brain runs on, among other things, glucose. Keep it topped up and it’ll be much more help to you.
These are most of the habits I’ve developed over the last We’re Not Going To Talk About It years of doing web scripting, programming, poking around in computer languages learning them for my own amusement. If you’re new to thinking about code and programming and creating things through computer logic, I encourage you to practice explaining your code to yourself and working on making it concise and clear. It doesn’t have to be in comments or any of the formats I discussed here! Being able to explain your code will help you understand the code, and will help you reassure yourself that you do understand it. Also, when you work in a team, it will help your teammates. If you’ve been doing this for a while, I hope you enjoyed my rambling descriptions of how my brain works regardless.