The kebab case – why conventions matter especially as an engineering team!
Across teams and industries, it is a common practice to follow conventions. There are some obvious advantages and disadvantages to using or relying on them. We write our URLs in Kebab Case. If you’re not familiar Kebab Case it-looks-like-this. An example would be https://causecode.com/blog/59/wishful-thinking-a-programming-skill-that-every-entrepreneur-should-learn. With this convention we are primarily trying to address a couple of things, readability and search engine friendliness.
But software engineers love relying on conventions to a crazy extent. To give you an idea as a community, software engineers have passionately debated about tabs vs spaces in the past:
Of course, there are endless other things we have debated about like directory structures, file names etc. Why is it important for us to have conventions?
1. Adding a new team member
2. Working on code implemented by someone else
3. Ease in code review
4. Bug fixes
These directly result in a software’s shelf life and maintainability. Also as an engineer, there is nothing more averse than fixing/maintaining/enhancing a code base that is either poorly written/organized or doesn’t follow any convention. Software teams should care as much about engineering experience as much as they care about user experience.
Once you have these conventions defined. Anybody familiar with them and the technology should be able to read the code and make sense of it. Over the years as an industry we started relying more and more on conventions, in fact, there are frameworks like rails that have been built around the idea of the “convention over configuration”. Improving the engineering experience drastically.
It becomes important to identify violations during cold reviews but at times things can slip through. Some of these conventions are followed in a team in good faith i.e. your program will still run and build even if you didn’t do those things. Now you’re supposed to follow some driving conventions on the road that are not rules. But drive around Boston or Mumbai and you’ll realize conventions are always not enough. To mitigate this as a software team we actually do exactly what the traffic department does. Convert some of these conventions to rules that a code analyzer like ts-lint or CodeNarc would complain.
Conventions will not guarantee a well-written codebase but it does make you exponentially closer to having an engineering team that scales and communicates better. Like anything they also need to be reviewed and improved upon over time even if it means making big changes.
How do you write your URLs :)? Would love to know your thoughts on organizing code and/or coding conventions, do comment!