Coding standards ideas from the past

These are the updates/revisions I made for my team when asked again in June:

Non-production warnings:

                An application should produce a warning on the blog, and by a net send to itself that it is in testing or non-production mode.  Otherwise it could run and not produce any results without anyone noticing.

Major modes/flags:

                An automation application should report all major flag settings it is running under to the blog for that run. (non-production, holiday run, any other major setting that could be set incorrectly for a particular situation.)

Net Sends:

                Net sends should be used to report failures and crashes instead of successes since we only need to do something if there is a failure or crash. Reporting successes tends to make us get used to ignoring net sends.  Also they should be used VERY sparingly, some code for a situation I never expected (all programs/automation net sending me EVERY time they could not use statsout for the blog, resulted in over 1200 net send messages being sent to me over 3 days.)

Exceptions:

                Throwing exceptions is wasteful, code should be designed in such a way that each part of the path from where the exception would be thrown to where it would be handled can be done without throwing an exception as there is overhead there and it violates the definition of Structured Programming

Return,exit for, exit statements:

                As a rule having more than one return statement in the same function violates the definition of structured programming.

                Exit for to a lesser extent is more of the same violation

Version Numbering (revised):

                Your build should include year month day in that order, but it should be in such a way that a straight string comparison puts the version numbers in the correct order. (you need a non-zero placeholder in front of month and day, or only month/day if they are in the same field) This ensures the ability to easily tell which is the newest version of a project.  Modification dates alone do not account for this because an old version could be run again, and produce a new modification date without actually being the latest changes/version.

Version Control Commits:

                After doing your revisions to a project, if they involve multiple new features, consider committing the individual files with the notes of what features have been added/revised.  This is easily obtained by right clicking the file and selecting show changes.

Change Log (revised):

                With version control, our change log should still include features added, modified, or revised so that end users can see the information. It should be less technical than what is in the version control, but features and functionality changed should still have change log information. Consider updating the change log, then copying that data and just using directly with your commit.

Pre/post build events (revised)

                Nothing should auto zip any longer. Auto-build should be used only on automations and only for the startup project of a solution.