On Wed, Nov 19, 2014 at 02:21:30PM +0100, Anselm R Garbe wrote:
> 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.
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?
