Produce better code and exchange knowledge with code reviews.

One of the most typical obstacles with the adoption of modern programming techniques in RPG shops is the fact that everyone is at a different level of knowledge in different areas. All programmers have their areas of work that they find important, and they may not always be in the same genre. With code reviews, you give all of the people with different flavors of programming styles the opportunity to share their knowledge with the others on the staff.

What Is a Code Review?

A code review is a process in which you have other programmers review your code to see if any improvements can be made, whether it be in coding style, business logic, or compliance to standards. This can be as formal or informal as you and your staff want. From my experience, a code review is a scheduled meeting in which invitations are sent out to other programmers on your staff who can opt to join or not, based upon availability and interest. Of course, it is strongly encouraged that as many people join as possible to get the full benefits.

• The organizer of code review is typically the software developer/programmer who will be conducting the code review.
• Invitations are sent either verbally or electronically, with flexibility of scheduling based upon participant availability
• The organizer may include material relevant to the code review either with the invitation or at least a day prior to the code review so that the participants can review your material to ask relevant questions during the review.
• The code review should preferably be in a location other than your desk so that you can focus on the code review without interruption, although if you are having frequent informal code reviews with a single participant, then working at your desk could be the best option.
• If you have multiple participants, the code review should try to be contained to within an hour's time to respect the work load of the participants but still give you enough time to cover the key points. This is just a basic guideline and can be adjusted based upon frequency of reviews and amount of material to cover.
• Every code review should have an introduction at the beginning to discuss the objectives and intended functionality of the code that you will be reviewing. This should set the direction of the feedback you will be receiving.
• Code reviews are intended to be interactive. If the organizer were the only one speaking, then it would be more of a training session, which is only one component of a code review. The organizer should organize the presentation to cover a specific topic at a time, with a point where the floor is turned over to the participants to provide feedback or ask questions.

Programmer Interests

Programming is an art, and the attributes of programmers may be different. What is considered important to one programmer may not be considered important to another.

Some programmers may find importance in the ultimate code that is designed to perfection. This is an admirable goal in a purist way, but sometimes the quest for coding perfection results in minimal results for completed code because the search for the best way or constant rewriting gets you nowhere.

Then you have the no-nonsense programmers who just get the immediate job in front of them done. This will get you quick results for the immediate job, but if you don't consider any best-practice coding methods for reusability, then you're building spaghetti code that will grow to a certain point and then become unmanageable.

The no-nonsense programming style has a relatively constant development time because every project is practically autonomous from all of the other programs, whereas a modular program requires more front-end time for better design and provides quicker and more stable future reuse of the code.

Programmer Experience

Code reviews have multiple advantages because you can review the code and the coding styles to expose others to your logic and have others provide input that may make the code better. Code reviews can become toxic sometimes when opinions become involved, but there must be an agreement that different styles can be discussed and evaluated with a true purpose of functionality. If the differences are small, then freedom of expression should not be discouraged, but if the styles are different enough to cause readability or standardization issues, then it's best to be diplomatic and prepare a list of agreed-upon standards that are publicly accessible and easy to understand.

Simplify Your Standards

If the specifications are too detailed and lengthy, they are no longer a quick reference and they become a means of slowing down development and turning code reviews into semi-legal disputes of how the rules are translated. That is clearly not the intent of the standards.

Clearly Define the Priorities

When you are considering the possibility of code reviews in your shop, you need to define your objectives, just as you would with any undertaking that will improve your software. And if you can define your objectives ahead of time, you may be able to take full advantage of everything that is available.

Each project has its own set of priorities, which is typically determined by the deadlines you have for your project, taking into account the balance between simplicity, functionality, reusability, performance, and maintenance. This line is relative to your staff and situation, and it needs to be diplomatically agreed upon.

If you're in the early stages of development of a new project or contemplating a complete rewrite of a system, your code review should be more open to design changes that may significantly change the overall design of your plans, with a lot of suggestions toward modularity, modern programming techniques, and potential portability. These features will make your code easily reusable for other software projects and easily shared with other members of your staff.

If you're on a super tight deadline, then encapsulation and modulation may not be your number one priority. Sometimes you have to get the code working, test it thoroughly, and get the money machine rolling. If you're too idealistic, your development projects may never get done. You'll have a pretty car with no motor in it versus having an ugly old tractor that brings home the crops.

So if you define your goals ahead of time, you can focus on everyone reviewing the business logic to find anything that is missing, instead of focusing on using things like using a procedure instead of a subroutine.

On the other side of the coin, if you are at the beginning stages of putting together the building blocks that will be reused throughout an entire project, then you can take the time to fine-tune your code to be as pretty as possible.

Business Logic with Programming Style

When you have your programming staff together, no matter how large or small, this is an opportunity to take advantage of all of the skills available. Some of your programmers may be well-versed in different programming languages and techniques but may be light in the understanding of the business. Conversely, you may have some programmers who know the purpose of the business inside and out but may not be as up to date with their programming skills. This is a perfect opportunity to harvest all of your skill sets to create the best code possible.

Of course, you will have cases where some of your staff is more well-versed in one aspect over another, so if you have someone who is not a seasoned veteran to the business but has plenty of programming experience, which is a common situation with the current economy and job changes, then the code review could involve showing the salty dogs some new coding tricks and at the same time getting confirmation on the logic of the code that is trying to accomplish the project objectives.

