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 <s...@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
