code portability

[Frederick Gotham]

Ian Collins posted:

I pity anyone who has to maintain your code.

Me too if they can't get their head around word order.

 

[Frederick Gotham]

Keith Thompson posted:

Ok, so your style is internally consistent, but it's inconsistent with
perhaps 99.73% of other C programmers (I made up that number).

I like my style though.

There's plenty of things I do which most C++ programmers don't do. For
instance, I use "++i" instead of "i++" when I discard the value of the
expression.

There are flaws in the way most programmers do things; my style tries to
improve on this.

char unsigned const static inline (*const Func(void))[3]

Anyone seeing that almost certainly going to spend far more time
wondering why the keywords are in that order and mentally translating
it to a more traditional order than appreciating the esthetics.

If they're only used to reading their own code, then they could do with the
practise of seeing other people's code. Do they brain-freeze when they see:

int const *p

rather than:

const int *p

As Henry Spencer wrote in "The Ten Commandments for C Programmers",
<http://www.lysator.liu.se/c/ten-commandments.html>:

... thy creativity is better used in solving problems than in
creating beautiful new impediments to understanding.

I make up the rules as I go along. I used to like:

const int *p;

, but now I use:

int const *p;

 

[Richard Heathfield]

Frederick Gotham said:

Ian Collins posted:


Me too if they can't get their head around word order.

If Yoda great Jedi Master is, why English sentences he cannot in the right
order speak?

 

[Ian Collins]

Ian Collins posted:





Me too if they can't get their head around word order.

They shouldn't have to. The excellent quote at the end of Keith's
comment is very pertinent to your style.

 

[Richard]

Keith Thompson posted:

People have different coding styles.

Yes. That doesn't mean all styles are equally good.

When I have a definition (or a declaration), I put things in order of
descending importance. The most important thing comes first.

First and foremost, I specify the type.

Next, I specify things such as "long", "short".

Next, I specify signedness, e.g. "signed", "unsigned".

[..]

Ok, so your style is internally consistent, but it's inconsistent with
perhaps 99.73% of other C programmers (I made up that number).

char unsigned const static inline (*const Func(void))[3]

Anyone seeing that almost certainly going to spend far more time
wondering why the keywords are in that order and mentally translating
it to a more traditional order than appreciating the esthetics.

And aint that the truth. I have a feeling that Fred has recently
mastered a few keywords and is bursting to use them.

As Henry Spencer wrote in "The Ten Commandments for C Programmers",
<http://www.lysator.liu.se/c/ten-commandments.html>:

... thy creativity is better used in solving problems than in
creating beautiful new impediments to understanding.

Very good. But there is something more important : concistency across
code base and anyone (I often suspect that not many here do) who works
on large, legacy systems knows the importance of good clear basic coding
styles which can be relatively easily understood by anyone with a
reasonable knowledge of the programming language in question.

I remember having one guy express his displeasure at the new edicts
which pretty much banned him from using his programming creativity on a
company code base. He was informed that at home he could program as he
saw fit : but on the huge, maintained system it was the documented way
or the highway.

 

[Ian Collins]

Keith Thompson posted:





I like my style though.

There's plenty of things I do which most C++ programmers don't do. For
instance, I use "++i" instead of "i++" when I discard the value of the
expression.

You're probably mistaken there, but this is a C group.

 

[Philip Potter]

Keith Thompson posted:



I like my style though.

There's plenty of things I do which most C++ programmers don't do. For
instance, I use "++i" instead of "i++" when I discard the value of the
expression.

There are flaws in the way most programmers do things; my style tries
to improve on this.

It's almost always better to stick with a coding style that you perceive as
flawed but which everyone is used to, than to use your own style which
(despite any advantage it may offer) nobody is used to and so nobody can
read. People get bogged down reading syntax and will spend less time
worrying about what the code actually *does*.

If they're only used to reading their own code, then they could do with the
practise of seeing other people's code. Do they brain-freeze when they see:

int const *p

rather than:

const int *p

Do people brain-freeze when they see a Dvorak keyboard? No. It's still got
the same number of letters as a QWERTY keyboard, just in a different order.
They haven't forgotten English, so they can clearly still use it for typing.

The problem is familiarity. If things are not familiar, then no matter how
"obvious" or "simple to work out" they are, they will take more time to
understand.

(Of course, if your local coding environment uses "int const *p" instead of
"const int *p" then you should stick with it.)

I make up the rules as I go along. I used to like:

const int *p;

, but now I use:

int const *p;

That's perfectly fine for a solitary developer. When more than one person
works on a piece of code, arbitrary clashing code styles will generally
cause more harm than good.

 

[Racaille]

