At 2018-05-06T00:19:44+0100, Ralph Corderoy wrote: > That was my point. Though the widespread conventional method has that > in its favour, it doesn't mean the more logical consistent one is wrong > or misleading. It mainly means the alternative hasn't been considered > for its merits, just dismissed because it `looks odd'. A knee-jerker.
There are a lot of jerking knees in software development. > > Enjoy changing it all over place. > > Sigh. I made very clear: "I accept it isn't groff's style". > I'm not trying to change groff, or anybody's style. > I am trying to explain how C works because at least two experienced C > programmers on this list thought they weren't equivalent and that > Branden and I were therefore mistaken and creating errors in using it. Yeah, I'm not interested right now in making a global change of this sort to the groff codebase. The idea of adding semantic macros to an-ext and making all the in-tree man pages use them is much more exciting. ;-) > That's the one that *persuaded* me of its merits. Before that, I'd just > seen it and thought `Why write the equivalent thing in that odd way?'. > I've seen its use growing. I suspect more projects will switch. > Branden was already using that style and that wasn't my influence. > Perhaps you're in a bit of a silo? :-) I had first _heard_ of it some years ago, but the most significant bit of prominent evangelism for it I'm aware of is from Ben Klemens's _21st Century C_: https://www.goodreads.com/book/show/14514281-21st-century-c It has a lot of good ideas, and while taken together they clearly work syergetically for Ben, they are mostly separable, so you can cherry-pick what you like. His enthusiasm for macros goes beyond what most people care for--though I sure share a lot of his motives for using them as aggressively as he does. (A popular counterargument in actual practice, more often seen than heard, is, "my code looks much cleaner if I don't check the return values of library calls!" <wince, gnash>) My personal declaration style is: [storage_class] {type_name [type_qualifier ...]} ... A storage class is only meaningful for a fundamental type so it makes sense for it to go out front. > I think you're wrong. I'm adopting it. I suspect over the medium term > its use will grow. Other aspects of C style have also changed over the > decades. > Again, I wasn't saying it does. Many people claim to `know Python' but > get caught by > l = [42, 314]; m = l > not behaving as they expect. Are you saying they expect l to be defined as a 42x314 array, or that they expect m to be a copy of l instead of a reference to l? -- Regards, Branden
signature.asc
Description: PGP signature
