Illustration podcast section

IBM i DevOps TechTalk
Coding Standards #10

by the experts at ARCAD

Join us for the 10th episode of the IBM i DevOps TechTalk Podcast, where we discuss the topic of “Coding Standards” – a cornerstone for achieving usability and maintainability in coding.

In this session, Nicholas DeLessio, Developer and CodeChecker expert, joins forces with Ray Bernardi and Alan Ashley, senior solution architects, to provide a comprehensive view on coding standards. Together, they address key points:

The significance of coding standards in modern software development.

Advantages of implementing these standards for your organization.

Specific challenges in the RPG coding environment and strategies to overcome them.

• How ARCAD can facilitate the integration of best coding practices.

Listen now to empower your coding strategies on IBM i!

Listen to the Podcast

Spotify Podcast Badge
Apple Podcast Badge

The Story Behind the Mic: Podcast Transcription

Ray Bernardi – Welcome to IBM i DevOps Tech Talk, where we discuss key topics and questions with ARCAD experts. I’m Ray Bernardi from ARCAD Software. And with me today is Alan Ashley and Nicholas DeLessio. Nicholas is an expert in our product CodeChecker. It’s designed to improve the quality of your code. We’ll be asking him some questions today. Let’s get started. Nicholas, we’re hearing a lot about coding standards. Can you tell us why this is?

Nicholas DeLessio – Coding standards are important thing to implement in any case, just for usability and maintainability of code. I think in this case, in the RPG world, it has a unique set of challenges around it. So RPG has the distinction of being an older programing language. One of the old is still in regular use. But at the same time also being one of the most updated programs and languages in that style.
When you compare it to something like Fortran or COBOL, that means that in the RPG world, code that was written 20 years ago is going to look a lot different than code that was written in the last couple of years. And code written 40 years ago is going to look a lot different than 20 years ago. So it becomes common in this space with developers who have entered the field at all different times to have standards that are all over the place. So it’s sometimes difficult in that kind of scenario to keep up with standards. It can become muddled.

R.B. – I can understand that. Alan, you have a question.

Alan Ashley – Nicholas, you’ve talked about how old RPG is and where it’s come from and that there’s some development going on. So with that are there benefits to implementing a coding standard?

N.D. – Yes. Definitely. So just in general, when you implement a coding standard, it makes code a lot easier to read and maintain. From a developer standpoint, this means less time wasted trying to figure out what the program’s doing and more time actually getting the problem solved and moving on to other things. From a business perspective, that means that if you hire on a new developer that can ramp onto your system and be productive a lot quicker, and as far as RPG goes, keeping up to the most modern standards means that newer developers who maybe have more experience in other fields, are going to have an easier time looking at RPG code, as the newer standards in RPG are a lot more similar to a C based programing language, whereas, older column formatted code is going to be a little bit more foreign to a new developer.

R.B. – So it does sound like there are some benefits.

A.A. – What are some of the examples that you can give for coding practices? Maybe something that you should avoid or something that you can improve?

N.D. – In the RPG world specifically. And this is kind of an example of how practices have changed in the RPG world. We could just talk about a very basic thing, like the length of variable names. Now, in the older RPG world, this was at one point limited to six characters and then it went up to eight and then ten, and now no such limit exists.
So one thing that, you can do in modern RPG that it isn’t really possible in older RPG is have descriptive variable names. Now, if you come from a certain era of RPG development, this is might not be, intuitive to do because you’re used to coming up with a coded name, how on some systems you’ll just have things that, to any outsider, would just look like a random string of characters, but they have very specific meanings within different ERPs or whatever.
But, with modern practices, you can name things as they are. If something’s an order number, you call it the order number and you can just read it. You don’t obviously want something that’s a whole paragraph, but just giving it a nice descriptive name is just going to make your code a lot easier to read.

R.B. – So you’re talking about good coding practices and good examples, things you should avoid. What does ARCAD bring to the table to make any of this easier?

