code portability

[Richard]

Chris Dollin posted:



My code is maintainable. Most of it is self-explanatory, and in other places
it's commented.




By whom? You?

I think this conversation is getting a bit fruitless.

At the end of the day, the word order in a definition doesn't matter --
people should realise that and acquiesce to it.

The is order word important fool you.

Convinced am I troll you are. Noone could be so ridiculously naive to
believe that the ordering doesnt affect people ability to read and
maintain your code.

 

[Phlip]

Convinced am I troll you are. Noone could be so ridiculously naive to
believe that the ordering doesnt affect people ability to read and
maintain your code.

I am much smarter than you, so you obviously can't read my code. This is
your problem, not my codes'!

;-)

 

[Frederick Gotham]

Richard wrote:

Convinced am I troll you are.

You left out the indefinite article: "a".

Noone could be so ridiculously naive to believe that the ordering doesnt
affect people ability to read and maintain your code.

Naive... or realistic? If people are taking any meaning from the word order,
then they're wrong to do so.

If I write:

int const *p;

, then does it mean that I'm lonely?

And if I write:

cont int *p;

, the does it mean that I'm excited?

 

[Chris Dollin]

Chris Dollin posted:


My code is maintainable.

By /you/ to /your/ standards - just like /fast/, it's a
particular taste. So long as you're feeding yourself,
that's OK.

By whom? You?

By the people in the discussion who you are failing to convince.

I think this conversation is getting a bit fruitless.

At the end of the day, the word order in a definition doesn't matter --
people should realise that and acquiesce to it.

See? You're doing it /again/. You're saying that because the
word order doesn't matter /to the formal language processor/,
it doesn't matter. It matters to the /people/ involved.
(This is as true of English as it is of C declarations,
incidentally.) You should just realise that and acquiesce to it.

 

[Frederick Gotham]

Philip Potter posted:

I think that is exactly as clear as:

export template<class NumT, class StrT>
static inline
const typename Assum<NumT,StrT>::CharT *
Assum<NumT,StrT>::TextProcess(const Letters<NumT> &stls)

Yes but things get fuzzy when I return a pointer to an array:

export template<class NumT, class StrT>
static inline
const typename Assum<NumT,StrT>::CharT (*
Assum<NumT,StrT>::TextProcess(const Letters<NumT> &stls))[5]

 

[Al Balmer]

"The grammar allows it" isn't enough. The grammar [including the lexis]
allows `int djh908gf( void *ewjh8455534 );` too, and `int *a, b;`,
and unrestrained use of `goto`, and redundant `auto`s and irrelevant
`register`s and pointless casts. The point about a widely-used ordering
for the formally order-irrelevant parts of a declaration means that
we don't have to /care/.

One point that no one has brought up is that reading code in quantity
is like reading English. One does not read one word at a time and
think about what the combination of words means. We recognize phrases
and even multi-line conventional idioms. When those conventional
phrases are scrambled, we have to go back to word at a time reading
and interpreting, at least momentarily. This not only slows the scan,
but interrupts the flow of thinking and absorbing the meaning of the
code.

In practice, over many years, conventions have appeared which make
this process possible. There are variations, but few, and they are
well known. Although I have a preferred brace style, I can switch
gears to one of the other conventional styles easily, so long as
there's consistency (the reason that maintenance programmers try to
maintain the style of the code they're changing.) OTOH, if you decided
that all opening braces should be in column 80 and all closing braces
should be indented from the previous statement, that's not one of the
conventions we're used to, and most of us would slow *way* down while
reading it, even though the compiler wouldn't mind a bit.

(Incidentally, although Frederick may be an expert cook, I suspect
he'd have some surprises in store if he took on the job of a real
chef.)

 

[Al Balmer]

Dik T. Winter said:


In Polish, which is of course a Slavic language, it varies (just as it does
in English proper!).

For example: in "otwartym terenie" - "open terrain" - the adjective comes
first, and this is commonplace. But "dzien otwarty" - "open day" - places
the adjective after the noun.

But, to the point, the usage is conventional and normally doesn't
change, right? In English, we allow "poetic license" but normally
conventions are followed, even if not all conventions are consistent
with each other.

 

[Philip Potter]

Naive... or realistic? If people are taking any meaning from the word order,
then they're wrong to do so.

It. Takes. People. Longer. To. Understand. Unfamiliar. Things.

 

[Philip Potter]

Philip Potter posted:

I think that is exactly as clear as:

export template<class NumT, class StrT>
static inline
const typename Assum<NumT,StrT>::CharT *
Assum<NumT,StrT>::TextProcess(const Letters<NumT> &stls)

Yes but things get fuzzy when I return a pointer to an array:

export template<class NumT, class StrT>
static inline
const typename Assum<NumT,StrT>::CharT (*
Assum<NumT,StrT>::TextProcess(const Letters<NumT> &stls))[5]

And again, your style doesn't make it any clearer.

 

[Al Balmer]

Yes -- I consider the asterisk to be a part of the name;

But, of course, it isn't.

this is reflected
by:

int *p, q, *r;

Heh. You don't code for a living, but I had a long-term client who
insisted that the asterisk was part of the type and required

int* p;
int q;
int* r;

This, of course, would limit your choices of where to put other
modifiers.

I though it was silly, but it's not that unusual, and can be
considered one of the standard styles. I made my opinion known (about
this and even sillier things in their style guide), but it was
opinion, not religion, and they paid well.

 

