stands for.
    int pc_reader;             // Lots of things can be abbreviated "pc".
    int cstmr_id;              // Deletes internal letters.


File Names ~

Filenames should be all lowercase and can include underscores (`_`).

Use underscores to separate words. Examples of acceptable file names: >

    my_useful_file.c
    getline_fix.c  // ✅: getline refers to the glibc function.

C files should end in `.c` and header files should end in `.h`.

Do not use filenames that already exist in `/usr/include`, such as `db.h`.

In general, make your filenames very specific. For example, use
`http_server_logs.h` rather than `logs.h`.


Type Names ~

Typedef-ed structs and enums start with a capital letter and have a capital
letter for each new word, with no underscores: `MyExcitingStruct`.

Non-Typedef-ed structs and enums are all lowercase with underscores between
words: `struct my_exciting_struct` . >c

    struct my_struct {
      ...
    };
    typedef struct my_struct MyAwesomeStruct;


Variable Names ~

Variable names are all lowercase, with underscores between words. For
instance: `my_exciting_local_variable`.

    Common Variable names ~

    For example: >c

        string table_name;  // ✅: uses underscore.
        string tablename;   // ✅: all lowercase.

        string tableName;   // ❌: mixed case.
<

    Struct Variables ~

    Data members in structs should be named like regular variables. >c

        struct url_table_properties {
          string name;
          int num_entries;
        }
<

    Global Variables ~

    Don't use global variables unless absolutely necessary. Prefix global
    variables with `g_`.


Constant Names ~

Use a `k` followed by mixed case: `kDaysInAWeek`.

All compile-time constants, whether they are declared locally or globally,
follow a slightly different naming convention from other variables. Use a `k`
followed by words with uppercase first letters: >c

    const int kDaysInAWeek = 7;

Function Names ~

Function names are all lowercase, with underscores between words. For
instance: `my_exceptional_function()`. All functions in the same header file
should have a common prefix.

In `os_unix.h`: >c

    void unix_open(const char *path);
    void unix_user_id(void);

If your function crashes upon an error, you should append `or_die` to the
function name. This only applies to functions which could be used by
production code and to errors that are reasonably likely to occur during
normal operation.


Enumerator Names ~

Enumerators should be named like constants: `kEnumName`. >c

    enum url_table_errors {
      kOK = 0,
      kErrorOutOfMemory,
      kErrorMalformedInput,
    };


Macro Names ~

They're like this: `MY_MACRO_THAT_SCARES_CPP_DEVELOPERS`. >c

    #define ROUND(x) ...
    #define PI_ROUNDED 5.0


==============================================================================
Comments                                                *dev-style-comments*

Comments are vital to keeping our code readable. The following rules describe
what you should comment and where. But remember: while comments are very
important, the best code is self-documenting.

When writing your comments, write for your audience: the next contributor who
will need to understand your code. Be generous — the next one may be you!

Nvim uses Doxygen comments.


Comment Style ~

Use the `//`-style syntax only. >c

    // This is a comment spanning
    // multiple lines
    f();


File Comments ~

Start each file with a description of its contents.

    Legal Notice ~

    We have no such thing. These things are in LICENSE and only there.

    File Contents ~

    Every file should have a comment at the top describing its contents.

    Generally a `.h` file will describe the variables and functions that are
    declared in the file with an overview of what they are for and how they
    are used. A `.c` file should contain more information about implementation
    details or discussions of tricky algorithms. If you