Everyone knows that group projects can be a pain. Finding time to all get together is hard enough, but then to have each person work on smaller pieces individually, then bring them all together to make a single, coherent project requires a lot of planning. It’s like a puzzle, except the pieces don’t fit together perfectly. Because each person completes their part of the project in an individualized way, it’s sometimes are to match one person’s piece to another. But somehow, once all the pieces are aligned, edges are smoothed, transitions are created, and the final project flows together flawlessly (hopefully). Coding is no different.
Each programmer has a coding preference. For example, some prefer to have more code, but easier to follow, such as for and while loops. Others prefer less code, but more condensed, such as using underscore in javascript. While this is an inconvenience when working in a group, it’s not a huge deal. Programmers should be able to read the words of code and understand it. What I mean by this is even if a programmer prefers to write for-loops, they should understand the functions of underscore so that if it appears in another’s code, they can still understand what the code’s purpose/function is.
Furthermore, each programmer has an environment preference, whether it be an IDE like IntelliJ or Eclipse, the command line, or a text editor (or a mix). This is a more serious issue that coding preference. If one person is using IntelliJ to code, while another group member is using Eclipse, it can be hard to combine the code into a single project. There are solutions to this issue such as GitHub, or using one environment and manually transferring it over to another. However, when working in group projects, many times a plan is laid out to avoid this issue, whether it be decided on a single environment all group members should use, or using something like GitHub to share your code in a single place.
While both the issues above are very important to the success of group coding, there is one more detail that can make a group coding project only that much harder – code standards. This is the small details of spacing, indenting, and overall flow of the code. It’s almost like the backbone of the code, as opposed to the code itself. Some people ask what this has to do with the code, as it does not determine if the code actually works or not. The answer is simple – it’s like working with someone who did their entire project manga-style (which is where you start reading in the top right corner and move from right to left). It’s not impossible, and you are able to combine the two parts of the project together since they are in the same language. However, it takes a lot of excruciating concentration to understand their part of the project, and then even more to try and fit the two pieces of code together perfectly.
One way to solve this issue is by using programs such as ESLint, which dominate the code standards for your project. It decides every minute detail down to the spacing between commas and the amount of blank lines you can have under your code. While it is good to have some guidance for coding standards, I personally think that ESLint is almost too picky. I think there should be some personality allowed in coding, such as how many spaces I should be able to put between a comma and a number (if you want to call this personality). There are many times that the code is complete and very readable, but I get an error from ESLint because I didn’t press enter after my last console output. However, if you look at ESLint almost like another language, once you understand it, it no longer becomes a pain, but instead more of a habit. With repetition comes ease of use. If every programmer used ESLint and got used to its coding standard, it would become the universal coding standard, which would be extremely helpful when working with a group.