Code Quality and Us
28 Dec 2014What is Code Quality?
All software engineers know this concept. The invaluable metric that defines whether someone's code is good or bad. Not all solutions are equal. There are dozens of sub-categories that can compose a code quality rubric - comment ratio, whitespacing, variable names, scope, performance, etc - the list goes on and on.
Simply Put:
I've found that the concisest definition of code quality I can think of is this: does your integration make it look like one person wrote the entire codebase?
There are contribution guidelines for most repos. This is because a seamless codebase represents one of the best performance benefits we can achieve: future engineers working on the project can quickly work with what you've made. When we write software, we don't write for ourselves, we write for our future teams. If you're the only one using IIFE's, it's going to stand out and slow down future development if it's not something people are used to. Comments, whitespacing, proper scopes that don't have global namespace soup, etc, all contribute to readability, and ultimately, more free man-hours for a team to make it better, whether its polish, optimization, or feature range.
Karma
Whenever I've gotten stuck on someone else's API, I use that frustration to push myself to build better solutions in the future. I think if we all kept in mind our future selves when we write software, the world would spin more smoothly. "Would future me want to use what I just wrote?"