[Frederick Gotham]

Philip Potter posted:

Philip Potter posted:

I think that is exactly as clear as:

export template<class NumT, class StrT>
static inline
const typename Assum<NumT,StrT>::CharT *
Assum<NumT,StrT>::TextProcess(const Letters<NumT> &stls)

Yes but things get fuzzy when I return a pointer to an array:

export template<class NumT, class StrT>
static inline
const typename Assum<NumT,StrT>::CharT (*
Assum<NumT,StrT>::TextProcess(const Letters<NumT> &stls))[5]

And again, your style doesn't make it any clearer.

I would write it as:

export template<class NumT,class StrT>
typename Assum<NumT,StrT>::CharT const
static inline
(*Assum<NumT,StrT>::TextProcess(Letters<NumT> const &stls))[5]


And I do find it clearer. Anyhow, I think this conversations has gone on
long enough.

 

[Richard Heathfield]

Al Balmer said:

But, to the point, the usage is conventional and normally doesn't
change, right?

Um, quite so. Polish is astonishingly regular for a natural language. And
whilst there may be exceptions to this rule that I don't know about, it
appears to have 100% regular spelling, too. For example, two of my Polish
friends rejoice in the name "Joanna", and each pronounces /both/ of the 'n'
letters - "Yo-a-nuh-na".

In English, we allow "poetic license" but normally
conventions are followed, even if not all conventions are consistent
with each other.

Yes. When a good writer breaks those conventions, he or she does so for a
good reason. For example, there's a book by Joseph Conrad that starts
something like this:

"And the wind blew. And the sea roared."

He doesn't mess around with merely starting a sentence with a conjunction -
he starts the entire /book/ with a conjunction! The effect, however, is
startling, and deliberately so.

I think there's a C newsgroup around here somewhere. Does anyone know where
it's got to?

 

[Keith Thompson]

Philip Potter posted:

These are concepts in your own mind, not in the C language.

They're also concepts in the minds of most C programmers, based on the
way most C code is actually written. The same is true of indentation.
The compiler doesn't care how or whether you indent your code, but
anyone reading it does.

A function is defined just like a variable, except that you have
parentheses after the name which contain a list of arguments.

Here's a few things which a variable can be:

unsigned
volatile
static

Just like my "smoot, yellow, painted, big wall", I don't care what order
they're put in:

If you don't care, why not just do it the way everyone else does it?

 

[Keith Thompson]

Chris Dollin posted:

My code is maintainable. Most of it is self-explanatory, and in other places
it's commented.


By whom? You?

By anybody in this discussion other than you. Or hadn't you noticed?

I think this conversation is getting a bit fruitless.

At the end of the day, the word order in a definition doesn't matter --
people should realise that and acquiesce to it.

Word order, in some cases, doesn't matter to the compiler. This has
been acknowledged *repeatedly* in this thread.

Arbitrary variations in word order, even if they don't matter to the
compiler, can make code more difficult to read for most people. Al
Balmer posted an excellent analysis of this phenomenon:

| One point that no one has brought up is that reading code in quantity
| is like reading English. One does not read one word at a time and
| think about what the combination of words means. We recognize phrases
| and even multi-line conventional idioms. When those conventional
| phrases are scrambled, we have to go back to word at a time reading
| and interpreting, at least momentarily. This not only slows the scan,
| but interrupts the flow of thinking and absorbing the meaning of the
| code.

It is your stubborn refusal to acknowledge this point that has made
this thread as long as it is.

If you want to use some unconventional style in your own code, code
that you never share with anyone else, nobody is going to complain.
If you insist on sharing your ideas with others, as you're doing here,
people are going to explain to you why it's a bad idea, as you've seen
here.

Nobody is going to acquiesce to your style. You should acquiesce to
that.

 

[ena8t8si]

Its called a developing thread.

The point is that threads not related to standard C
should develop somewhere else.

 

[ena8t8si]

<name>

const and volatile *are* type specifiers, afaicr.

Type qualifiers.

 

[ena8t8si]

I'm not trying to convice people to start writing:

int const static *Func(void);

But rather to explain to them that it's a perfectly acceptable variant.

It is perfectly acceptable to you. For
lots of other people, it isn't. Do you
get it now?

 

[Richard Bos]

By anybody in this discussion other than you. Or hadn't you noticed?

Dunno about you, but I'd not noticed that, no.

Richard

 

[Richard Bos]

Yes, I agree. What's your point? Func3 and Func4 are still less readable.

Wrong. You had it right last time: they're less readable _to you_. To
someone else, who wrote those lines, they're presumably more readable.

And my point? My point was that you're going to encounter a whole lot
worse than Frederick's unusual, but at least consistent style, so if you
get fazed by that kind of word order, you need more experience.

Richard

 

[Richard Bos]

If you don't care, why not just do it the way everyone else does it?

Who is this mythical "everyone" you keep harping on about? The
"everyone" who always uses the same style as "everyone" else? The one,
golden, omnipotent, omnipresent, sacrosanct C style?

If you read code that does not come from your own shop, you _are_ going
to encounter different styles of coding. Many of them are a lot less
consistent than Frederick's. And contrary to the assertions made in this
thread, it is not unfamiliarity which makes code hard to read - not for
longer than five minutes - it is inconsistency. I can easily read any
reasonably laid-out code, even if it's different from mine. The problems
start when a coder starts mixing styles at random.

Richard