Naming Convention for Posix Flags

Naming convention for posix flags

The answer seems to be buried in the GNU docs here.

GNU adds long options to these conventions. Long options consist of
‘--’ followed by a name made of alphanumeric characters and dashes.
Option names are typically one to three words long, with hyphens to
separate words. Users can abbreviate the option names as long as the
abbreviations are unique.

What you've got follows the convention; camel case does not.

Is there a naming convention for new bash commands?

I think most languages recommend remove_unused_script over removeUnusedScript these days for readability. remove-unused-scripts is a legal file name for a script. bash allows function names to contain hyphens:

some-func () {
    echo hi
}

but that isn't portable; POSIX function names are restricted to letters, numbers, and _.

Should command line options in POSIX-style operating systems be underscore style?

Underscore is not a good idea, sometimes it gets "eaten" by a terminal border and thus look like a space.

The easiest to read, and most standard way is to use a dash:

--cure-world-hunger

Are there standards for Linux command line switches and arguments?

Generally, yes.

• IEEE
• GNU getopt

When implementing command line flags, should I prefix with a fowardslash (/) or hyphen (-)?

You can (theoretically) use whatever you want, as the parameters are just strings passed to your command-line program.

Windows convention seems to prefer the use of the forward slash ipconfig /all, though there are programs that take a hyphen gacutil -i or even a sort-of environment variable syntax setup SKUUPGRADE=1.

*Nix convention seems to prefer the hyphen -v for single-letter parameters, and double hyphen --verbose for multi-letter parameters.

I tend to prefer hyphens, as they are more OS-agnostic (forward slashes are path delimiters in some OSes) and used in more modern Windows apps (nuget, for example).

Edit:

This would be a good place to recommend a library that does .NET command-line argument parsing: http://commandline.codeplex.com/

Name and Unnamed Semaphore

Think in terms of who can access the semaphore.

Unnamed semaphores (lacking any name or handle to locate them) must exist in some pre-existing, agreed upon memory location. Usually that is (1) shared memory (inherited by children after fork) in the case of child processes; or (2) shared memory, global variable or the heap in the case where they are shared between threads of a single process. The essential thing here is that the code in parent, child, or threads already knows the address of the semaphore.

Named semaphores are necessary for unrelated processes. For example a producer and consumer might be written by two different developers and run as completely unrelated processes. But they have to share some resource that needs to be protected by a semaphore. The named semaphore gives them a path to the semaphore.

In reality you can use a named semaphore in all scenarios but they come with a little extra baggage because you have to deal with the paths and permissions and such that are unnecessary if the programs are related and already know how to access an unnamed semaphore. It's a little silly, for instance, to use a named semaphore to share a resource between threads. The threads already have access to the same memory where an unnamed semaphore could reside.

How to validate naming conventions in an XML Schema

I've automated WIPO ST.96 XML Design Rules and Conventions conformance via Schematron. Many rules are simple to represent, but some naming conventions such as CamelCase would require some serious dictionary-driven code. Consider:

• GD-10: Type names MUST use the UCC convention and have the suffix Type. For example, ApplicantType.

We decided to forego the lexical sophistication needed for full UCC verification but at least check that the name does start with a capital letter, is not all uppercase, and ends with the required suffix:

  <pattern>
    <title>GD-10</title>
    <rule context="xsd:complexType[@name] | xsd:simpleType[@name]">
      <assert test="fnx:is-exception('GD-10')
                    or matches(@name,'^[A-Z]')" flag="AUTO" role="ERROR">
        The <value-of select="local-name()"/> name <value-of
        select="@name"/> does not start with an upper-case letter.
      </assert>
      <assert test="fnx:is-exception('GD-10') or
                    not(matches(@name,'^[A-Z]+$'))"
              flag="AUTO" role="ERROR">
        The <value-of select="local-name()"/> name <value-of
        select="@name"/> contains all upper-case letters instead of
        using camel case.
      </assert>
      <assert test="fnx:is-exception('GD-10') or
                    ends-with(@name,'Type')" flag="AUTO" role="ERROR">
        The <value-of select="local-name()"/> name <value-of
        select="@name"/> does not end with Type.
      </assert>
    </rule>
  </pattern>

(fnx:is-exception() is just a little utility function that allows an organization to opt out of any given convention via an entry in a configuration file.)

---

Related Topics