"Good" code

Before I officially started programming, I'd heard horror stories not just on the internet but from my own coworkers about the challenges they faced reading poorly written spaghetti code with meaningless variable names. At the time it was often difficult for me to look at the code and know why it was bad; the syntax was strange, and even beautiful code would have looked elusive. Still, I'd witnessed enough frustration as a result of "bad" code to realize that the way code was written - not just what it did - was important.

When I started programming, I decided that I would make a determined effort with every piece of code I wrote, whether for an assignment, for practice or for production, would have properly named variables. Seemed like an easy enough place to start, right? It turned out to be much harder than I'd originally expected. "Why can't I just write 'var x = y;'? It's only for a practice problem and nobody's going to see it anyway..." The urge was there, though I'd made up my mind, and I wasn't going to let myself slip into that bad habit.

What I've found is that little things can make all the difference when it comes to code readability. Properly named variables and functions, consistent spacing, consistent capitalization, batching of declarations, etc. Each one doesn't take a huge amount of time, yet without them what was once readable code turns into an absolute mess that is not only difficult to follow, but distracting for the reader. The number of times I've seen node* root on one line and node *left on another is too many to count. I have my opinions on where the `*` should be placed, but it really doesn't matter so long as the code is consistent.

I'm fortunate that I haven't yet worked as a developer on a project that has a huge code base with bad coding style. At the same time, I certainly can't say that I've ever worked on a living breathing project where inconsistencies existed. Proper coding style is something that's worth the extra overhead. Developers may not like the strict linting rules that result in them having to spend extra time on each feature branch getting the code up to snuff, but in the end I can't say I've ever met a developer who didn't appreciate well-written and readable code.