VBA Coding Rules

[Mackeral]

1. Always have of the last time the spreadsheet ran.
2. Don't change original code unless there is a compeling reason.
____It's too expensive.
3. Keep documentation up to date.
____I often have to use it to remember what I was doing or how
____or why I coded it that way.
4. Don't put calculations in Function Call statements.
____If you need to "Debug" into the Function Call, all you will
____is the code connected with the Argument calculation, not the called Function.

(If you have any rules of your own, please update this post)
Mac

 

[hiker95]

Mackeral,

See if something, in the below link(s), of my most up to date list will help you:

Training / Books / Sites as of 5/30/2018

https://www.mrexcel.com/forum/excel...lding-software-excel-shipper.html#post5079095

 

[Mackeral]

Is this the right way to get to an Adminsitrator. I couldn't find a place to just send a genreral message.

I have a post which is currently appearing in the "General Excel" forum but I should have put in "Excel Questions".

I'd also like to change the post. I apparently ran out of time re-editing it and the insructions were to send it to an Adsministrator.

The New Post:

1. Always save a copy of the spreadsheet of the last time it worked.

2. Don't change original code unless there is a compeling reason. 
    It's too expensive and will probably require extensive 
    modification of other code as well.


3. Keep documentation up to date.
    I often have to use it to remember what I was doing or how
    or why I coded something that way.


4. Don't put calculations in Function Call statements.
    If you need to "Debug" into the Function Call, all you will see
      is the code connected with the Argument calculation, not the called Function.


5. Always put in a commented description of a subroutine and keep an updated dated 
      list of changes as well.
    If you always use the same format, you can then process that information
      into a library. 
    I also like to leave standardized comments as part of description process,
      like "'Type: String" which lets me find a group of similar routines.


6. My example of a Subroutine/Function definition:

------------------------------------------------------------------------------------------------

       Sub Name_of_the_Subroutine(Argument_1, ...)
            ' Description of what the subroutine does _
              second line of description if needed.
            ' mm/dd/yy A description of the change. Initials of who made the change.
            ' mm/dd/yy More lines of dates, descriptions, and initials of programmer _
                       making change.


        ' Type: String  
            
            Prog = "Name_of_the_Subroutine"
        
            Orig_Arg = Argument_1  <-- the important argument to be operated on or used.


       Start: _
        Argument_1 =Orig_Arg


             ' Code to be executed


    End Sub ' Name_of_the_Subroutine  <-- followed by "() if routine was a function

------------------------------------------------------------------------------------------------

   The "Prog" statement can be used as a call argument in Messaging routines to
      let you know where they were called from.

   The reason for this is that if I am debugging, I can restart processing from "Start".
   The reason for the "Start:" label is that I can restart the code to rerun it as I'm debugging.

If you have any additions, please add them to this post.
Mac