If the person giving the code review is new at adapting modern coding techniques but is extremely familiar with the business logic, then this is a good opportunity to allow others who have experience with the new coding techniques to provide input on experiences that they have had, provide useful input on how to do things better, or provide confirmation that their approach is feasible.

Resource Awareness

When you have code reviews, there are so many things to take advantage of. One of the things I would like to see available for RPG programs would be a documentation tool, like JavaDoc for Java, that creates standardized, easy-to-read HTML pages that provide a list of objects and methods that are available.

With service programs coming of age in RPG, it would be great if there were a similar tool that could show the service programs that are contained in a binding directory and list all of the available procedures. But, until that day comes, you can use your code reviews to discuss the newly available service programs and the associated procedures to make everyone aware that they are available. And while they are learning about it, they could also review it to make sure it is written in the best coding style and will produce the desired results.

In addition to providing exposure to new procedures that are available, you are also making the other members of your staff aware of what projects you are working on. So, if you are working on something that is in the realm of another project that is in progress, you may be able to collaborate and develop the new procedures with a joint purpose that will immediately result in optimum return and will provide a good building block for the additional project.

Be Open 

This may be one of the hardest obstacles to overcome, and it's sometimes easier said than done, but it's well worth the effort and can be very rewarding. Of course, when you are creating your programs, you take pride in the work that you've done. To open yourself up to potential criticism, you have to be prepared for it. Try not to make it into a religious belief. What is your goal in your development? Is it to be the self-proclaimed smartest person who considers everyone else to be less intelligent (which makes you the least intelligent person in the room), or is it to actually find the best answer? 

Be Prepared

Preparing for a code review forces you to seriously evaluate your code to make sure you are doing it in the best means possible so that, when the code review occurs, you are prepared to answer questions about why you did things the way you did. Here's why: If you can clearly define your intent, but someone knows a better way, they can show that to you with the intentions that you've had in mind. Or possibly someone in the review has a similar issue that they could reuse your code in.

Be Generous and Accommodating

When you do have some awesome code to share, make it easily accessible so others can get at it. I see code reviews as being bidirectional in terms of who is gaining benefits, because you are giving resources to the others who you are working with, and they are providing feedback and recommendations to make your code that much better. If you present awesome functionality but show only segments that are incomplete, anyone adopting your code could get frustrated when it doesn't work. Unless you're looking for job security by not sharing your secrets, then you should share your code.

Assist Others 

If you happen to be the most experienced person in your programming language, it will definitely be easier for you to have confidence in your code review because you would be playing the teacher role versus the student who may be self-conscious and discouraged by too much constructive criticism. So take the time to work one on one with your peers to possibly review the code ahead of time for contained recommendations, which will make the code review more positive when it happens.

Programming Nirvana

"Programming nirvana" is a term that would most commonly be outside of my comfort zone, but it is the exact definition that I shared with a fellow programmer when describing the rewarding feeling of a successful code review. She was also a code review advocate and a friend. I hope that is she and the rest of the team are continuing to enjoy their weekly code reviews.

I know that code reviews can seem initially intimidating because you're exposing yourself to criticism. And it may seem cumbersome to allocate the time to have yet another meeting. But when you look at all the benefits that can be gained from having them, I see it as yet another valuable tool in modernizing your coding process, and you will actually be reducing development time when your staff is more aware of the resources available and best practices. It also gives you a chance to show off the cool new things you've been working on, which doesn't hurt.

The fact that your company is willing to allocate the time to have code reviews shows that the quality of the code is a valuable asset. I am fortunate enough to have been able to participate in productive code reviews with enthusiastic participants. I find the whole process to be a very positive experience and beneficial for better code and collaboration within your team.

I hope that there was no bias inferred in this article toward the desire to create great code versus down-and-dirty, getting-the-job-done coding. I am guilty of both sides and believe there is a time and a place for both coding styles. If you make good decisions during the initial stages of development in the design stage with best-practice evaluation you can apply the right tactics to the right situation.

as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7, V6R1

Thomas Snyder has a diverse spectrum of programming experience encompassing IBM technologies, open source, Apple, and Microsoft and using these technologies with applications on the server, on the web, or on mobile devices.

Tom has more than 20 years' experience as a software developer in various environments, primarily in RPG, Java, C#, and PHP. He holds certifications in Java from Sun and PHP from Zend. Prior to software development, Tom worked as a hardware engineer at Intel. He is a proud United States Naval Veteran Submariner who served aboard the USS Whale SSN638 submarine.

Tom is the bestselling author of Advanced, Integrated RPG, which covers the latest programming techniques for RPG ILE and Java to use open-source technologies. His latest book, co-written with Vedish Shah, is Extract, Transform, and Load with SQL Server Integration Services.

Originally from and currently residing in Scranton, Pennsylvania, Tom is currently involved in a mobile application startup company, JoltRabbit LLC.

---

MC Press books written by Thomas Snyder available now on the MC Press Bookstore.

		Advanced, Integrated RPG See how to take advantage of the latest technologies from within existing RPG applications. List Price $79.95 Now On Sale
		Extract, Transform, and Load with SQL Server Integration Services Learn how to implement Microsoft’s SQL Server Integration Services for business applications. List Price $79.95 Now On Sale

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails