Hi, On Fri, Aug 19, 2022 at 11:50:04AM +0200, Arne Schwabe wrote: > Am 18.08.22 um 22:43 schrieb Antonio Quartulli: > > yes! This is what we need! > > > > Acked-by: Antonio Quartulli <[email protected]> > > I am out of the loop here. Could you two explain why we need this? I.e. > what is wrong with the current style is and what the plan is to change? > > If often struggle to properly format function with the soft limit of 80 > without being allowed to put the return type on a separate line. So I am > not sure what the improvement of this change is.
This is the conclusion that I arrived to as well, when reviewing the
changes in 1/2. Forcing the prototype on the return type while at
the same time permitting enums, structs, etc., will cause cases like
enum some_special_type special_function_with_descriptive_name(int arg1,
char * arg2);
which is definitely less readable than
enum some_special_type
special_function_with_descriptive_name(int arg1, char * arg2);
or maybe
enum some_special_type
special_function_with_descriptive_name(int arg1, char * arg2);
Now, for other cases,
int
somefunc(void);
I find the other style
int somefunc(void);
much easier to grok ("have a single look and see what this is about").
... so, my suggestion is that we permit both styles for function prototypes,
based on overall type + function name + parameter length.
It would be cool if uncrustify had a magic flag for that, like "if
return type + function name is < 40 characters, put on a single line,
and if over, split" :-)
Am I making sense?
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-devel
