There is absolutely no difference between one and the other, except the reading of the code by a human.

, ( alias ) C # for your types in the .Net Framework System.Int16 , System.Int32 , System.Int64 in, and System.String respectively) and during execution it will not make any difference if you used one or the other to declare the variable.

As for your colleague doing differently than what was being done and claiming that each one will code in a way, it contradicts the common sense that the team should choose patterns, informally or formally if necessary, and everyone should adopt the standards. / p>

When all code follows the same pattern, once we get used to this pattern no one feels uncomfortable reading the code of others and we are exempt from having to do the fateful "switching" of reading mode every time we read other code.

  

In addition to the style standards that avoid the constant adaptations by the reader, there are also standards for security, robustness and code quality. If a team does not follow the style standards, will it follow other even more important standards?

Evidence of the importance of the team following a coding standard is the existence of specialized tools (eg StyleCop, FxCop and Resharper).

After all, is there justification for this change?

The only plausible justification is your colleague's preference for this style he is adopting.

Any other justification is lack of information or just a lie.

Generally, there is no justification for breaking the established standard. If the project is using 100% int , long , and short , it continues to use, even with Int16 , Int32 , and Int64 .

Now, I think the worst thing I could do is leave the project with this mix - it's hard to keep track of what pattern you should be following.

If your colleague started to change everything to int , I believe I would have to change everything , leave nothing in the other way.

I believe that if he is programming ALONE on a project he could do whatever he thinks best, but as there is a team, there must be rules and standards established and agreed upon at the beginning of the project.

Anything that is out of the standard should be justified in not following what has been agreed, even if it is simply a single line comment.

I agree that each one has a different way of programming and therefore neither one nor the other will be wrong, but in order for a project to be defined the best way (not to end up becoming "miscellaneous"), p>

To change some pattern must be given the justification of the same and soon be debated and accepted by all. Even though this is simple and takes around 10 minutes to happen, but it's the team, not one or the other that decides. At least he has the authority to go over the others, but I still think it would not be the best alternative.