Page 1 of 2   next page »

Welcome to a new column in PBDJ. In this column, we'll discuss all things "new" in PowerBuilder - from keys to success in starting new projects to tips and techniques you need to know to features in the latest, and upcoming, releases of the product.

Our mission is to guide you on your path to developing state-of-the-art, robust, maintainable applications using PowerBuilder and other technologies. Your mission is to ensure we are fulfilling our mission. Your feedback and input on past and future topics will be critical in making sure this column provides educational, accurate and, most importantly, useful information. Disclaimer: both Larry and I have many years of development experience to share with you, but there will inadvertently, and inevitably, be times where we present (slightly) inaccurate information. Please remember that those errors and omissions are ALWAYS Larry's fault.

Let's Get Started
Whether you're new to PowerBuilder or starting a new project, there are some keys to remember to help ensure a safe and successful endeavor. These aren't new concepts in software development, but somehow they get pushed aside and aren't given enough consideration. I'm referring to Standards and Frameworks.

Standards
Standards typically encompass naming and coding, but can include data modeling and architectural design as well. Whether you're staring a new project or joining an existing one, standards make it much easier to ensure that everyone is speaking the same language everywhere. Whether you're doing analysis in the database or modifying code in the application, it's ALWAYS easier when standards are used, communicated and enforced.

Too much time is wasted when similarly purposed columns in the database are named differently and selects won't compile because an account column is named acct in one table and accountCode in another table. Do you find it hard to jump into someone else's code when their naming and style conventions clash with your own? Does filtering take place in a where clause or in a DataWindow object or is it set dynamically in code? How are transactions handled? Does the application use embedded SQL or stored procedures? Is all database access only through DataWindow objects? How is security enforced in the application? Is code placed directly in window functions, behind command buttons, or in non-visuals objects (nvo's)? The list can go on and on but the bottom line is that inconsistencies cost time, stability, and maintainability.

Many of these issues will be determined by the project architects, DBAs, technical leads, and project managers. Hopefully, documentation exists that can be shared by the team members. Hopefully, someone does code reviews and enforces the standards that were developed. And, if any of these are missing, you may be able to add input to help make sure that they are addressed, or at least understand why they are not.

PowerBuilder tries to do its part with regard to naming standards. In the DataWindow painter, select Design| Options|Prefixes to see suggested DataWindow object naming prefixes. Other modifiable naming conventions are available from the Design|Options| Prefixes1 and Prefixes2 dialogs when you're in the script painter. In the User Guide, there are sections regarding naming conventions for objects, variables, user objects, and controls. Consult the index and look for naming conventions. If you don't have the User Guide, you can reference it online at www.sybase.com/support/manuals and select PowerBuilder from the product dropdown in the middle of the page. It's a good idea to use the PowerBuilder default prefixes since these are generally accepted standards in most PowerBuilder shops and projects.

One last note about naming conventions: Don't use naming conventions that are applicable to one tier or technology of your application in another tier or technology without good reason. Each technology or tier already has a fairly well established naming convention. It's very confusing and frustrating to find non-standard naming conventions. For example, while it's standard to find a variable named li_ReturnCode in PowerBuilder, using this same name in a stored procedure or Java code is nothing short of ridiculous.

While naming conventions propose a method of identifying object types and functions by their name, coding standards and style affect how the code looks. Are language keywords in all caps (e.g., IF ... THEN ... ENDIF)? Do variable names use underscores or capitalize the initial letter of each word in the variable name (e.g., ls_last_name or ls_LastName or ls_lastName)? Do objects have the associated application as part of the name (e.g., w_genapp_sheet or w_sheet)? How are parentheses to be demarcated (e.g. if (a < b) then or if( a < b ) then or if(a<b) then)?

Since coding standards and style are often the cause of wars, I certainly won't be so bold (read: stupid) to propose a particular standard or style. Whether you want to code in typical PowerBuilder fashion or in a Java-like style, or something else, the key is to develop a standard to maintain consistency.

You'll inevitability have to maintain or enhance someone else's code at some point in the project. It's so much easier when naming conventions are the same and coding styles are, at least, similar.

Frameworks
Frameworks are tricky. Well, hopefully, not the frameworks themselves, although, some certainly are. Whether to use a framework is the tricky question.

Frameworks, in theory, are wonderful things. They provide functionality that all applications need and let the developer concentrate on coding the business logic and user interface. Sometimes frameworks try to do too much and become behemoth-like and difficult to understand and use. Sometimes, frameworks do too little and don't provide any real value. Sometimes, a framework forces a rigorous methodology on developers that becomes more trouble than it's worth.

Page 1 of 2   next page »