Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 06/10/2017 in all areas

  1. 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.
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.