Re: [dev] [sbase] style

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Wed, 19 Nov 2014 14:21:30 +0100

Hi there,

first of all good effort. I'd like you to bring this style guide
forward to become the official suckless styleguide, not just sbase.

On 18 November 2014 11:52, Dimitris Papastamos <sin_AT_2f30.org> wrote:
>> no block for single statement (optional block? always block? discuss)
> LICENSE header
> headers
> macros
> types
> function declarations
> global vars
> usage /* this could also go below for consistency but I like it here */
> main
> function definitions

I dislike main definition at the top, I pretty much prefer main at the
bottom -- at least this style was used in most suckless projects so
far.

>> functions
>> =========
>> declarations at top of file
>> declarations, definitions, in alphabetical order (except main, at end of file)
>> static if not used outside current file (what's the right term?
>> compilation unit?)
>> definitions have modifiers and return type on own line
>> { on own line (function definitions are special case of block as they
>> cannot be nested)
>
> Also parameters should not be named in function declarations.

Hmm, also I dislike not naming the args in function declarations.
Often I use a split window with the declarations in a top window, and
the actual code in a second. Having:

static void resize(Client *c, int x, int y, int w, int h, Bool interact);

in the declaration line gives me a hint what the args are all about,
otherwise I would have to seek for the definition each time, this
sucks imho.

>> types
>> =====
>> user defined types start with a capital letter
>> when possible typedef struct {} Name;
>
> Debatable. I'd like to hear more opinions on this.

In most suckless code types always start with capital letters (pretty
much acme/p9 influenced), as opposed to lower case everything else.
This is much more readable than foo_t, which can be overlooked easily
to be a type.

So definitely agree with the proposal.

>> line length
>> ===========
>> we aren't limited to 80 columns in our terminals anymore, no need to
>> pretend we are
>> if using more columns makes code more readable, do so
>> it also means we can fit more code on a single screen, less scrolling
>> (some hard limit so we don't have 300 character lines?)
>
> No. 80 columns per line is sane. This is not a hard rule and you can
> easily have printf() or similar spanning that limit.
> The idea is that heavily indented code is probably broken in the first
> place and that all good, sane and elegant code should really fit in 80
> columns per line. This implies sane naming conventions and proper use
> of continue and break.

Agreed, though I wouldn't mind increasing the 80 to 100.

>> tests (boolean)
>> ===============
>> do not test against 0 explicitly (e.g. if (!strcmp(p, q)) instead of
>> if (strcmp(p, q) == 0)) (discuss)
>
> It should be the latter. See my other post here for details.

In general I agree, for the sake of strcmp() which is used quite often
I prefer !str(n)cmp() to check two (sub)strings for equality. The
typical use case doesn't wants to know if s1 < s2 or s1 > s2.

>> more alignment
>> --------------
>> somefunc(foo .bar, baz );
>> somefunc(bonzai.bar, qux );
>> somefunc(blah .bar, blargh);
>
> I do not like this.

This sucks. No pretty printing of arg lists. Just a whitepace after each comma.

BR,
Anselm
Received on Wed Nov 19 2014 - 14:21:30 CET