Transcript Don`t Do That! Common Programming Mistakes

Please Don’t Do That!
Common Programming Mistakes
Tammy Lonsberry
Sr. Programmer/Analyst
Sungate Solutions, Inc.
About me

Tailoring and customizing Progress code for QAD
users since 1995





Most versions (Mfg/Pro 7.3 – QAD EA 2013 SE)
All User Interfaces (CHUI, GUI, Desktop, .NetUI)
Progress and Oracle db’s
Active PEG member
Long time consultant with exposure to many
different environments, processes, protocols
… and many lessons learned, too often the hard way
Agenda






Environment Setup
Programming Tips
Code Installation
Support and Maintenance
Summary
Questions
Environment Setup
Environment Setup Basics

The basics include a minimum of 3 databases
and 3 code environments

Databases:




Production
User Testing
Development
Code Environments:



Production
Test
Development
Directory Layout



Do: Keep custom code separate from QAD
Do: Keep 3rd-party code separate from QAD
Do: Keep “layers” of directories for the
separate code environments




Prod = top layer
Test = middle layer
Dev = lowest layer
Provide an easy way to peel away the
customizations and 3rd-party apps



Can run standard QAD with simple Propath change
Can run any code environment against any database
Better ability to isolate root cause of code issues
Propath Tips

Keep Propath consistent across all
environments, UI’s, users


.NetUI Propath should match non-.NetUI Propath
All end-users should use the same Propath




No source
Prod users = only Prod .r’s
Test users = Test then Prod
All developers should use the same Propath



Includes all source
Same directories in the same order
Eliminate guesswork; use <File>, <Open> to get correct
version of code
•
Watch for stale copies in your start-up directory; in Test
Propath Examples

Production (no source)
PROPATH=
.
/apps/qad/mods
/apps/qad/trm
/apps/qad
/apps/qad/bbi





Startup directory
Prod Mods (in-house custom code)
Trade Management (TrM)
QAD
Test
PROPATH=
.
/apps/qad/test
/apps/qad/mods
/apps/qad/trm
/apps/qad
/apps/qad/bbi
 Test Mods
 Prod Mods
Propath Examples

Development (full source)
PROPATH=
.
/apps/qad/test
/apps/qad/test/src
/apps/qad/mods
/apps/qad/mods/src
/apps/qad/trm
/apps/qad/trm/src
/apps/qad/trm/xrc
/apps/qad
/apps/qad/src
/apps/qad/xrc
/apps/qad/bbi












Startup directory
Test compiled .r’s
Test source code
Prod compiled .r’s
Prod source code
TrM compiled .r’s
TrM source
TrM encrypted source
QAD compiled .r’s
QAD source
QAD encrypted source
QAD (misc. include files)
Programming Tips
Programming Tips

Goal: Make code easier to read, understand

Leads to faster investigation, troubleshooting,
problem resolution
•

Faster response time = happy users & management
Do: Add code comments

Messages

Place message text within comment to assist with code
readability
/*ITEM NUMBER DOES NOT EXIST*/
{pxmsg.i &MSGNUM=16 &ERRORLEVEL=3}

Use brief code comments to explain why

The “what” is obvious; the “why” is not
•
•
Explain business reasons; these change over time
Explain why this logic/algorithm/method was used
Programming Tips

Don’t: Abbreviate field or variable names



Prohibits ease & effectiveness of text searches
Ex: Never use code_fld for code_fldname
Do: Recycle & Reuse


Recognize reusable code segments
Eliminate redundant code
•
•
•

No minimum number of lines; 2 lines repeated is too many
Gets out of sync too easily
Makes code unnecessarily lengthy, harder to read, harder to
maintain
Use internal procedures, include .i files, external
programs
Programming Tips

Do: Use QAD variables to gain bonus features


Example: Use part/part1, site/site1
Freebies include:



Field Labels (and their multi-language translations)
Field Lookup browses
Field Help
Bonus: Free Labels
Bonus: Free Lookups
Programming Tips

Custom copies – Think beyond the code

When creating a copy of a standard QAD program
in order to rename it and customize it, also check
for:


Lookup browses
Field labels


On screen
On output
Custom Copy Example
Programming Tips: Data

Code development often includes data, too

Examples of developer’s data:
•
•
•
•

Browses
Drill-downs
Field lookups
Generalized Codes
•
•
•
•
Labels
Menu options
Messages
Program Information
When creating data:


Always add to Dev database first
Avoid:



Collisions with other developers
Mismatches
Out-of-sync scenarios
Code Installation
Code Installation Do’s:


Do: Put source programs (.i, .p) in /src
directory
Do: Put compiled code (.r) in applicable 2letter subdirectories


Ex: /us/xx
Do: Keep all related .i’s, .p’s, .r’s in sync


Always installed together, into the same
environment, at the same time
Follow this for all code, including:



ECO’s (patches)
Add-on modules
3rd-party apps
Code Installation Don’ts:

Don’t: Put source programs in a 2-letter
subdirectories



Or in any directory except /src
Don’t: Install .r without corresponding source
Don’t: Keep duplicate copies in multiple
directories

Development directory should contain only code in
active development


When complete, move it to Test
Test directory should contain only code waiting to
be tested

When complete and approved, move it to Prod
Code Installation

Do: Devise and follow an installation process

Methods include:




List the steps, then step the list




Can use 3rd party apps
Can develop your own scripts, programs
Can be completely manual
Self-documenting
Becomes an easy checklist
Assists with code version control
Increases overall environment stability
Code Installation

Do: Use code “check out” process




Ensures that only one person is working on a
program at a time
Avoids coding conflicts
Avoids lost work, accidental overwrites
Sample check out method


Use a designated folder (ex: …/src/checkout)
Place a simple text file into this folder


File name = program name (ex: xxabc.p.txt)
Contents include:
•
•
•
Developer name or initials
Date
Reason (ex: ECO #, project ID, case #, etc.)
Code Installation

Do: Keep source code history



Can do immediate roll-backs
Can do diff’s to determine version changes
Sample code history method



Use a designated folder (ex: …/src/history)
Copy current Prod version to this folder
Add a date extension (ex: xxabc.p.20140324)
Installation Includes Data, Too

Manage data in the same manner as code

Data and code move through the installation steps
together; same place, same time



Data can be dumped and loaded



Dev  Test
Test  Prod
Don’t retype it into each database
Develop simple tailored versions of QAD’s dump/load
procedures
Browses


With .NetUI, can use Browse Import/Export
Without .NetUI, dump/load applicable tables
Installation Example
1.
Diff it



2.
Keep history

3.
(Prod only)
Copy production code; add date extension
Install code & data



4.
Compare your modified code to the existing version
Ensure the only changes are yours -- no more, no less
Do this for any environment (Test, Prod, etc.)
Includes source (.i, .p) and .r
Move, don’t copy
Load data into target database(s)
Remove check out file
(Prod only)
Support and Maintenance
Support and Maintenance



No program is ever 100% final
Always keep in mind future modifications,
enhancements, testing & troubleshooting
Don’t:



Develop a report without any selection criteria
Develop data exports, imports or interfaces
without any selection criteria
Develop a program that executes fully by simply
selecting it from the menu
Support and Maintenance

Do: Add more selection criteria than required



Do: Provide a way to do quick & simple
testing with a small number of records
Do: Provide a way to run every program and
process outside of production


Reports, data exports, imports
Especially useful for interfaces, data loads,
automated jobs, processes requiring scripting or
OS commands (such as FTP), etc.
Provide a way to test individual steps of a
larger process
Support and Maintenance

Provide intuitive menu titles

Make it clearly obvious what type of program it is
•
•
•
•

Maintenance
Report
Browse
Utility
Provide enhanced descriptions

Add details about a program’s function as
informative screen text
•
•
Especially helpful for utility programs, data exports and
imports
Ensure text is visible in .NetUI
Support and Maintenance

Always change Company Address after a
database refresh



Make it clear to users (and developers) what
database they are logged into
Ensure that report titles always indicate the
source database
Use 2.12 Company Address Maintenance

Change address for:
•
•
•
~reports
~screens
~taxes
Company Address Maintenance
Company Address: ~reports
adctryrp.p 2+
Page:
1
2.14.3 Country Code Report
Your Company Name **TEST**
Date: 03/13/14
Time: 11:20:59
Alt
Ctry Name
EC NAFTA DEA GATT Group
Type
Code
---- ---------------------------- --- ----- --- ---- -------- -------- ---UAE UAE
No No
No No
UKR Ukraine
No No
No No
URY Uruguay
No No
No No
USA United States of America
No No
No No
US
VEN Venezuela
No No
No No
VIR Virgin Islands (U.S.)
No No
No No
VNM Viet Nam
No No
No No
WIN West Indies
No No
No No
ZAF South Africa
No No
No No
End of Report
Company Address: ~screens
.NetUI Shows db:domain
Summary
Summary

Standards, policies and procedures – these
are not your enemy!

Following best practices leads to:




Faster response time
Happier end-users
Lower IT support costs
Less stress, less headaches
Questions?
Contact information

For further information or a copy of this
presentation:
Tammy Lonsberry
(847) 628-4796
[email protected]