Going Open Source 1: Coding Style
This is the first article in 'So you want to go Open Source', a journal of my process as I work toward releasing a company project that has been in development for a very long time as open source. This article covers my first passes through the code base.
I have already taken my most advanced implementation of the code base, set it up in a shiny new dev area and stripped all traces of the former project. I'm left with a fully functional engine with no polish that basically purrs great but does very little - isn't attached to any gears, drive trains or tires... etc. My temptation is to start implementing the meta-code that will give the project shape, but that would be getting ahead of myself.
Before shaping the logic and design of the app, I ought to do a full audit of every line of code. In my fist pass through the code, I am focusing on two things:
- Cleaning up, stylizing and commenting the code and
- Creating an itemized list of all elements of the project that will have to be dynamicized and genericized
Style, style, style...
My approach to style focuses on clarity and accessibility with a bit of dry sarcastic wit. I will be using php documentor so I'll largely taking my inspiration from their style guide. I also recommend reading the pear guides, and articles and guides for other open source projects just to round out the ideas.
Framework?
I'm basing my software on a simplified MVC, so won't have to package any other framework or incorporate bridge notes on how issues may arrise.
Comments!
I'm finding that the process of commenting is the most helpful aspect of this exercise. By forcing myself to explain each segment of code, I am rigorously exposing potential inefficiencies, insecurities and even some contextual errors. I am also developing my master ToDo list concurrently as a place to organize the tasks. I recommend Basecamp for ToDoing.
This process will take me a while, as I have to fit it in amongst other responsibilities. Stay tuned for part 2.