I'm getting push back from some developers (who will remain nameless) that I'm setting a standard for coding practices using Pega Robotics Studio v8 too high.
For example: My belief is that comment blocks in code are a good thing and valuable to add many useful blocks, vs a few or none. Pushback is that one doesn't need comments because it's a more visual interface...
Another example would be the complexity & size of an activity/function. How many is too many functions to add into one routine... For the image below, without reading code (too small anyways) does it look complicated or not, and is the one comment at the bottom. would this be enough?
Are there standards for good coding standards.. I know there are file structure examples, but what about good code?
Generally speaking, comments are required only for areas that require explanation (i.e. when you are doing something that isn't self-explanatory to other developers). Generally, I do not add comments except for complicated or otherwise non-obvious logic. A good automation would be one that is compact (it only works on a specific area and can be executed to complete that step), easy to read (lines do not cross whenever possible and is not so large that it requires much scrolling to get around), and well-written (meaning all execution paths are handled and it clearly accomplishes the goal relevant to the name of the automation; SendEmail for example).
I have a small automation that I have attached that only performs two steps. It sends and email using the SMTP component and attaches an Excel file to it.
Posted: 5 years ago
Posted: 16 Mar 2017 7:26 EDT
Jeff Badger (jeffbadger)
Principal Product Manager, Robotics
Thomas and I have worked together for a long time, so I agree with everything he said. I would add the following. For me the most important thing is can someone else figure out what I was doing. So I prefer smaller automations and automations should flow from left to right and top to bottom like reading a page in a book. I use jump labels to connect lines and use their names to document steps. If it doesn't fit on a single screen at close to 100% magnification (remember you can't make bigger when debugging) make sure it is organized so that when it is at 100% the next person by scrolling up and down can see the important elements.
Another important thing to consider is reusability. Automations can accept input parameters of any valid type. So, if you are doing something complicated more than once (as long as the controls are of the same type), create an automation that performs that action and accepts a parameter of the type and then just call the same automation on multiple controls.