Something that evolved a lot during these years is the coding style I use.

When I look backward in my past projects – mainly when it’s backup and cleaning time! – I can easily identify different ‘periods’. And these periods can also be linked to the company and the teams I was working in.

The first thing that jumps out at you is the indentation style.
For instance, I was using and defending this one a lot in the past:

while (x == y)
{
    something();
    somethingelse();
}

One of my arguments – at the time – was mainly that it helps readability to have accolades on the same columns.

Whereas nowadays I mainly use this one:

while (x == y) {
    something();
    somethingelse();
}

And this is mainly thanks to Apple because most of their docs and sample codes use the later one. And it had some influence in the development community (but there is some schizophrenia there, as you may still find the first one depending on the engineer behind the keyboard).

I’m now used to switch from coding style to coding style with some ease, depending on the team motivation and project.

And there is some kind of erosion still, like in every language or slang.

 

But sometimes some coders replicate things they happen to experience at school or with an old developer at work without understanding why is that.
One that horripilate me a lot is when someone exchanges the order in a comparison.

For instance:

if (12 == x)

instead of:

if (x == 12)

Don’t get me wrong! I know where it comes from:
With early compilers, this could lead to logical errors when you forget one ‘=’ such as: “if (x = 12)” this is no more a comparison but becomes an assignment.
So people were inverting the two because “if (12 = x)” triggers a compiler error.

But with modern compilers (not speaking about the last few years but since a much longer time) the “if (x = 12)” triggers a warning (remember when I was writing about the warnings importance and that it is a good point to consider warnings as errors). And you can mute this warning by either having double parenthesis like “if ((x = 12))” or – if this is a typing error – fixing it back to a comparison: “if (x == 12)”.

Which is way better! You keep a more human-readable form instead of trying to fix things up to help the compiler do its job!

 

And the worst thing of it – in the addition to the fact these persons don’t even know where it came from – is that we can even see weird derivations of this, such as:

if (["toto" isEqualTo:myString])

Yuk!!!

Hopefully, the usage of a linter helps to have each member of a team to follow a general coding style and comply with it. And you don’t have to worry about the coding style much during the code reviews”