Miscellaneous Hints and Tips

1. Keep specifications as simple as possible. In particular, keep the abstract data as simple as possible (simple abstract data makes for simple specifications). Where the abstract data is or contains a collection, use the built-in collection types (set, bag, seq and map) wherever possible.
    
2. Declare classes final unless you expect to derive other classes from them - this makes it easier to reason about them.
    
3. Use ref types sparingly. Only use them where you genuinely need to have two variables referring to the same object, such that any change made through one variable will be seen by the other.
    
4. Avoid redeclaring member variables as interface selectors. Try not to redeclare them as confined selectors either. Once you redeclare data variables as selectors, in addition to losing encapsulation, you lose the ability to refine them to more efficient implementations.
    
5. Don't even think about optimizing your component or application until you have specified it, generated a prototype, evaluated the prototype and achieved the desired degree of validation!
    
6. When you do come to optimize, use profiling to determine where the bottlenecks are. They may not be where you think! If you are generating C++, you can use the built-in profiling support (this is enabled by defining the macro _dProfile as the constant 1 when compiling the C++, then calling library methods within your application to start and stop profiling and to write the profile to file). The generated profile data file is unsorted, so in order to make sense of it, sort it into decreasing order of time spent. If you are using Multi-Edit or TextPad as your editor, it can do the sorting for you (you access the sort function from the Text menu of Multi_Edit or the Tools menu of TextPad).
    
7. Perfect does not support global variables, so you may find yourself passing parameters that would otherwise be global data. To avoid passing more than one value around, create a class to contain all the unchanging variables that you may wish to pass; then you can pass an instance of this class as a single parameter. You can easily add new variables to this class in the future.
    
8. Large projects can take a long time to verify. Modularize large projects so you can verify each module independently. Organize your work so you can run validation over a meal break or overnight.
    
9. For help on how to handle verification failures, see these helpful hints on verification, courtesy of Technische Universität Wien (opens in a separate page), and our basic tutorial.