Haven't tried them out yet.
Absolutely. All my code is in a library of some sort... either a lvlib or a class. Usually a class inside a library.
- Use lvlibs to divvy up your application into modules; it helps keep your code organized. As an added bonus libraries make it a little easier for multiple developers to work on the same project. Much less fighting over who gets to checkout the .lvproj file.
- Make liberal use of privately scoped classes inside a lvlib. Typically a module has too much functionality to fit inside a single class. Break the module's functionality into separate classes and make them private. Expose the needed higher level functionality through a few public api classes. Your modules will be much easier to use.
- Tight coupling within a module = good. Tight coupling between modules = bad (usually.)
- If you persist your classes objects to disk, don't change their namespace... ever. That resets all the internal mutation data.
- Give your libraries descriptive names. Letters are cheap... don't be a scrooge.
- Always, always, always be aware of your dependencies between modules. Avoid cyclic dependencies.