N.D. – So two things really. So ARCAD has a product called CodeChecker. And within that product we have a new set of best practices that exist within. So CodeChecker is essentially a product that can look over and comb through your code and find whether or not certain rules are being adhered to or not. And then within that product we have identified and defined a set of rules that we consider to be best practices that as a developer or as an organization, you can turn on or off at will.

R.B. – So CodeChecker comes ready to use with a whole bunch of rule sets already?

N.D. – Yes. And, these rule sets are vetted from veterans in the industry, people like Jim Buck, Barbara Morris. So we’ve gone over different things that are designed to be best practices or otherwise, style guides in the RPG world. And we’ve kind of combed through them, found the ones that we feel are important and used in-house development, experience to kind of look over these and came up with a set of best practices that can be applied over a broad range of code.

R.B. – So could you take these rules right out of the box and use them to, like, identify your technical debt within your organization?

N.D. – For the most part, yes. So obviously not every organization is going to sit perfectly in a little box, and it always pays to look through and decide what’s best. But on the whole, with the amount of vetting we’ve done, it wouldn’t be bad to run code through this rule set and see if it applies.

R.B. – Now, is this 100% RPG specific or can I look at other things?

N.D. – So the CodeChecker product isn’t limited to RPG. It’s able to look at COBOL and CL. The specific rules we’re talking about here were written for RPG.

R.B. – How many rules are we talking about actually in this product?

N.D. – So CodeChecker on the whole I think has 116 rules, 125 metrics, 74 metric models, 16 rules sets. Now, the new rules we’re talking about is a little bit more limited and more targeted. That’s 35 new rules or thereabouts, over five new rule sets. There are other rules that can be looked at and applied in more specific cases.
And these rules are kind of an amalgamation of rules that other businesses have used and exist in the tool.

A.A. – Can we take a step back? You mentioned some of the support that CodeChecker has in it. Does it support SQL?

N.D. – Yes. CodeChecker can look at SQL (or Sequel).

A.A. – So you can start to look for those things, maybe security flaws that may be in your code from an SQL statement.

N.D. – Yes. And we do have a handful of rules in there to cover some of those things like doing a select over an entire file or all the fields in a file or that sort of thing.

A.A. – Now, you’ve mentioned how CodeChecker looks at code and how it manages code, and how it can help set those standards. You’ve covered where ARCAD fits into this, and you’ve covered what languages are supported in here with the SQL and C, some COBOL as well as of course, RPG. But I know a lot of people like to get into the automation of things.
They want to be able to maybe run this in the background after hours, or have it part of a pipeline process. Can CodeChecker fit into that pipeline and be automated?

N.D. – Oh yes. Absolutely. It doesn’t just have to be run up front. Definitely it can fit in as part of a DevOps process. One newer feature in it is that it can actually run as in delta mode off of the existing git branch. This is useful in cases where we want to make sure that new rule violations are being introduced, but we want to maybe be a little bit more lenient with things that are already up on the box to separate those kinds of different projects. Maybe you want to put off fixing those things until a later date. A developer can run CodeChecker over an entire source file if they want, just to identify rule breaks within a source file, it can be used on the fly as well, and it can fit as part of a larger pipelines like whatever you’re using. That would be maybe Azure or Jenkins.

A.A. – Yes, I can totally see how this could fit into a process along with project management, because you can run this up front and maybe get that list of suggestions. I’ll put it on things that need to be improved upon to fit these standards. And this can be then incorporated into future versions that come out saying, hey, if you’re working on this piece of code, go ahead and make these updates and make these changes to fit the standard that we have or the company has implemented. So the things go forth.

N.D. – Yes, absolutely. And it’s also worth mentioning that it can also tie a report back into SonarQube as well, if that’s a solution you’re using.

R.B. – So that’s how CodeChecker identifies the issues. Is that what it does when it sees things, it reports?

N.D. – Yes. So we talked a little bit about rule sets. Essentially it’s going to use those rule sets whichever ones you’ve checked on or off or decided to implement and fire those off at a limit that you have the freedom to control. So one thing that kind of sets CodeChecker apart here is that these rules don’t have to be a hard stop.
They can be just a warning or informational versus failure to compile at the hardest level. So that’s kind of up to the business to control whether or not this is something we want to stop or just gently steer in the right direction.

