Code Convention

Programming is complicated, and complexity hurts productivity. Keep things simple to be successful.

This advice applies to all projects, but it's more crucial for larger ones. Small, solo projects can get away with complexity, but as projects grow and teams form, simplicity becomes essential.

On a small team, trying to divide tasks into "my code" and "your code" can lead to difficulties. Defining interfaces between code becomes a challenge.

As projects grow, the "my-side-your-side" approach becomes unsustainable. Programmers might argue that creative freedom is stifled by constraints or that different parts of the project have unique needs. But these arguments overlook the impact of complexity on team performance.

In reality, coding style variations add complexity and make everyone's job harder. In large teams and projects, simplicity is key to success.

Coding style

Code reflects a unique style and philosophy. Reading code that uses a different style is like reading a foreign language - it's slower and more error-prone.

Code looks the same, but with different naming and formatting. If you're used to one style, the other will seem strange. Reading it requires mental translation.

The issue isn't the coding style, it's combining different styles, adding complexity. This makes it hard to switch between styles. It's better to stick to one style throughout your code.

Language Conventions

The same is true for language features. If you're used to simple javascript code, more modern Typescript code will be hard to understand.

It's not about the features themselves, but about consistency. If you're used to one set of features, switching to another set can be exhausting. And if the change is unexpected, it's like trying to read a different code.

Problem-Solving Conventions

As programmers, we develop our own instincts for solving problems, but this can lead to different solutions for the same issue. This can increase cognitive load and result in reinventing the wheel.

Error handling is a good example of this. There are many ways to handle errors in programming, and even within a single language like C++, there are multiple approaches.

Sticking to a convention can be challenging, especially when working with libraries that have their own error-handling models. However, using a consistent convention can make code easier to understand and maintain.

Here are a few examples of error-handling conventions:

  • One approach is to return a combination of global state and special return values, like in old-school C-style file handling.
  • Another approach is to use functions with names starting with "try", which return a boolean value indicating success or failure, and report details about the failure to a log.
  • A richer error type can be used, which allows code to propagate errors while still providing detailed information.
  • Alternatively, exceptions can be used, which can hide the complexity of error handling but can also make it harder to track.

The key is to choose a convention and stick to it. Mixing different conventions in the same project can lead to confusion and bugs.

In summary, error handling is a complex issue, and there is no single "right" way to do it. The key is to choose a convention and stick to it, and to avoid mixing different conventions in the same project.

Effective Teams Think Alike

As a team, our goal is to think and work together seamlessly. We aim to write the same code for the same problem, with the same formatting, naming, and algorithm.

Working with code written by others can be challenging. It's like reading a foreign language, with assumptions and conventions that are unfamiliar. This leads to misunderstandings and waste of time.

The solution is simple: align your assumptions! Use the same conventions and standards. Consistency is key.

When a new standard is adopted, we update our codebase quickly and efficiently. This process takes less than a week, and results in consistent code that is easy to navigate.

Our ultimate goal is to write code that is indistinguishable from our own. When we achieve this, we've set ourselves up for efficient and stress-free programming.