New Coding Standard (spaces and NO tabs)

[Albrecht Schlosser]

All devs,

as discussed recently, we decided to replace tabs in our source code
with spaces and to remove trailing whitespace.

The CMP has been updated but is still being worked on.
https://www.fltk.org/cmp.php


I committed the source code changes today in commit f09e17c3c564.

*Please configure your editors* accordingly to keep this new standard
alive, i.e.:

- use 2 column indents
- use space for indenting
- do not use tabs for indenting
- do not use tabs for "trailing comments"
- etc. etc.
- avoid adding trailing whitespace
- remove trailing whitespace on exit if possible [1]


Note: A common issue is when adding an "empty line" in indented code
like the following. Some editors "indent" the "empty" line with spaces
up to the current indent level (column) - which would effectively add
trailing whitespace:

function a(int b) {
static int i;
i++;
<<< empty line: this is where whitespace gets added!
return b+1;
}

[1] Take care to do this only for source and other text files that don't
have significant trailing whitespace. Some shell scripts may have such
significant trailing whitespace!

Thanks in advance.

[Greg Ercolano]

On 2020-07-06 14:00, Albrecht Schlosser wrote:
> *Please configure your editors* accordingly to keep this new standard alive, i.e.:
> 
> a. use 2 column indents
> b. use space for indenting
> c. do not use tabs for indenting
> d. do not use tabs for "trailing comments", etc. etc.
> e. avoid adding trailing whitespace
> f. remove trailing whitespace on exit if possible [1]

    For VI/VIM, the following can be used to solve a-d:

	set ai		  " Enable auto-indent
	set sw=2	  " 2 space indent (sw=shift width)
	set expandtab	  " Uses spaces instead of tabs when you hit tab
	set ts=8          " Always leave tabstop at 8
	set softtabstop=8 " Columns the tab key stops at (ok to change to e.g. 2 or 4)

    For e-f, I'm not sure there's an easy answer; see below.

    Apparently 'autocmd BufWritePre {filepat} {cmd}' can be used to apply
    a search/replace just before all :w write operations for files with
    filename extensions that match {filepat}, e.g.

	autocmd BufWritePre *.cxx,*.c,*.h,*.mm :s/\s\+$//e
                ----------- ------------------ -----------
                All writes  filepat            regex cmd

    ..which applies the search/replace to all .cxx/.c/.h/.mm files
    just before writing the file to disk.

    But because this does a search/replace, the cursor might be moved to the
    last search/replace match, loosing your cursor position, so to solve that
    a slightly more complicated approach seems necessary (in your ~/.vimrc):

fun! <SID>StripTrailingWhitespaces()
    let l = line(".")
    let c = col(".")
    keepp %s/\s\+$//e
    call cursor(l, c)
endfun
autocmd FileType c,cxx,h,mm autocmd BufWritePre <buffer> :call <SID>StripTrailingWhitespaces()

    I haven't tried that yet, but perhaps it's a start.
    I suggest all vi users try the different approaches out there and report back what works.
    Here's a few links to start:

            How can you automatically remove trailing whitespace in vim
            ===========================================================
            https://stackoverflow.com/questions/356126/how-can-you-automatically-remove-trailing-whitespace-in-vim

	    How to automatically strip trailing spaces on save in Vi / Vim?
            ===============================================================
	    https://unix.stackexchange.com/questions/75430/how-to-automatically-strip-trailing-spaces-on-save-in-vi-and-vim

	    Remove Unwanted Spaces
            ======================
	    https://vim.fandom.com/wiki/Remove_unwanted_spaces

	    "New" Techniques (2010) for "Tidying Whitespace"
            ================================================
	    http://vimcasts.org/episodes/tidying-whitespace/

[Albrecht Schlosser]

On 7/7/20 12:52 AM Greg Ercolano wrote:
> On 2020-07-06 14:00, Albrecht Schlosser wrote:
>> *Please configure your editors* accordingly to keep this new standard alive, i.e.:
>>
>> a. use 2 column indents
>> b. use space for indenting
>> c. do not use tabs for indenting
>> d. do not use tabs for "trailing comments", etc. etc.
>> e. avoid adding trailing whitespace
>> f. remove trailing whitespace on exit if possible [1]
>
> For VI/VIM, the following can be used to solve a-d:
>
> set ai " Enable auto-indent
> set sw=2 " 2 space indent (sw=shift width)
> set expandtab " Uses spaces instead of tabs when you hit tab
> set ts=8 " Always leave tabstop at 8
> set softtabstop=8 " Columns the tab key stops at (ok to change to e.g. 2 or 4)
>
> For e-f, I'm not sure there's an easy answer; see below.

> [...]

In case someone can't config his editor as required, I can contribute
the script I used to convert our files.

Use with care though, it may have unwanted results. I believe it's good
to check and convert the files from time to time, but I don't recommend
it for every day use.

If you use it, I suggest to `git add' (or better: commit) all changes so
you have a clean working directory, then run the script and check the
diffs. If correct, run `git commit --amend' to add the corrected files,
else reset your working directory (`git reset [--hard]'). Take care!


Notes:

1) The name 'expand_tabs.sh' is because I first used it to convert
(expand) tabs to spaces. Later I added the function to strip trailing
whitespace.

2) Requires `expand' and uses the default tab setting of 8 columns as
required by the CMP. If anybody edits a file with the *wrong* tab
setting (other than 8), the result *will* be wrong as well. In this case
`expand -tN' can be used instead.

3) It's a quick hack with lots of output - it was intended to be used
only once. But it can be reused whenever required. It does NOTHING if
all files are correct.

4) The order of files used is per file type - because that's what I
wanted to do for a better overview. This involves multiple `git
ls-files' steps which is inefficient, but every file is converted only
once. See also (3).

4a) Only our own source files are converted, the bundled libs are not
touched.

