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 <a...@unstable.cc>
> 
> 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                             g...@greenie.muc.de

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to