Thursday, April 26, 2007

Manipulating Data Files

Jim Kring posted techniques in his blog future-proofing data files by adding schema and version information to the file. Over the years, we’ve added some file formats to LabVIEW that make it hard for customers to follow his rules and that can cause problems.

I’ve seen folks hang themselves with the Datalog file by writing a file with one particular type definition (i.e. cluster) and then can’t read the file any more when they change clusters without understanding it will affect backward compatibility.

The newer file formats in LabVIEW like .TDM datalog files are much more maintainable because they store the type definition (typically called a ’schema’) in the data file so you can’t lose it and so it can be browsed by an external application.

Technorati tags: ,

Wednesday, April 25, 2007

Writing Stylish Code

Working on a codebase that is authored by a lot of people has given me a new appreciation for writing consistently styled code.  Even having 10 programmers all writing in a different way makes it hard to go in and modify or fix code written by someone else.  In the C/C++ community, there are constant wars about indention or variable naming. In the end, it's not really important which convention you pick, it's more important that you pick one and stick to it.


LabVIEW is no different and it may be a bit more difficult because we give you 2 dimensions (X and Y) in which to place your code rather than just one.  I just saw an announcement for a new LabVIEW book and thought I'd pass it along.


The LabVIEW Style Book - Peter A Blume



Best-Practice Style Rules and Standards for Developing Quality LabVIEW Software
Drawing on the experiences of a world-class LabVIEW development organization, The LabVIEW Style Book is the definitive guide to best practices in LabVIEW development.
Leading LabVIEW development manager Peter A. Blume presents practical guidelines or "rules" for optimizing every facet of your applications: ease of use, efficiency, readability, simplicity, performance, maintainability, and robustness. Blume explains each style rule thoroughly, presenting realistic examples and illustrations. He even presents "nonconforming" examples that show what not to do-and why not.


I like that he mentions a tool that we release and use internally for our own G code reviews



Code reviews: Enforcing a style convention using a checklist, the LabVIEW VI Analyzer Toolkit, and peer reviews


Check it out.



Technorati tags: ,


 

Labels: ,

FREE hit counter and Internet traffic statistics from freestats.com