boolean or Boolean? and other wiki style questions...

[Aristos Queue]

1. I noted a few uses of lowercase "boolean". Capitalizing that B is often confusing because it is the only non-class type that is typically capitalized. Text languages have solved this by using keyword "bool", and therefore that is the actual type name. LabVIEW doesn't typically type out data types. NI style guide says to capitalize Boolean. Does LV wiki agree?
2. When I'm editing the wiki, I will generally follow NI documentation style guidelines (so "subVI" instead of "SubVI", for example).
   Are there any particular conventions that the community has established that differ from NI standard practices?
3. When discussing language features (as opposed to editor features), LabVIEW 20xx uses "LabVIEW"... LabVIEW NXG has moved to using "G" and uses "LabVIEW" to discuss the IDE. We find that this provides clarity in many documents, and it provides less of a mouthful when speaking (The NXG root class is "G Object" instead of "LabVIEW Object", for example).
   Does the wiki prefer "LabVIEW" or "G" when discussing language features?
4. When behaviors diverge, what is the preferred way to document distinctions between LabVIEW 20xx and LabVIEW NXG? Should they be separate pages (so the former can be easily deprecated in the future) or do we prefer same-page-different-sections for easier side-by-side comparison?

 

[Rolf Kalbermatter]

While you bring up valid points here, I think there is no standard whatsoever in the community about this so far. Everybody does as he or she feels at that particular time of the day and may do it different the next day. So if you want to bring this up, it may be a good idea to document it somewhere in the wiki. Basically start some sort of recommended style guide there. Obviously not everyone will read it and even if someone does he won't be shot if he does not follow it. 😀

About your last point I would personally prefer to have different sections on the same page for now. I also don't see deprecation of pages going to happen anytime soon and definitely not as a separate task that anyone would take upon himself. If something will be deprecated in the future it will be likely as part of editing a page for other purposes such as adding information about new features or similar. And it is anyhow at least 7 years in the future as NI committed at some time to a support timeframe of 10 years for LabVIEW CG after the first NXG version was released. 😁

With the current progress of LabVIEW NXG that might be about the time it reaches feature dominance over LabVIEW CG. 😆

[Antoine Chalons]

I agree with Rolf, I think most people are not as strict as you are.

And while we're at it, what version of english should be used? American english or British english or any other flavour.

I thought about this when I read capitalising spelt with "z" 😂

[hooovahh]

All very good points and good concerns.  Personally I would capitalize Boolean, but I may forget occasionally.  I would also prefer subVI as I've gotten used to the NI standard.  I can see the confusion with LabVIEW and G, and often I go back to what the community at large uses.  If I say "My programming language of choice is G" some may confuse this with GCode, or something else.  If I say LabVIEW I think that conveys what I mean to the general public more.  For this reason I default to "LabVIEW" but at times will say G.  Public opinion may change, and that may mean updating the wiki.  And if there are specifics I'd prefer separate pages for 20xx and NXG, but whatever.

One thing you might not be aware of is that there is a place for page specific discussions on the Wiki Talk Page.  You could make an edit, but leave a comment asking for direction or leave it open to preference.

That being said I think the opinion of most moderators on the Wiki is more that getting something which is non-perfect, is better than having nothing.  I'd encourage others to make pages and fill in what they can, even if they are unsure of how to handle some of these differences.  Things can always be cleaned up and refined later.

[ShaunR]

On 7/12/2019 at 5:06 PM, Aristos Queue said:

I noted a few uses of lowercase "boolean". Capitalizing that B is often confusing because it is the only non-class type that is typically capitalized. Text languages have solved this by using keyword "bool", and therefore that is the actual type name.

This is a historical "problem" due to compilers being case sensitive. This was one of the reasons that I went for Pascal compilers over C since Object/Open/Turbo Pascal is case insensitive and boolean or Boolean are synonymous (as a type). I've always maintained that there is no excuse for case sensitvity as it only introduces errors, obfusicates and increases foot-shooting but has zero benefits (unless you consider obfusication a benefit which is arguably a security risk). 

I've had many conversations with C/C++ programmers over capitalisation of types and function names (initial caps vs camel case vs lower case etc) and my response has always been "whatever". Do we really need to bring this problem to a wiki, of all things, about a language in which case is irrelevant?

Edited July 15, 2019 by ShaunR

[JKSH]

6 hours ago, ShaunR said:

This is a historical "problem" due to compilers being case sensitive. This was one of the reasons that I went for Pascal compilers over C since Object/Open/Turbo Pascal is case insensitive and boolean or Boolean are synonymous (as a type). I've always maintained that there is no excuse for case sensitvity as it only introduces errors, obfusicates and increases foot-shooting but has zero benefits (unless you consider obfusication a benefit which is arguably a security risk). 

This thread is about literature, not code.

It's a question of finding a balance between practicality and professionalism. Side A can reasonably accuse Side B of being a Grammar Nazi while Side B can reasonably accuse Side A of being sloppy.

 

6 hours ago, ShaunR said:

I've had many conversations with C/C++ programmers over capitalisation of types and function names (initial caps vs camel case vs lower case etc) and my response has always been "whatever".

My response would be "be consistent within a project". Feel free to have different conventions across different projects.

So for the Wiki, we should at least be consistent within a single article or group of closely-related articles. Some might even argue that the whole Wiki is a single project.

 

