Convert to GNU Octave code style

[apjanke]

Let's convert Tablicious fully over to Octave's conventional code style.

• [X] Specific endif/endfor/endfunction/endxxx instead of plain end.
• [X] Use ! instead of ~ for negation.
• [X] Use () around if, while, and switch predicates.
• [X] # for comments (# for inline comments, ## for block comments).
• [X] Remove trailing whitespace from all lines.
• [X] 2-space indents.
• [ ] Block comments (including one-liners) use ## instead of #.
• [ ] String literals use "..." unless there's a specific reason for '...'.
• Anything else in the Octave style guilde, unless I really hate it.
  • I'm passing on end_try_catch, just bc that looks gross to me.

Open questions:

• Should the LHS of multi-argout [a,b,c] = ... assignments have spaces after commas like [a, b, c] = ...?

Don't care about Matlab compatibility here, because there's not much use case for running Tablicious code under Matlab at all.

It's fine to do code-style-only commits or PRs for this. And IMHO preferable: I'd rather get this all over with at once and have the whole Tablicious code base in consistent Octave style.

But wait until pr0m1th3as is done with this PR work before modifying table.m.

TODO

• [X] Re-read the Octave style guilde for more items.
• [in-progress] Convert all code to Octave style.
• [X] Add .editorconfig with supporting settings, including trailing whitespace stripping.

References

• https://github.com/apjanke/octave-tablicious/issues/111#issuecomment-1917698503
• https://wiki.octave.org/Octave_style_guide

[apjanke]

Open question: for multiple LHS variables in an assignment like [a,b,c] = ..., should there be spaces after those commas? I'm guessing yes, because in the array-concatenation [...] syntax it uses spaces, there's spaces after commas in function calls, and everywhere else except in x(a,b,c) or x{a,b,c} indexing calls that I can see, it uses spaces. But this isn't addressed directly in the GNU Octave style guide as far as I can tell.

[apjanke]

I did a rough draft bulk conversion for this on branch "WIP/swift-style". It addresses most of the items noted in the description, except for converting the generic ends for try/catch blocks; "end_try_catch" is disgusting and I can't bring myself to type that. I'll consider a PR if someone else wants to do it, though.

This is a multi-commit WIP work stream, and will be rebased and squashed before merging.

[apjanke]

I merged those style changes from the "rough draft" plus a couple others to main. That covers most of this, except for the (...) around if/while predicates, and other stuff that may be in the Octave style guide but I don't remember. I'll do a reread through the style guide before closing this.

[apjanke]

Octave style guide re-read notes

"It is customary to prefix the error message with the name of the function that generated it." But it doesn't mention using an actual error or warning identifier (the separate arg).

"For functions that are not present in Matlab, favor the use of underscores. For example, base64_decode, common_size, or compare_versions." I'm using camelCase instead.

Under Naming, outside "Function names" it says "Do not use mixed case (a.k.a. CamelCase) names." It doesn't mention class naming at all.

"Always use double quotes for strings and characters rather than the Matlab single quote convention." Except for strings containing double quotes or backslashes.

"Enclose the condition of an if, while, until, or switch statement in parentheses, as in C", but not for for statements, including the RHS of the for x = ....

"The negation operator is written with a space between the operator and its target, e.g., ! A." Oops! I'm not doing this.

"Comments that start with a double sharp-sign, ##, are stand-alone comments that occupy an entire line." They use this even for one-line comments; those are still considered "block comments". I'm not doing this.

Things they don't cover

• Indentation level for statement continuations, like a foo(x, y, ... \n function call that's continued on the next line.
• Anything about classes.
• Anything about packages/namespaces.
• Whitespace lines immediately inside properties, methods, and classdef blocks?
• Spaces after commas in [x,y,z] = ... multi-argout LHS?

[apjanke]

Did some more style changes on the WIP/preallocation-ctor-form branch. Think I got all the big ones now, except:

• Block comments (including one-liners) use ## instead of #.
• String literals use "..." unless there's a specific reason for '...'.

I'm a little tired; don't think I'll get to those soon.

[apjanke]

I'm going to postpone doing the ## block comments and "..." double-quoted string literals until later. Closing as Fixed.