Well first of all you shouldn't use controller tags in any logic, They should be mapped to Program Parameters using Connections. Other wise you are creating a tightly coupled mess.
As for as "_CS" I think it is silly in this instance, but having structured and detail naming conventions for Tags is a good idea. Some of my Tags actually hit the tag character limit in Studio Designer, but no one will ever question what that tag is for, If I have tags that are of differnt Types I will often do something like
- ScaleA_LiveWeight_Int and ScaleA_LiveWeight_Float
- ScaleA_LiveWeight_Int_LB, ScaleA_LiveWeight_Float_LBS, ScaleA_LiveWeight_Int_KG, ScaleA_LiveWeight_Float_KG
I think the biggest issue you have is buy in from him on your standard practices. Standards are not intended to be unchangeable. Let him influence them. If you want him to stop deviating then include him and the decision making for your standards. Otherwise you can either live with it or fire him. I doubt you will get him to change otherwise. These things are a 2 way street, everybody needs to give a little, to form a consensus.
HOWEVER, If he did this with me He would have an unfortunate industrial accident.
If you created six tags like that for scale weight components I would shoot you. Create one tag of a UDT with each element. I loathe opening up a controller tag db and seeing 1000s of tags like this. Organize them into components.
Now, not picking on you, but just demonstrating that one person's convention is another person's pet peeve. So to the OP, nothing that programmers doing is really an issue.
CS - anything that helps identify a tags purpose is fine
NEQ move saves scan time
500 array is better than needing an extra element later which can't be expanded online.
HMI - yeah if not using alignment tools, shoot the *******.