6 hours ago, ShaunR said:

Do we really need to bring this problem to a wiki, of all things, about a language in which case is irrelevant?

No, as long as you don't care when people write "LabView".

[JKSH]

On 7/13/2019 at 12:06 AM, Aristos Queue said:

1. I noted a few uses of lowercase "boolean". Capitalizing that B is often confusing because it is the only non-class type that is typically capitalized. Text languages have solved this by using keyword "bool", and therefore that is the actual type name. LabVIEW doesn't typically type out data types. NI style guide says to capitalize Boolean. Does LV wiki agree?
2. When I'm editing the wiki, I will generally follow NI documentation style guidelines (so "subVI" instead of "SubVI", for example).
   Are there any particular conventions that the community has established that differ from NI standard practices?

These are purely stylistic issues. I'd personally prefer Boolean and  subVI, but I'll follow the community guidelines (when they are produced).

 

On 7/13/2019 at 12:06 AM, Aristos Queue said:

3. When discussing language features (as opposed to editor features), LabVIEW 20xx uses "LabVIEW"... LabVIEW NXG has moved to using "G" and uses "LabVIEW" to discuss the IDE. We find that this provides clarity in many documents, and it provides less of a mouthful when speaking (The NXG root class is "G Object" instead of "LabVIEW Object", for example).
Does the wiki prefer "LabVIEW" or "G" when discussing language features?

This one has ramifications for the ease of understanding of an article (especially for newcomers). I'm not sure what's best here.

Perhaps we can let NI spearhead the effort to "normalize" the use of "G". We can stick to "LabVIEW" for now since it's more common, but switch over to "G" later when NI's efforts bear fruit.

 

On 7/13/2019 at 12:06 AM, Aristos Queue said:

4. When behaviors diverge, what is the preferred way to document distinctions between LabVIEW 20xx and LabVIEW NXG? Should they be separate pages (so the former can be easily deprecated in the future) or do we prefer same-page-different-sections for easier side-by-side comparison?

I'm with Rolf; same-page is much more useful in the forseeable future.

Edited July 16, 2019 by JKSH

[Aristos Queue]

You people are so laid back and forgiving. I’m an editor on multiple wikis across cyberspace, and none of the others are anything less than draconian. Capitalization whatever?! Wow. I’m going to need to wear my oversized Hawaiian shirt and cargo shorts when I’m editing, just to get in the right state of mind! 🙂

[Antoine Chalons]

46 minutes ago, Aristos Queue said:

 I’m going to need to wear my oversized Hawaiian shirt and cargo shorts

Please post a picture 😂

[hooovahh]

7 hours ago, Aristos Queue said:

You people are so laid back and forgiving. I’m an editor on multiple wikis across cyberspace, and none of the others are anything less than draconian. Capitalization whatever?! 🙂

Maybe it has something to do with the fact that we have a more graphical mindset and don't care as much as long as we can convey a thought.  Maybe because we are primarily engineers?  Or this is a wiki with a relatively small support base?  In any case thank you for your wiki contributions.

[LogMAN]

9 hours ago, Aristos Queue said:

You people are so laid back and forgiving. I’m an editor on multiple wikis across cyberspace, and none of the others are anything less than draconian.

LabVIEW doesn't backfire for misspelled words, which means we don't freak out every time we see one.

Here are a few suggestions for draconian rules on the LabVIEW wiki 😇

1.1 Uploading sample code to the wiki

• Put input terminals to the right, output terminals to the left (on the block diagram and VI terminals)
• Use backwards wiring
• Show terminals as icons
• Don't use shift registers (use local variables instead)
• No error handling (disable debugging)
• Take a screenshot with your mobile phone (compress as much as possible before uploading)

Seriously, though. The wiki should have some guidelines for the structure and content of each article. Otherwise it will decay to some kind of link collection (formally known as favorites) with no added value (example). Those guidelines should be more general, as in:

• A page must be informative
• It should focus on one topic (create new pages for other topics)
• Citations must be marked clearly using the format "<blockquote>Someone said this!</blockquote>"
• ...

My point is: This page should be updated (last edited on 7 October 2007, at 11:18): https://labviewwiki.org/wiki/LabVIEW_Wiki:Manual_of_Style

[ShaunR]

12 hours ago, Aristos Queue said:

You people are so laid back and forgiving. I’m an editor on multiple wikis across cyberspace, and none of the others are anything less than draconian. Capitalization whatever?! Wow. I’m going to need to wear my oversized Hawaiian shirt and cargo shorts when I’m editing, just to get in the right state of mind! 🙂

When the compiler doesn't care, why should I?  The view I take is that "Style Guides" are just that. GUIDES, not LAWS.

If "boolean" was chosen, what do you do about capitalisation at the beginning of a sentence? There are arguments for grammatical considerations but I'm "meh" when it comes to programming type names, classes at. al. These things are just a distraction - form over function.

Read it and weep:

 

Edited July 16, 2019 by ShaunR

[hooovahh]

1 hour ago, LogMAN said:

My point is: This page should be updated (last edited on 7 October 2007, at 11:18): https://labviewwiki.org/wiki/LabVIEW_Wiki:Manual_of_Style

Wonderful suggestion.  Most LAVA members that are older than some date have a wiki account and are welcome to update it.