R.B. – And it sounds like all of us can totally shift left all the way down to the development phase?

N.D. – Yes. You can tackle it at the lower level there and have it so that it’s not a problem later on when you have to maintain that code later. That’s kind of the idea is you put the work in now when the code is at the development phase and that’s just going to make the code easier for everyone to read and maintain later on.
Even the developer who wrote it. And maybe you don’t have to maintain that for two years, and you have to go back in and look at that code and be like who wrote this? You.

R.B. – We are all about shift left here. That is for sure.

A.A. – Now, you’ve talked about how this can be split in as part of a pipeline, maybe a Jenkins pipeline to kick something off as you’re going through your various builds and, working on updating your code. As a developer, where can I use CodeChecker? Because personally, I love using VS Code. But I know some of my folks aren’t so thrilled with VS Code yet and working RDi.
Are those options?

N.D. – Yes. Actually, CodeChecker is very flexible in that regard because it can be used as a standalone outside of any idea, it can be used in Rdi as a plugin and also can be used in VS Code as an extension.

A.A. – Oh, that’s nice that I can kind of bring your own tool to the set and continue to keep working on this. Now, as we begin to wrap this up here, I do have one other question. You mentioned going back. All these rules and metrics and models and rules sets that are in the box, so can these be customized? Can you add new ones?

N.D. – So first off, any rule that exists in the tool can be shut on and off. And to some extent can even be modified with variables. Like for example, we talked a little bit about the name lengths, ARCAD has come up with a specific set of lengths there to look for, but those variables can be changed based on your individual needs too.
So what we have here, nothing is set in stone. So within the individual rules they can be shut on and off. They can be made to warnings or if you find something is more important, you can make it a hard stop. And on top of that, with the given metric and metric models that we have, new rules can even be created by your business using our existing metrics and metric models.

R.B. – So it sounds like CodeChecker, a solution right out of the box. And it’s also a tool. You can customize it to suit your own needs.

N.D. – I would say that’s accurate.

R.B. – So in the end, it really sounds like CodeChecker is like something that you need that you should be doing.

N.D. – Yes, it definitely makes development easier. It makes maintaining code easier. It’s a very powerful linter. So it will definitely help make it easier to build up, maintain good code that meets best practices and, good standards for your business.

R.B. – Automation sounds a lot better than a peer review meeting that takes half a day. So that was a great discussion around code quality and CodeChecker. Thanks, guys. I appreciate you being here with us today.

Our Hosts

Alan Ashley

Alan Ashley

Solution Architect, ARCAD Software

Alan has been in support and promotion of the IBM i platform for over 30 years and is the Presales Consultant for DevOps on IBM i role with ARCAD Software. Prior to joining ARCAD Software, he spent many years in multiple roles within IBM from supporting customers through HA to DR to Application promotion to migrations of the IBM i to the cloud. In those roles, he saw first hand the pains many have with Application Lifecycle Management, modernization, and data protection. His passion in those areas fits right in with the ARCAD suite of products.

Cécile Masson

Ray Bernardi

Senior Consultant, ARCAD Software

Ray is a 30-year IT veteran and currently a Pre/Post Sales technical Support Specialist for ARCAD Software, international ISV and IBM Business Partner. He has been involved with the development and sales of many cutting edge software products throughout his career, with specialist knowledge in Application Lifecycle Management (ALM) products from ARCAD Software covering a broad range of functional areas including enterprise IBM i modernization and DevOps.

 

Cécile Masson

Nicholas DeLessio

DevOps Consultant, ARCAD Software

Nicholas DeLessio serves customers as a consultant at ARCAD Software, with his expertise rooted in a deep understanding of IBM i. His career highlights include software analysis and development at a leading appliance manufacturer, full-stack project management at an iSeries consulting firm, and quality assurance with a market leading QA shop. These experiences have honed his skills in code modernization, agile development, and end-to-end project management, underscoring his proficiency in IBM i consulting.