As we continue forward with our project of Ripples it became apparent that we all needed to sit down and come up with a set of Coding Standards and Practices that we could reference if needed. Right now, we have three developers on the team going through adding to our code base. If each developer is adding code in their own style, things can quickly get out of hand. These Coding Standards unite everyone under a single guideline that determines how we should go about writing our code.
So the other day, that is what we did. The three developers we had all sat down and came up with a solidified set of coding standards that we will follow for this project, and hopefully if we continue on to next semester, new teammates will follow. Our document covers the use of Comments, Spacing, Naming conventions and some General Guidelines that we set up.
But why is this important?
Readability.
Since we are all working on separate parts of the code base, we know individually how the section that we are working on functions. If one were to move over to a different section of the code base that they did not work on initially, thanks to a single coding standard, they should have an easy time reading through the code and have a much easier time understanding what a section of the code is suppose to do and how it works.
Also, it just looks really nice. And there is something about having nice looking, organized code that makes you want to keep working. And if you take the time to implement these standards, your future self will thank you whenever they need to look back on a section of code.
The other thing we went over after making some Coding Standards was our practice for working with Unity and Source Control. We are using Git as our main form of source control which has been very nice. I am enjoying it much more than SVN which we need to use in the past. Anyway, since we are all working on the same project now, we needed some guidelines to follow for our Source Control to make the process or headache known as merging as simple as possible. The first rule we decided on was that everyone works in their own Unity Scene. Want to test out a new idea? Make a new scene for that. This makes it so the likely hood of us stepping on each others toes by editing the same scene and trying to merge. The next idea was to make sure everything was a prefab. That way everyone would be working with the same objects as a starting point. And no matter which scene you are in, you can access those objects if needed.
Armed with those sets of standards and practices, we venture forth in continuing to create ripples.
-Jack Storm