Our expertise and 7 principles of work

Pretty much any healthy programming workflow will include code review at some point. However you do it, not all code expertise is the same. At Lab 42, we have a strictly required workflow that includes code review. This helped us catch a lot of bugs and sub-optimal code fragments in the early stages of development. Therefore, our team provides this kind of service to other developers as well.

Our 7 Ways to Work

The first and foremost principle of good review is thorough code review. We are always ready to spend a decent amount of time on this. And as practice shows, we always find something, because code is never perfect. We try to always suggest at least one specific code improvement (not just style) at the initial stage, so subsequent reviews may no longer require it.

The second principle actually follows from the first. We strive to understand every line of code. This is important because simple elegant code is better than complex code. And to understand whether the best solution is really applied, you need to understand the current one. And if we're having trouble understanding the code, it probably needs to be refactored, cleaned up, or better commented.

The third principle. We start from the fact that initially the code may well not work – we assemble it using the build system (if there is one), and test it ourselves! At Lab 42 we also use automated testing.

Principle 4. Commenting matters. Lab 42 has developed and uses its own standard (of comments showing the intention of CIT), which requires that approximately every logical statement should have a comment describing the intention of the programmer. The suggestion is that if you're working on a project that follows this convention and you don't see an intentional comment, you should request that it be added to the code.
As for the comments themselves, it's not enough just to have something written there. Intentional comments should actually describe the intent. When reviewing the code, we will advise you to solve the following problems:
1. Intentional comment doesn't make sense. This indicates that the comment, the code, or both are incorrect. So our team found a lot of potentially nasty bugs!
2. An intentional comment doesn't make sense. If a comment is confusing, it's just as useful as not having one at all.

Principle 5. We check temporary code as rigorously as working code. It can be shocking how often the search for ways to fix a time code turns it into a working product, and how much of it is never actually replaced. It's just the reality of programming. In other words, even if the code is not perfect, the implementation should be clean, maintainable, and reasonably efficient.

The sixth principle. We make sure to check how the code will work in the real world, how it will handle incorrect user data and errors, whether it will fit well with the rest of the code. We are always demanding on the code.

Principle 7. We thoroughly review documentation, tests, and build files. Good code doesn't just include the code, it includes all the attributes that come with it. When adding, removing, or renaming temporary code files, the assembly files must reflect these changes. Likewise, if any dependencies have changed, the build files should reflect that.