char 8 bits
short 64 bits
int 64 bits
long 64 bits

and at least one implementation does it like that.

which one ?
(thanks & sorry, just curious)

 

[Frederick Gotham]

Philip Potter posted:

It's almost always better to stick with a coding style that you perceive
as flawed but which everyone is used to, than to use your own style
which (despite any advantage it may offer) nobody is used to and so
nobody can read.

If you're going to be reading other people's code, you need to be used to
variety.

If part of your job is reading other people's code, then you should be good
at it. It takes less than an hour to get used to different word orderings:

int const *p;

const int *p;

static inline int Func(...

int inline static Func(...

inline static int Func(...

static int inline Func(...

The people who are arguing that "other people should be able to read your
code" are the very people who have difficulty reading other people's code.
Big deal: I write "char unsigned" instead of "unsigned char"... is it
really that bewildering?

At then end of the day, if you have a problem with:

char unsigned const static inline (*const Func(void))[3]

, then you should take it up with the Standards Commitee -- because right
now, it's perfectly legal, and I like it. (And please don't come back with
an argument such as the following is legal:

#define void int
#define main core
#define start {
#define end }

void core()
start
return 0;
end

 

[Richard]

Philip Potter posted:



If you're going to be reading other people's code, you need to be used to
variety.

If part of your job is reading other people's code, then you should be good
at it. It takes less than an hour to get used to different word orderings:

You have clearly never had to do so.

In large code bases "other peoples codings" might just be 3 lines in a
200 line module : its called maintenance.

I've managed teams of up to 35 programmers and people who refuse to
conform to a (relatively liberal) coding standard soon become very, very
unpopular. There is really no excuse for "going it alone" in code bases
which are maintained globally by possibly hundreds of programmers and
which, invariably, end up in the customers hands for "on site"
tweaking. It is unprofessional and hard to keep up with.

Not only that, but when certain "initiatives" like the latest "must
have" ISO blah blah are ordered in by higher management, then non
conforming code can be very hard to recognise standard typings etc for
isolating the change areas.

 

[Philip Potter]

Philip Potter posted:

The people who are arguing that "other people should be able to read your
code" are the very people who have difficulty reading other people's code.
Big deal: I write "char unsigned" instead of "unsigned char"... is it
really that bewildering?

Personally, if I learn that somebody has trouble reading my code, I assume
that it's my fault, not theirs.

At then end of the day, if you have a problem with:

char unsigned const static inline (*const Func(void))[3]

, then you should take it up with the Standards Commitee -- because right
now, it's perfectly legal, and I like it. (And please don't come back with
an argument such as the following is legal:

#define void int
#define main core
#define start {
#define end }

void core()
start
return 0;
end

Why not? It's a perfectly good argument. Legality != readability.

 

[Richard Heathfield]

Racaille said:

which one ?

One of the Cray implementations. I forget which one. Nexus rings a bell, but
I wouldn't swear to it.

 

[Al Balmer]

Keith Thompson posted:



I like my style though.

There's plenty of things I do which most C++ programmers don't do. For
instance, I use "++i" instead of "i++" when I discard the value of the
expression.

There are flaws in the way most programmers do things; my style tries to
improve on this.

Kepp trying - you have a long way to go. First, you have to get up to
their level, then you can start improving things. Don't confuse
"different" with "better."

char unsigned const static inline (*const Func(void))[3]

Anyone seeing that almost certainly going to spend far more time
wondering why the keywords are in that order and mentally translating
it to a more traditional order than appreciating the esthetics.

If they're only used to reading their own code, then they could do with the
practise of seeing other people's code. Do they brain-freeze when they see:

int const *p

rather than:

const int *p

As Henry Spencer wrote in "The Ten Commandments for C Programmers",
<http://www.lysator.liu.se/c/ten-commandments.html>:

... thy creativity is better used in solving problems than in
creating beautiful new impediments to understanding.

I make up the rules as I go along. I used to like:

const int *p;

, but now I use:

int const *p;

 

[Frederick Gotham]

Al Balmer posted:

First, you have to get up to their level, then you can start improving
things.

Perhaps you'd like to post some of your own code, and I'll point out the
flaws?

 

[Keith Thompson]

Keith Thompson posted:


I like my style though.

Ok. What about anyone else who reads your code?

You can, of course, write anything you like, either in your C code or
on this newsgroup. But if you expect anyone else to read it, or
particularly to maintain it, you would benefit greatly from following
certain conventions that will make what you write easier to read.

Unless you manage to mount a *successful* campaign to change the
generally accepted style, you're just "creating beautiful new
impediments to understanding".

There's plenty of things I do which most C++ programmers don't do. For
instance, I use "++i" instead of "i++" when I discard the value of the
expression.

Most of us here do something most C++ programmer's don't do: we write C.
++i and i++ are equivalent when the value is discarded, and I find
them equally clear. (comp.lang.c++ is down the hall, past the water
cooler, third door on the left.)

There are flaws in the way most programmers do things; my style tries to
improve on this.

char unsigned const static inline (*const Func(void))[3]

Anyone seeing that almost certainly going to spend far more time
wondering why the keywords are in that order and mentally translating
it to a more traditional order than appreciating the esthetics.

If they're only used to reading their own code, then they could do with the
practise of seeing other people's code. Do they brain-freeze when they see:

int const *p

rather than:

const int *p

No, that's straightforward enough that my brain doesn't even get
chilly.

How do you feel about this?

char const inline static unsigned (*const Func(void))[3]

Don't you think there's some advantage in having all the keywords in
alphabetical order? }

I make up the rules as I go along.

[snip]

And that's the problem. If programming is a solitary activity for
you, that's fine. If not, I think you're making a mistake.

 

[Keith Thompson]

Racaille said:

One of the Cray implementations. I forget which one. Nexus rings a bell, but
I wouldn't swear to it.

Cray vector systems. I've seen this on the T90 and J90 (both of which
are more or less obsolete). I'm not sure what the newer vector
systems do.

These systems are optimized for massive floating-point calculations.
The hardware can only directly access 64-bit words; 8-bit bytes are
manipulated in compiler-generated software. (They could have made
ChAR_BIT 64, but that would have created too much incompatibility with
other systems, and with the Unix-based operating systems these things
run.)

 

[Al Balmer]

Al Balmer posted:



Perhaps you'd like to post some of your own code, and I'll point out the
flaws?

I wouldn't bother, since you and I obviously have very different ideas
as to what constitutes good code.

I'll just say that if you presented the examples you've shown in a
code review here, you'd be told to fix them. If the second review
wasn't drastically improved, there wouldn't be a third.

So, do your own thing, but I hope no one else ever has to deal with
it.

 

[Keith Thompson]

Philip Potter posted:


If you're going to be reading other people's code, you need to be used to
variety.

If part of your job is reading other people's code, then you should be good
at it. It takes less than an hour to get used to different word orderings:

[examples snipped]

And that's an hour of my life I'll never get back. I'll expend the
time if it's worth it.

The people who are arguing that "other people should be able to read your
code" are the very people who have difficulty reading other people's code.
Big deal: I write "char unsigned" instead of "unsigned char"... is it
really that bewildering?

It takes a small amount of time to figure it out the first time you
see it, and some more time to figure out why it's being written that
way. If I see "char unsigned" in some random piece of code, I'm not
just going to wonder why it's written that way, I'm also going to
wonder whether it's correct. I know the language allows either order,
but I'm going to have to allow for the possibility that the author
doesn't know what he's doing. I know that "unsigned char" and "char
unsigned" mean the same thing, but how do I know that the author knows
that?

At then end of the day, if you have a problem with:

char unsigned const static inline (*const Func(void))[3]

, then you should take it up with the Standards Commitee -- because right
now, it's perfectly legal, and I like it.

No, I'm taking it up with you, because you wrote it.

(And please don't come back with
an argument such as the following is legal:

#define void int
#define main core
#define start {
#define end }

void core()
start
return 0;
end

Why not? It's a perfectly valid argument, and it's very similar to
what you're doing.

For that matter, the standard doesn't require any particular code
layout. There are a number of different conventions for indentation
and brace placement, but something like this is perfectly legal:

#include <stdio.h>
int main
( void
) {
printf("Hello, world\n"
);}

Maybe you need to get used to variety. Or maybe it's just horribly
bad style.

 

[Richard Heathfield]

Keith Thompson said:

Ok. What about anyone else who reads your code?

If you don't like it, don't read it.

I don't like it, so I won't read it.

But how he writes his code is up to him. If he doesn't need other people to
read it (e.g. to help him out), then as long as he can read it, that's all
that matters.

 

[Frederick Gotham]

Al Balmer posted:

I wouldn't bother, since you and I obviously have very different ideas
as to what constitutes good code.

I'll just say that if you presented the examples you've shown in a
code review here, you'd be told to fix them.

Who said anything about a code review? My programming doesn't undergo a
"code review", and so I don't have to dumb it down and suck the efficiency
out of it to satisfy the politics of whomever I work for.

If the second review wasn't drastically improved, there wouldn't be a
third.

If my second try was 40% less efficient the second time around, would it
make the cut?

So, do your own thing, but I hope no one else ever has to deal with
it.

God forbid they might actually adopt my style.