Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 12/16/2015 in all areas

  1. I put together a series of articles while working on an AF 101 presentation for our local CLD summit. Check them out and let me know what you think or if you have any questions/improvements. Part 1 – The Background Part 2 – The Actor Part 3 – Launching and Communicating Part 4 – Being Productive With Actors Basic Walkthrough – Creating a Logger
    1 point
  2. My oldest software that hasn't become "vapourware" seems to be the "windows_api_1.0.llb".It was written in LabVIEW 5 in the late 1990s but think I had it internally for a couple of years before I released it. It is posted in the CR after someone asked for it and is identical to the original except it was recompiled for 2009 and later so people could actually use it. Here is the original in LabVIEW 5. I can't actually open it any more but I'm pretty sure it is identical to the CR one. windows_api_1.0.llb
    1 point
  3. .Net is in some ways better than ActiveX in the areas Shaun mentions. ActiveX is an extension of OLE and COM which have their roots in old Windows 3.x times. Back then preemptive multitasking was something reserved for high end unix workstations and PCs had to live with cooperative multitasking. So many things in Windows 3.1 and OLE and COM assumed single threading environment or at best what Microsoft called apartment threading. This last one means that an application can have multiple threads but any particular object coming from an apartment threading component always has to be invoked from
    1 point
  4. I don't think the criteria I am posting is different from the general consensus of the previous replies, but it might help others as it helps me to decisively determine where to draw the line... I always filter comments based on whether they answer 'what am I doing' or 'how am I doing' something and leave out the 'hows'. The level of detail is based on what questions someone else familiar with the purpose of the SW would ask (the peer review scenario) or similarly, what I will forget about a couple months after finishing it (the SW update scenario). Exceptions would be comments answeri
    1 point
  5. I can pile on here. One reason not to over-comment is that then it makes it harder to figure out which comments are important. Sometimes less is more. Admittedly more often code suffers from a dearth of comments than from a surplus.
    1 point
  6. In general, Darren and I add comments to our diagrams when, during a buddy session, we actually have to explain what's going on to the other. That's our standard measure for when a comment is needed. If the buddy session proceeds without the other person getting lost as we walk through, then the code and the API documentation (i.e. the Context Help) likely suffices as it is. My instinct in this case would be to put a Diagram Disable structure down and put the other version that I had tried in the Disabled frame -- then I don't have to describe what I tried, people can look at it. Now, that
    1 point
  7. Wow, I head slapped myself silly after seeing that image, especially since that little piece of code was my modest contribution. I completely agree about OpenG showing best practice and all, I strongly disagree that this level of documentation is best practice. Looking at the original thread, the first suggested code was slightly more complex. I thought I would see if it was faster than the completely obvious method. It turns out no. Had the more complex code been faster, as it often can be, that would have been worth a comment. My usual philosophy is that well-written G is self-docum
    1 point
  8. For this particulary example I disagree with you. Comment is good, but all the comments in this particular example are in my opinion not needed since the code is very straight forward. When coding in C I wouldn't either comment code like "lenVariable = strlen(strVariable) // get the length of the string" In my opinion only parts of code which are not that straightforward, certain parts of a algorithm, should be documented. When all the parts of the algorithm are straightforward, as in this case, the only thing that needs to be documented is what the algorithm exactly does, which is already d
    1 point


×
×
  • Create New...

Important Information

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