...
- More than one procedure per module. Back in the day we did this to reduce generation time. Now it's just a pain, for several reasons:
- When you get a compile error that can't be sourced back to the app, Clarion will take you to the source file. It can be a hassle finding out which procedure is involved. If you have one procedure per module it's dead easy - just go to use module view in the APP.
- If you don't already use version control with Rick Martin's add-in you really should do so, and when you do that, one procedure per module makes a lot more sense.
- Bad prototypes/parameter lists. The very old way of doing this declaring procedures and functions is to put the data types in the prototype and the parameter names in the parameter list. Somewhere around Clarion 4 I believe this was changed so For years now (since Clarion 4?) the standard has been for the prototype and the parameter list are to be the same (except the parameter list doesn't allow cannot have a return type, which is seems like a silly omission). So do it Declare your procedures this way:
Prototype: (string var1, byte var2),string
Parameters: (string var1, byte var2)!,string
Note the ! before the return type in the parameter list. That makes it compilable and it leaves behind , to please the compiler. You can leave it off entirely but I like having it as a reminder of what this the procedure returns. - Global data - I can't believe I missed it this the first time around.Yes, sometimes you really do need it, but in general global data is trouble waiting to happen, especially unthreaded global data. When any code in your app can modify data potentially used by any other code in your app, mayhem awaits.
- Module data isn't as bad as global data, but it's not much better either. And it prevents you from using one procedure per module (see above).
- Huge apps. Keep your apps small, and try to group procedures in apps by functionality or some other useful taxonomic principle. If you're getting to 100 procedures or generation/compile times are slowing down, split up the app. DLLs are your friend.
- Short app and procedure names. You've already taken the advice to make your labels descriptive; do the same for your procedure and application names.
- Long procedure names and labels that aren't helpful. Anybody can come up with a long label, but does the label mean something now and, more importantly, will it make sense to you months or years from now when you've forgotten what the code does? As is often said, naming is really hard. But even a little care now pay dividends in time.