10 Tips how to make a smartform easier and more readable

[Florian]

Hi all,

As in my blogs before I’m a fan of the counting things. Today I want to share my experience in an area I’m a heavy user. I develop a lot of forms in my career as an ABAPer and I also worked through a lot of it. Unfortunaly I also see a lot of things, which make a form very hard to understand and out of that, form-programming is one of the things a lot of developers do not like that much.

In my case, I’m very into it, because I like the output in the end. Sometimes I get a paper in my hand, I developed before and now I’m one of the “aimed” which the company wants to provide information.

Ok, there are also some, I do not love to get in my hand, bills and stuff like that :lol:

Back to the topic, what I wanted to say before is, that forms doesn’t have to be complicated and difficult to debug if you follow some rules and with this blog I want to share some of the main rules you should really set a focus at.

I’m not saying that there is for every special case a solution in, but I’m absolutely convinced that 95 percent will be getting easier to handle by one of the guidelines here.

First point: Give your smartform a name, which is readable

This is an easy point to archive, but why are names out there, nobody can understand. I mean, is it really necessary to name a form WLF_INVLI01?  You got enough letters left, to provide a readable easy to find name to your form... I think there are the 2KB left on the disk

2^nd point: Name your nodes, use the description field

Another easy enemy to fight. I know it is always a messie work to go through the tree and give everything a name. But be sure, as in another blog I published, your work will return one time and be sure, a form will return a lot earlier than the rest :razz:

You will love the minutes, you invested in this point.

3^rd point: Use folders in your main-window

Add folders as much as you can, it is a fantastic thing to get a clear view in your form, it makes the life a lot easier and you will find the correct spots to enhance something a lot faster than before

4^th point: Mark your special things in the form

Everybody who ever developed a form came once to the point thinking about saving a coding for later. Customer called, say something is to replace and you, as a developer, know right in that moment, this coding returns and you do not want to trash the output before.  There are two ways to fight a thing like that: First is you save your form with all data, you just download it or create a copy in the system. That works most of the times not that good, because it is just a little spot you want to save for further developing. That’s the point I refer to point three again, if you use folders you can deactivate it by adding a condition 0 = 1 (you know, code inspector do not like 1 = 2 that much :twisted: ) and give a clue to it.

Perhaps as shown below.

5^th point: Create easy Conditions if you really need some

Most of the conditions in a form I see are really not necessary. It would be a lot easier if the content would be passed to the form in way, it is printed. But if you really need to develop conditions, create easy conditions. Do not double your conditions, just because you need to hide two or more fields at once… again point three cross our street :!:

6^th point: Do not hide coding-nodes in your form

We all know, it is a really easy thing in a smartform to add some values to an output. Developers might know sentences like “Add me additional customer-number right at that place.” Doesn’t take long, am I right? Yeah, but that is a returning thing in a way, nobody wants to face. It is fast and easy to create a coding-node in the depth of your smartform, but does your younger colleague next to you find it again. Or better, do you remember that node in three month again? Exact that is the point, you dig a grave and waste a lot of time in future, just because you save right now 15 to 30 minutes to do it in a good way.

7^th point: Do not use the coding-nodes

Right before we talked about creating the nodes and now I’m saying do not use it at all? Are you crazy? No, I’m not (at least I think that :smile: ) and why I’m adding this as an extra point. I’m adding this as an extra point, because there are a lot of disadvantages. You know, the editor in the smartform itself is a joke, isn’t it? Not big, hard to read and if you write a few lines, you aren’t able to see everything. You have to add every import and export parameter extra and if you delete or rename one, you can easily waste 20 minutes with searching your form. Why don’t do things like that in your driver program. Big editor with all advantages, don’t have to say anything more here, do I?

It is all stuff which could be passed to the interface as well or at least done in one coding-node.

8^th point: Name your global and local variables in a good way

As mentioned in my intro, I work through a lot of forms and I’m always asking me, why people think, that a form is not restricted by the guidelines at all? Every developing is related to the guidelines, name conventions and stuff like that, globals start with GV_, locals with LV_ but having a look into a form brings names like SF_ which might be standfor smartform( if you found the transaction code I think you know where you are) or even things like nothing before…

I can just say, take a look in your guidelines and use the guidelines also here, just because it is a generated coding and it doesn’t look like developing a program it is Coding and so your guidelines take also care of this part of the project.

9^th point: SELECT from database is not a good solution at all!

It doesn’t matter in what context you are working, but I see a lot of SELECTS in the form-programming and I ask me every time the same question. Why do people think, that a form does not also get a count on the performance side. I mean, nobody would just program select without thinking twice in order confirmation or price-routines. But in a form it doesn’t matter? I know, nobody is perfect, sometimes it has to be fast and however you didn’t recognize it afterwards and it’s gone.  Just a example, there is a form with  30 SELECT-Statements in there, whoever work through all of that to see if it is required? Yeah, we all know the answer. There are a lot of companies out there and earn their money with performance-tuning. Here we got an easy way to bring our part in. But you have to remember it during you develop it. Spend now 20 minutes longer will save you in the future hours of refactoring and junk searching through junk forms. I know that feeling very well :cry:

10^th point: Use the interface

And here it is my major point. Most of the other points hit in that direction. Use the interface. If you do not know why, just go to point one again and start reading again :grin:

Thank you for reading to the end. I know, smartforms and all the form stuff aren’t that popular, but you know, in the end of each project and each single step in every company there is an invoice.

Feel free to add additional points or leave me a comment. I'm very interested to learn something new everyday, as you perhaps know.

Cheers

Florian

BTW: Most of the points are also the same if you use Adobe-Forms. It is the mass of javascript to avoid there :wink: