Re: [dev] [sbase] style

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Wed, 19 Nov 2014 15:23:08 +0100

On 19 November 2014 15:02, Dimitris Papastamos <sin_AT_2f30.org> wrote:
> On Wed, Nov 19, 2014 at 02:21:30PM +0100, Anselm R Garbe wrote:
>> 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.
>
> ACK.
>
>> >> 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.
>
> ACK.
>
>> >> 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.
>
> ACK.
>
>> >> 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.
>
> Let's get some more opinions on this.
>
>> >> 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.
>
> I am sure we can figure this out :)
>
> Should this be maintained on the wiki or in a separate style repository?

I suggest http://suckless.org/style[.md], to be the central place for this.

_AT_Evan, feel free to proceed ;)

BR,
Anselm
Received on Wed Nov 19 2014 - 15:23:08 CET

This archive was generated by hypermail 2.3.0 : Wed Nov 19 2014 - 15:24:13 CET