Programming Style & Culture

I am an ambitious programmer and I find satisfaction in writing good code to yield good results which are optimized to produce the best performance of a system. Programming is not all about knowing the trending languages, or writing complex code and furthermore. In my opinion and experience, it is about knowing how to use the least of computing resources to achieve something really big in the shortest time possible even though technological advancements are growing at lightning speeds implying that computational resources are no longer as limited as they used to be just back then. But one must build their programs towards that goal that uses few computational resources because though the computer resources are many, cloud computing service providers also charge for them. Therefore, writing programs that use few resources benefits the organization in terms of reduced costs.

For anyone in the IT world of Development, we can agree that the computational resources are incurred most at the point of writing and reading to and fro the disk that holds the Database. This also includes running queries and table joins. This requires that any developer gets an understanding of Database Systems. A Developer who can write a program that solves the client’s problem by having few reads and writes off that disk is a very good programmer. But this article is not about that. That topic will be for another time.

Back on the growing technology, due to high levels of competition among companies to adopt and have IT solutions to meet their customers’ needs, Software Companies that provide these IT solutions have been pushed to adopt Teams of Developers and not just that, but as a software engineer or developer in the field, you are most likely to find yourself working with other people on the same codebase. Quick fact, a shared codebase is like having a roommate, both people or even more are going to have different characters, habits, or behaviors, and if the royals in that room fail to agree on some things, there is likely to be war. That is the same thing that happens on a shared codebase.

It is important for developing teams to sit around a table and agree on a programming culture if they are to operate efficiently. And, due to the introverted nature of most developers, many might not agree that they have conflicts because they don’t talk enough with their team members, probably because they are working remotely or in different offices at work but the truth comes out at the version control system level. If you always have “merge conflicts” every time you try to put your code together, chances are that one of the reasons is because of the lack of programming style and your same files appear different.

The other conflict could be failure to read each other’s code or be able to integrate with it because some one John Doe labels his table fields differently or variables in a way they desire and everyone on the team has to suffer the consequences.

In this article, I want to include some of the most common naming conventions and these can only be adopted depending on the programming language you are using. I am going to write basing on the most common programming languages last year, i.e Javascript and Python This is the list of conventions: Disclaimer: These conventions have been around for quite some time and there is nothing new I am adding to the knowledge base.

1. Camel Case. ( functionName ). This case is used mainly to name functions during function declaration. Try to keep your function name within five words.
2. Pascal Case ( ClassName ). Almost similar to Camel Case but this starts with a capital letter. It is used when labeling class names. Try to keep your class name within three words.
3. Snake Case (variable_name). Use this to label your variables, database table names, and file names. Try to keep these within three words.
4. Kebab Case (vue-object, text-primary) Even though it is used in syntax in most cases, especially in Frontend Frameworks, consider using this in your HTML object classes. It is also used for writing URL endpoints (edit-item) and it makes the URL endpoints clean. i.e *https://example.com/edit-item*

You can inter-change the cases as you wish as long as there is consistency. Making perfect use of these cases can be the start of coming up with a programming culture.

Now coming back to reality, many programmers are able to do what they can do from other programmers who learnt it from elsewhere. It is actually hard to track which genius minds that come up with some of these algorithms. So that means that there is a lot of duplication of code from AIs, StackOver Flow sites, etc. Many of these solutions are at most times not going to follow your programming style, so it is important to practice the habit of refactoring the codebases on the modules you are working on before committing it to your version control system or where everyone shares the codebase.

Comments.

Some programming culture could be from where you insert your comments. Agree or not but commented code will always make a difference in terms of understanding than uncommented code, even to a personal code base. But there should be a style of placing these comments. In my personal coding style, I place the comments above the code I am commenting about. And for longer pieces of code, I add a comment at the end to show the end of the functionality I was commenting about at the start.

You could adopt your own commenting styles which could be in-line commenting, comments above, comments below or any other way that you can come up with.

Spaces and Tabs

I can’t believe that I actually have to write about this but the debate about tabs and spaces in the IT world is like the arguments we had in lower school about Blood being thicker than Water. Regardless of what someone prefers, the Tech Lead must find a way of harmonizing their team to one of these. It is important to choose between this because, however much spaces don’t matter when a computer is executing programs, it matters to the people reading the codebase. For the sake of a language like Python or HTML that needs intending for syntax or clarity respectively, having just the right indentation helps your team understand the codebase more and leads to more organization.

Having different tabs or spaces can cause you to have issues with your version control. Imagine pulling code onto your local machine only for it to format to your tab and space size hence raising a ‘staging flag’ even before you make any changes to the actual files. You are going to face much temptation to make a commit called ‘small changes’ which is just making your commit history long without any use to it.

IDE and Code Editor

Even though this seems like encroaching on a developer’s freedom about the Editor they use, a hard decision must be enforced for the good of the company and for the good of the team. There are a number of IDEs and Code editors out there to improve your productivity as a developer which is a good thing. I am one of those people who use Microsoft Visual Studio Code for all my projects apart from Machine Learning and IoT projects. But there is someone who prefers JetBrains, Atom, or Sublime Text to mention but a few. However, as a Team Leader, make a standard for the Code Editors or IDEs that you use on projects.

It is important because different IDEs have different document formatters. In case, you choose to select a document formatter from the plugin market of that IDE, you should ensure that everyone abides with it. Having the same Code Editor will have all your code formatted in a similar way to prevent Version Control issues. If you want to be a Cool Team Head, you could let people stick with their Code Editors but use a specific plugin for document formatting and everyone might be happy in the end.

Documentation During the Project planning, let the Team head document the Programming Styles for the project because the project could be in a new language due to certain Project requirements. Something that is documented is easier to follow than something that is just said. Let every team player have viewing rights to the programming style document before they start implementing the code of the project. The Team Head only should have rights to edit the document because the project might get to situations where some tasks need to be clear and precise to everyone.

Documentation is not only important for the programming culture but also for the Junior Developer or other team players who might join along as the project goes on. These documentations should explain the logic part of the code as the code comments explain the technical part of the code. That way, everyone can have a mutual understanding of the shared code base.

Conclusion

All these adoptions of certain codes of operations are aimed at achieving productivity, efficiency, and effectiveness as the Tech Team works. It is therefore important to understand your team and come up with SOPs that won’t compromise the productivity of your team but will instill a level of organization.