A collection of notes that I hope will not sound at all condescending. When I was in college, I felt really abstracted from what I imagined coding as a career to be. It turned out that I was wrong, and all of that stuff was actually really important, but luckily I osmoted enough knowledge or something to drop out like a champ. Anyway, my belief is that environment inherently acts to inform consciousness and experience! Wow, that was out of nowhere! No, it was out of the tenets of phenomenology, and I swear it makes sense here. As a coding person, you are the master of your domain, and every tool you use to make your environment an extension of yourself facilitates workthrough, reduces context switches, etc. And I feel like maybe if I'd been more in touch with that when I was in school, I wouldn't have imagined such a schism separating me from real programmers.
Whoa, that was a bold reference! Did the situation warrant it? No, but we watched The Importance of Being Earnest together! I just wanna broach a really polarizing, contentious subject here. I wasn't sure if I should, even, but it's so...foundational. Okay - text editors. You already use one! And I'm sure the one you use is just great, and I have no judgment! But maybe I'll just make some mild assertions here anyway, and you can scoff at my narrowmindedness and ignore this section! That's okay!
So I write in Vim. I am going to list some reasons that I use Vim, not for the purpose of selling it to you, but only in order to clarify some of the reasons that text editors are so important to me!
- When you SSH into a machine, you'll probably default to editing stuff in Vim. This makes its basic usage pretty general-purpose, and I think it kind of appealingly demonstrates how close to the metal Vim is?
- My Vim config file is 350 lines long and invokes 15 separate plugins. It's kind of a direct manifestation of my needs into my environment! That's not hyperbolic! It is!
- I'm writing Markdown right now and it's kind of getting, you know, marked down? Not perfectly, because I'm going to post this to my github, which uses a different kind of Markdown, but still! (This is a plugin, though).
- I philosophically enjoy the separation of inputting text from the navigation and parsing of text. I really think it structures my thoughts in a very code-conducive way.
- Mice are evil.
- It's nice to not leave the terminal.
- It plays really well with Tmux, which I'll get into shortly!
Okay! I'm done proselytizing. You might not use Vim, and that's okay! You might use Sublime Text? You might use Emacs? You might use Emacs in evil mode! (That appeals to me.) You could be using something...different? Regardless, there are some common tools you might want to integrate with your text editor!
- GitGutter is a big one for me, and while our use cases are slightly different I think you might have reason to like it too! There are GitGutter plugins for all the editors I mentioned above. Basically, it uses a few unobtrusive markings near your line numbers to indicate which lines have been added, which have been modified, and where some have been removed between now and your last Git commit. The bigger the project the more useful this is, sure, but I think it's handy to have your eye naturally drawn to the sites of recent change - those are most likely the spots you want to keep working. I like this so much that I kind of want to write an enhancement of it that lets you compare your current state to a chosen commit hash instead of just the latest one, because sometimes I feel lost and unproductive when I've just made a commit and now have no idea where I've written changes.
- Linters are kind of heavyweight, but they keep you honest, you know? Text editors that teach you how to code! It's living the dream! I don't use one for C (because my C is flawless - joking, joking!), but I use Syntastic with Rubocop and Ruby-lint enabled to check my Ruby. And they catch a lot of errors.
- I don't know how localized the rest of my list is, so I'll drop this for now.
- Ag is basically magic. It's a super-fast, ignore-file-respecting, smart search tool that I've basically used to replace my fleshy human memory of my project structures.
- Tmux is ALSO basically magic. It serves a lot of purposes, but I mostly use it to partition my terminal windows on the fly. So you can read multiple source files without moving your eyeballs, you can compile and run your programs on one half of the screen while you edit code on the other, or you can just subdivide your terminal into Golden Spirals when you're bored! And while the basic syntax is *pretty good*, you can integrate with Vim really nicely so that they use all the same navigation hotkeys. Tmux is a bit of a rabbit-hole, definitely - things get kinda crazy down there. Like, you can use Wemux to share your terminal with remote users and selectively give them read-write-control access. Crazy!
Debugging tools that seem at first glance to only be relevant to C, but actually have broad and mysterious powers
- You might already be using GDB. If not, you should! It's amazing. Compile with -g and all optimizations off, and you can step through your program execution, jump to certain points in your source code, set breakpoints, *backtrace out of segfaults*, and more! You mentioned that you have a class that's half C and half assembly, so maybe you would be interested in the way that GDB can disassemble C into assembly? Or getting the values of everything in each of your registers with "i r"? These seem like useful things!
- You might already be using Valgrind, too! This is actually a suite of individually amazing tools brought together under one amazing umbrella! That umbrella is a virtualized CPU that intersperses your binaries with various tooling code. The default is memcheck, which is also good for understanding segfaults, as well as getting chastened about the massive memory leaks in your program. Keeps you humble, you know? But it does other awesome things like Callgrinds, which is a tool for generating call-graphs. The awesomeness of which is self-explanatory:
Actually, I think I have more self-explanatorily awesome call-graphs of my own, but I think they're technically IP? Anyway, note that each node is a function with directed edges showing what other functions it calls, the edges are marked with the sum of those invocations, and the percentage in the node is the total amount of program time spent in this function and all its callees. The virtualized CPU aspect gives it certain advantages over tools like GDB, such as allowing it to work at different optimization levels, as well as *not being limited to C code*. Supposedly you can even Valgrind interpreted programs? Which doesn't actually make sense to me, but certainly sounds cool!
I guess I don't want to ramble more than I have already rambled, so let's leave it off for now? I hope that, even if you find none of the above useful, you don't think less of me for writing it! Good luck in your studies and other adventures!