Part 1 documents conventions that can be enforced or guided through IDE settings.
Part 2 here describes conventions that really depend on the developers following them. In particular, the conventions here are for JavaScript/TypeScript code.
This is another one of those things that every developer has an opinion of. Can't blame them us really. As much as programming is science, it is also an art. And artists have their own temperaments.
Regardless, unlike artists, developers have to work as a team. That means that they have to follow the team's conventions regardless of their preferences.
Many conventions can now be easily enforced via configurations settings, thanks to the ubiquity of VS Code and, to a lesser extent, Prettier.
This article looks at the easy steps we can take to enforce coding conventions easily for a Next.js project.
In a previous article I wrote about my Git branching strategy for small teams. In this one, I will look at the topic of writing commit messages. This is also a highly opinionated take, just like the previous article.
I'm preparing a set of materials for a batch of interns whom I will be mentoring for a software development project.
One of the things that they will be doing is to check out an existing codebase to work on. To do that, they need to know Git.
I'm quite certain that the basics of checking in and out code is no problem for them if they have any Github profiles. However, every organization has its own conventions and requirements when it comes to maintenance of their codebases. This post documents my preferences in code maintenance.