I'm a recent AI graduate (circa 2 years) working for a modest operation. It has fallen to me (primarily as I'm the first 'adopter' in the department) to create a basic (read useful?) C# coding standards document.
I think I should explain that I'm probably the most junior software engineer going, but I'm looking forward to this task as hopefully I might actually be able to produce something half usable. I've done a pretty extensive search of the Internet and read articles on what a coding standards document should / should not contain. This seems like a good as place as any to ask for some suggestions.
I realise that I am potentially opening a door to a whole world of disagreement about 'the best way to do things'. I both understand and respect the undeniable fact that each programmer has a preferred method of solving each individual task, as a result I'm not looking to write anything so draconianly proscriptive as to stifle personal flair but to try and get a general methodology and agreed standards (e.g. naming conventions) to help make individuals code more readable.
So here goes .... any suggestions? Any at all?
SSW Rules
It includes some C# standards + a whole lot more.... primarily focused at Microsoft developers
Personally I like the one that IDesign has put together. But that's not why I'm posting...
The tricky bit at my company was taking all the different languages into account. And I know my company isn't alone on this. We use C#, C, assembly (we make devices), SQL, XAML, etc. Although there will be some similarities in standards, each is usually handled differently.
Also, I believe that higher level standards have a greater impact on the quality of the final product. For example: how and when to use comments, when exceptions are mandatory (e.g. user initiated events), whether (or when) to use exceptions vs. return values, what is the objective way to determine what should be controller code vs presentation code, etc. Don't get me wrong, low level standards are also needed (formatting is important to readability!) I just have a bias towards overall structure.
Another piece to keep in mind is buy-in and enforcement. Coding standards are great. But if nobody agrees with them and (probably more importantly) no one enforces them then it's all for naught.