Coding standards ideas from the past

My December 23, 2008 Coding standards proposal for our team it appears to be a tad ideallic and beauracratic looking back, but it's what my thoughts were at the time.


These are things I recommend, things I would like to be either enacted, or put up for discussion/debate at the standards meetings. This is not an exhaustive list but a good place to start.

• Visual studio
• Pre/post build events
• All projects should use pre/post build events to auto push to the built folder and the project zips folder
• Help->about
• All projects should make use of blib.showStartStats so we can at a glance locate dependencies and version information
• Settings
• Anything that needs to be changed back and forth easily for testing, should be done in the settings area
• Strong Signing password
• Anything that needs to be published must be signed
• That signing passkey should be something consistent between all of us
• or stored somewhere consistent for all of our apps… perhaps in the settings area as an application level-setting
• Mainframe access
• Anything that accesses the mainframes should be done using the most up to date version of the libraries
• Library references
• Anything that references a class library should be pointing to the Z drive not a local copy
• Change Log
• Anything that is in use somewhere besides your desk, or that reports to the bLog should have a change log for each change
• The date and version number of the change (very simple if your version number only changes via date)
• The class and function name that was changed should be mentioned
• Or ‘overhaul’ on and the class name
• The reason for the change should be mentioned
• Version Numbering
• Your version numbers should include the year, month, and day of the build.
• Strict and explicit
• All projects/solutions should have those compile settings set
• Template files
• Excel and word document templates should go in the templates folder on the Z drive, but in a folder of the application name, not in the templates folder itself
• NetSend
• Net Send must be used very sparingly or we may get used to clicking it away thinking it’s the same message we are used to seeing
• clsStatsUpdate
• should be used in all places where you are looping through and processing data
• should be called at the end with the finished flag set to true so that it will note that in the BLog
• TestMode
• All apps should have a test mode where they do not make real changes to the mainframe or make real changes to the database
• Or they access the test region, or test tables in SQL where they do make their changes
• Alternatively apps should have detailed testing instructions about what to do and what not to do.
• Methods
• Should fit on a single screen
• If not the method should be broken/refactored into smaller pieces for readability
• Class Variables
• Should only be used for things that are needed between many different functions, where you would be passing the same data to more than 3 other methods.
• Process Code
• Code that does not involve the interface should not be in the form code sections
• Only calls to invoke the process code should be in the form code.
• Data types
• A list of ‘things’ should be enum instead of using coded integers or coded strings
• This ensures compile time checking that a value is still valid if it is present
• Items that are removed should be commented out of the enum with a date of inactivity
• A number should be a number type not string
• Commenting
• Commenting should be done using the ''' method. - This was Vb.net 
• SSIS -Storage
• Packages should be stored either under your username, or in the appropriate folder (QR\Daily\Weekly\Monthly)
• Packages no longer in use should be moved into your NBK folder and/or off the server
• SOP/pass downs
• Reviewed
• All SOPs should have a last reviewed date showing when the last time you looked over your procedures and verified they match with what you are currently doing
• This date should match the day before you went out on vacation or at least the last time you changed your procedure.
• Format:
• Title
• What is the process called
• Last Modification date
• When was this particular process’ SOP last modified
• Exact and specific location to run from (for anything that may need to be manually run)
• Special instructions for other users or holiday runs
• Computer it is currently set up to run on
• Time/days of the week it runs
• Deadlines/when it needs to be done by before other things/people may have a problem
• Whom to contact for help with it (if someone else previously designed the process or if Scott is the best contact if something isn’t clear)
• How to verify start
• Most should have a BLog entry
• How to verify success
• Most processes should have a blog entry of complete success or which pieces failed and if that failure means someone needs to go check on it or manually run that piece
• Should a file now have a new modification date?
• What the outputs are and what a good one ‘should’ look like
• Excel, word, SharePoint, a SQL table: what are all outputs of the process
• Exact/specific location of those outputs
• What systems it pulls data from
• If you are out and your project ‘appears’ per your instructions to be running fine, and a system has a known problem, which systems might cause the process to have faulty data and require us to double check the results.
• Information about who to inform of a problem if there is one.
• Enough information about what happens so that someone outside of our department would be able to read your instructions and run the process (not including login information)
• Known ‘Errors’
• Things that occasionally or have happened and how you dealt with them
• Test run instructions
• If someone has to debug or test changes to your process how do they do so?