On Wed, 21 Jun 2017 10:55:20 +0200
Anselm R Garbe <garbeam_AT_gmail.com> wrote:
Hey Anselm,
> On 20 June 2017 at 21:45, <git_AT_suckless.org> wrote:
> > -enum stati {
> > +enum req_field {
> > +enum req_method {
> > +struct request {
> > +enum status {
>
> I really dislike using lowercase enum and struct names. Types should
> always be easily distinguishable from global / local variable names
> and shouldn't be required to be qualified with enum or struct in the
> code (I highly prefer typedef for this eye candy).
well, there are split opinions about this.
My rationale is that typedefs are fine for anonymous structs. This is
also what we can see for instance with FILE from stdio.h, which is a
struct but given it's only passed to libc-functions for modifications
the typename is uppercase and the fact that it's a struct is not
revealed, as it is not important.
Completely different is "struct stat", which is not a typedef'ed
structure as the standard expects people to use the fields it provides,
and the fields are specified by the standard.
If the case comes up, I will use uppercase letters for typedef'ed
structs, but to be honest, this really only comes up if you write a
library or something.
For a program like quark, which only uses transparent structs for
internal processing, opaque structs just make no sense, and I think
typedeffing for the sake of it kind of hurts the readability because it
takes two steps to jump to the definition instead of one. The extreme
case is glibc and Qt, where you have to hoop through multiple layers of
typedefs and macros to find the definition you were looking for.
> I also dislike extending _t or _e or similar postfixes to type names.
> Hence I adopted the Plan 9 style a while back to use capitalized type
> names.
I completely agree! It is also a problem given Posix reserves itself
the _t-suffix. You may not use it in a standards compliant program.
> Afair also our coding style suggests that.
I would alter the rule to "Typedef opaque structs", but it depends on
personal taste and don't mind too much. I know though that many here
would agree with me based on previous discussions.
After all, I'm glad you took your time and looked at the code. Thanks
for the feedback!
With best regards
Laslo Hunhold
--
Laslo Hunhold <dev_AT_frign.de>
Received on Thu Jun 22 2017 - 17:29:14 CEST