5) It's quick enough for me on my system (2.7 sec) for sporadic checks.
YMMV.

6) The `sed' command can probably be optimized (see the links provided
by Greg).

Use at your own risk.

[Albrecht Schlosser]

On 7/7/20 1:55 AM Albrecht Schlosser wrote:
>
> In case someone can't config his editor as required, I can contribute
> the script I used to convert our files.
>
> Use with care though, it may have unwanted results. I believe it's good
> to check and convert the files from time to time, but I don't recommend
> it for every day use.

[...]

> 3) It's a quick hack with lots of output - it was intended to be used
> only once. But it can be reused whenever required. It does NOTHING if
> all files are correct.

Well, this is not entirely true:

It doesn't produce any different files (`git status` and `git diff` are
"empty"), but it *touches* every file in the list, i.e. all file times
are changed. This could be changed if necessary, i.e. if we wanted to
use a script like this one in a Git commit hook or devs wanted to use it
regularly, maybe before or after every commit ...

[Gonzalo Garramuño]

El 06/07/20 a las 21:21, Albrecht Schlosser escribió:

> On 7/7/20 1:55 AM Albrecht Schlosser wrote:
>>
>> In case someone can't config his editor as required, I can contribute
>> the script I used to convert our files.
>>

For emacs, I believe this can be used:

(defun fltk-c-stuff ()
"FLTK C stuff. Customizes indentation style."
(c-set-offset 'defun-open 0 nil)
(c-set-offset 'defun-block-intro 2 nil)
(c-set-offset 'statement 0 nil)
(c-set-offset 'statement-block-intro 2 nil)
(c-set-offset 'substatement 2 nil)
(c-set-offset 'statement-case-intro 2 nil)
(c-set-offset 'statement-case-open 2 nil)
(c-set-offset 'inclass 2 nil)
(c-set-offset 'case-label 2 nil)
(c-set-offset 'inline-open 0 nil)
(c-set-offset 'access-label -2 nil)
(c-set-offset 'label 10 nil)
(setq-default c-basic-offset 2
tab-width 2
indent-tabs-mode nil)
)

(add-hook 'c-mode-common-hook 'fltk-c-stuff)

[Greg Ercolano]

On 2020-07-06 15:52, Greg Ercolano wrote:

> *Please configure your editors* accordingly to keep this new standard alive, i.e.:
> 
> a. use 2 column indents
> b. use space for indenting
> c. do not use tabs for indenting
> d. do not use tabs for "trailing comments", etc. etc.
> e. avoid adding trailing whitespace
> f. remove trailing whitespace on exit if possible [1]

    I'd sure like to see the suggested settings for Visual Studio
    if anyone knows them.

[Greg Ercolano]

On 2020-07-06 15:52, Greg Ercolano wrote:

> On 2020-07-06 14:00, Albrecht Schlosser wrote:
>> *Please configure your editors* accordingly to keep this new standard alive, i.e.:
>>
>> a. use 2 column indents
>> b. use space for indenting
>> c. do not use tabs for indenting
>> d. do not use tabs for "trailing comments", etc. etc.
>> e. avoid adding trailing whitespace
>> f. remove trailing whitespace on exit if possible [1]
>
> For VI/VIM, the following can be used to solve a-d:
>
> set ai " Enable auto-indent
> set sw=2 " 2 space indent (sw=shift width)
> set expandtab " Uses spaces instead of tabs when you hit tab
> set ts=8 " Always leave tabstop at 8
> set softtabstop=8 " Columns the tab key stops at (ok to change to e.g. 2 or 4)

I'm trying to tune this into my workflow so that I don't leave tabs
and stuff in the FLTK source files.

Gets a bit tricky when you move from machine to machine.

What I have found is that I can use the following in my ~/.exrc to limit
the FLTK settings only to FLTK files.

I found that if I used:

" FLTK formatting
au BufNewFile,BufRead */fltk*{.cxx,.H,.h,.c} setlocal expandtab sw=2 ts=8 sts=8

..this will enable the FLTK settings only if the file I'm editing is:

> In a directory that contains the string "/fltk" (e.g. /var/tmp/fltk-1.4.x/)
> Only files ending in .cxx .H .h .c, so as to still allow tabs in Makefile's

So this way I can still open .c and .cxx files in non-FLTK directories, and not
have the FLTK settings interfere.

[markj...@gmail.com]

What would be real exiciting is to run it through a source formatter like astyle

[Ian MacArthur]

On 10 Sep 2020, at 04:06, markjolesen wrote:
>
> What would be real exiciting is to run it through a source formatter like astyle
>

OK... um, did note that Albrecht said he’d been running the code through clang-format?
You know that’s a source formatter, like astyle?

[Albrecht Schlosser]

Well, yes, I tried it and I prepared a (preliminary) .clang-format file
which I installed in our FLTK root directory.

I'm sure this is not the final setup, there are some points we need to
discuss and there are some cases where we would either re-think the code
formatting (for instance table-like structures of function arguments
etc.) or we'd need to add clang-format directives to disable formatting
in certain places.

Everybody is invited to test: install clang-format if you don't have it,
then run either

$ clang-format `input-file' > `output-file'

or

$ clang-format -i `input-file'

I'm using a graphical diff tool (meld) to compare the result with the
original, YMMV.

I'd appreciate all feedback and suggestions on what of the setup
(.clang-format) to change. TIA.