Leaderboard

I was writing a login screen for a recent project that required me to verify that the password met certain criteria, i.e. at least eight characters, at least one cap, at least one number or special character, etc... I came up with the attached piece of code using regex, which, surprisingly for me, actually worked. I'm planning on leaving it this way, without any comments so when I find it five years from now I'll spend at least an hour wondering what the hell I was thinking. Anyone else have any utterly ridiculous code? Not spaghetti, just off the wall, makes no sense but works perfectly kind of code? -Ian

Yup. Any application I write after 6 months has elapsed

How about this gem?

http://forums.anandtech.com/showpost.php?p=33584072&postcount=15

That's because it is PCRE (Perl Compatible Regular Expressions). How about this for graphical programming? http://www.ioccc.org...hamano/hamano.c

Yeah, I hate regex because they're so difficult to decipher, but love them because they're so bloody powerful. Reminds me of perl code.

I like Ton’s idea. And not just for NI; having to compile a list of all licenses to make available in an executable is a pain, especially as no one will ever read them. While providing a license in source code is easy if the license is already on the FP, or BD, or documentation of the VI’s themselves. What about a test case? In OpenG there is a Trim Whitespace function that duplicates the same function in LabVIEW. Due to the work of several programmers, OpenG’s version has considerably higher performance. I don’t believe there is any other difference in function, no “advanced” features or anything, and thus no reason why the OpenG version shouldn’t be adopted as standard. What would it take to do this? — James

Late Friday night and almost in sleep mode... AQ said that to really reach out to all customers we really need to give our code to NI, but since LV 2011 we have the LabVIEW Tools Network built in to LabVIEW and this enables each and every user to easily install features they need (from OpenG, LAVA or LVTN). LVTN has no restrictions for licensing that I know of, but NI still reviews and put code under the NI umbrella and even publish some code of their own. I currently know nothing about JSON, but from reading through the threads here at LAVA it is probably something I will look into in the future. And when I do, I like to be able to select the implementation that I want to use; NI version, LAVA version or any other version. Installing these from LVTN/VIPM mean that new features/versions are available to me directly and I don't have to wait until the next LabVIEW release. Bugs detected in LVTN modules are also likely to be fixed much faster since the fix can be released regardless of the LabVIEW release cycle. /J

Here is the MCL control again (since the previous links in the Thread are broken). Thanks special MCL.vi

Here's the scenario to create a bug: change the interface of the VI with banner "Files" and wired enum "Save Cues" to have a string filepath instead of a Filepath filepath (perhaps not the best example... consider changing say a DBL to a U32). Yet that change was not propagated back to the message sender, whatever is stuffing that queue. Now, you've got a bug that manifests itself as a run-time bug. Whereas, if the Variant to Data had the Filepath wired as its type, that case structure above would have broken when the "Files" VI ConPane was changed. Sure, you could change the Variant to Data type within that case and still forget to change the message senders, but since you're in the domain of changing message datatypes, you're much more likely to remember to change the senders also. Whereas, in the current implementation above, a change to the ConPane of the "Files" VI might not necessarily trigger the correct synapses in your brain to also change your message datatypes. I guess in a nutshell it just simplifies the mental ruleset and memory stack size required of developers when you're able to depend on the broken run arrow and compiler messages. And that probably means fewer possibilities for creating bugs.