top of page
  • Foto do escritorYves "Jack" Albuquerque

Code Style / Code Standards


Blurred code

Code Style, Code Standards or whatever you call it are a common discussion point within programming circles. Most tech companies eventually crystallize their own unique code style. In theory, ostensibly tailored to meet their specific needs. In reality, these styles often trace their roots back to the formative days of the company. They are, in a sense, a historical artifact—crafted by the original cadre of programmers who mingled their personal preferences and idiosyncrasies to create a compromise that suited their early environment.


The amount of time spent on onboarding developers into these unique coding paradigms can be staggering. Newcomers often find themselves grappling with the Herculean task of decoding and adapting to a code style that, while second nature to the company, might seem arcane to the uninitiated.


I'm not advocating for the abolition of code style. On the contrary, having a code style is crucial for maintaining readability and consistency. What I am saying is that save time through better Readability and Consistency are actually the whole reason to have this discussion in the first place.


I listed some rules of thumb to explaim my perspective on this topic:


  • Readability is more important than code style. Is not following the guidelines but is clear, readable and will not cause any confusion with other code parts? So, it's perfect fine. Sometimes, a code can be clear and easier to understand following a different structure different from what is used elsewhere.

  • Don't exagerate on your rules. Resist the temptation to overrule. The rules are suppose to reduce possible confusions in order to accelerate your coding. You totally missed the point if, at the end, you spend time more time ensuring the adherence to the standards.

  • Performance, flexibility, robustness are not a code style. These are good programming practices. I already saw companies adding good programming explanations in the code style guide. Please, don't. Companies that do that, usually produces huge documents that ends up to be harder to follow. If you want a document or a course to improve good programming practices, do it. Code style guides are just not the right place to do it.

  • Adopt a widely recognized and standardized code style rather than concocting one from scratch. Have your own code style implies much more effort and time than any benefits it may bring.

  • Mimic the third party style. Working with a third party code may force you in a complete different style so it's very tempting to change the third party code to your own standards. This is risky and often time consuming.

  • Adopt code style to the tech you are working on. Aim to the already stabilished guidelines used by the techs you are using. Your company are not alone in the Universe and you want to avoid code style conflicts with external code as much as possible.


That said, that's the main references I use:

Unity References :


Unreal References:


General C#:

5 visualizações0 comentário

Posts recentes

Ver tudo

Comentários


bottom of page