Code review checklist for AS/400 application

10 pts.
Tags:
AS/400
AS/400 applications
Hi, As part of Unit Testing process documentation, I need to prepare 'Code review checklist' for AS/400 application. Request the members to please share the same.
1

Answer Wiki

Thanks. We'll let you know when a new response is added.

Generally a Code Review is not include in the Unit Test Process.

The Unit Test is done by the QA staff or the end users.

A code review is the IT Developement staff looking at the actual source code.

Discuss This Question: 8  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • TomLiotta
    Unit Testing is often not done by QA and is generally impossible for end users. A Unit Test tests a "unit" in isolation. It most often is created by the developer and commonly performed by the developer, usually because of the difficulty in getting it done by anyone else. I usually first code a CL wrapper that passes in a set of known values and compares actual results to expected results. The "unit" being tested might be a procedure or a *PGM, but it will not be integrated with other elements. It will succeed or fail as a 'Unit'.   As the 'unit' is iteratively developed, the wrapper might also be developed more. Ideally, a database of test values and expected results allows the wrapper to repeat tests automatically and to test new combinations of inputs.   Unit Testing should be done all through the development of the component (the 'unit'). Depending on development methodology, the site standards and other considerations, code review probably shouldn't be done until after the developer is satisfied with the Unit Test. The code is then assumed by the developer to be ready for review. Any test wrapper can also be promoted for QA's use.   The code review should then be reviewing code that "works". The review may find numerous issues with quality or standards or simply unexpected circumstances. Because the Unit Test already exists, fixes may be tested as soon as they're made, and a subsequent review can conceivably be made later the same day, or at least it can be made soon enough that reviewers are still freshly familiar with the code.   A code review should review code that is candidate for promotion. There is less need to review code that is known will be massively modified.   As for what a code review should physically consist of, I suggest starting with two Google searches, first for [ code review ] and second for [ code review checklist ].   What works for me is unlikely to work well for you. The types of code and their purposes are likely to be very different. For example, the last major code unit I created was an interface-matching replacement for IBM's Qp0lProcessSubtree()--Process a Path Name API. That's not the kind of code most sites see. Reviews would have different focuses.   If you read a few articles on code reviews, you can then look over some of the code-review checklists already available on the internet. It's likely that many of them won't seem to apply to you, but you can cut & paste parts together to custom build one that seems to work in your environment.   When you create a first example, you might paste it back here to see if anyone can add bits that weren't obvious before. But it will be bits added to something that you think fits. It won't be something that works in some other shop.   Tom
    125,585 pointsBadges:
    report
  • ToddN2000
    @ashoklamb12: A job? where? is there a site that has the specifics you are looking for? There are a lot of users here that may have an interest and some have 20 - 30 + years experience.
    131,625 pointsBadges:
    report
  • azohawk

    I don't have a list (that was just being discussed for implementation at my previous employment at the time of my departure).

    However, I would think you would want to look at how the code compares to the departmental standards.

    Use of current vs obsolete opcodes. (I saw a recent post with CABxx opcodes-who does that anymore?)

    Efficient use of code. I have encountered code that used multiple lines of code to do what could be performed a single line of code.

    Is code that should be in a called procedure used in the code instead of the procedure?

    Variable names clear  (i.e. we are not using variable A1 for the Customer Number)

    Internal documentation, sufficient? No useless/redundant documentation (i.e. the code is self explanatory enough?)

    Screens and reports well designed? Do they make sense?

    Best techniques used?  Could an SQL statement be a better technique in part of the code?

    Keep the code modern (I have a predecessor that used RPGIV specifications, but the code looks very much like RPG II (conditioning indicators, GOTO, etc.)



    4,055 pointsBadges:
    report
  • TheRealRaven
    @azohawk : I had a job interview just over 20 yrs ago, and I messed up on one RPG-related question -- What are some of the UNstructured op-codes?

    I couldn't think of any, but all other parts of the interview meetings were easy. I asked that interviewer later about the question, and she mentioned CABEQ. It had been so long since I'd used that group of op-codes that I (temporarily) forgot about them.

    I have to agree. If they were forgotten 20+ years ago, why use them today?

    For this question, there are principles that make sense. For example, first principle that I learned is "Make it work, THEN make it pretty."

    That is focus on correct operation long before trying to make it better. For example, don't get hung up on squeezing a few more micro-seconds of performance out of anything until after you're sure that the procedure actually is correct.
    34,465 pointsBadges:
    report
  • azohawk

    @TheRealRavin I will agree, that it has to work correctly first before making it pretty.  By time it gets to code review, I think that should be resolved.

    One thing I would add to my list, Is the code readable?  I have looked at code and wondered what it is supposed to be doing. Favorite line of code I ever encountered:  *off doueq *on

     

    4,055 pointsBadges:
    report
  • azohawk

    I recall one job interview, I was asked to read some code and tell the interviewer what the code was doing. I read the documentation and said "it has something to do with payroll" and was asked "how did you get that so fast", to which I replied "I read the documentation".  I never heard back from them after the interview.  I thought we did documentation to make it easier for someone coming after me (or even me in 6 months).


    4,055 pointsBadges:
    report
  • ToddN2000
    I agree with the function over beauty aspect. Many times I have worked an a project I thought was a one and done. Did not use good field names they just wanted something real quick, down and dirty. (one my my old bosses back in my punched card days used variables like a,  b,  c  for quick fix programs). Then they thought they'd try it again a week or 2 later.. now it's part of their daily routine... Had I known it would lead to this it may have been written more efficiently and more documented...I feel anything that goes into long term use should be flowcharted for making the logic flow easier for others to understand.
    131,625 pointsBadges:
    report
  • azohawk

    Punch cards, what are they. Just kidding. I had to write one program on punch cards in a COBOL class "for the experience".  I came across a website today that is a tutorial (last updated in 2015) for RPG, not even RPGII. I had never seen old style RPG previously, so that was interesting to look at (thankfully, never have to code in).  I did do a little with RPGII (not much), really starting with RPGIII and progressing to RPG free.  

    I have used variables like a, b, c for counters, particularly in RPGIII with arrays and tables since there really wasn't much space for larger variables in those situations. But, I always documented the variable name and use in the program header.

    4,055 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: