code portability

[Eigenvector]

My question is more generic, but it involves what I consider ANSI standard C
and portability.

I happen to be a system admin for multiple platforms and as such a lot of
the applications that my users request are a part of the OpenSource
community. Many if not most of those applications strongly require the
presence of the GNU compiling suite to work properly. My assumption is that
this is due to the author/s creating the applications with the GNU suite.
Many of the tools requested/required are GNU replacements for make,
configure, the loader, and lastly the C compiler itself. Where I'm going
with this is, has the OpenSource community as a whole committed itself to at
the very least encouraging its contributing members to conform to ANSI
standards of programming?

My concern is that as an admin I am sometimes compelled to port these
applications to multiple platforms running the same OS and as the user
community becomes more and more insistent on OpenSource applications will
gotcha's appear due to lack of portability in coding? I fully realize that
independent developers may or may not conform to standards, but again is it
at least encouraged?

11.32 of the FAQ seemed to at least outline the crux of what I am asking.
If I loaded up my home machine to the gills will all open source compiler
applications (gcc, imake, autoconfig, etc....) would my applications that I
compile and link and load conform?

[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

[Richard Heathfield]

Frederick Gotham said:

Ian Collins posted:

>I pity anyone who has to maintain your code.

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?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[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;

--

Frederick Gotham

[Ian Collins]

Frederick Gotham wrote:

Ian Collins posted:

>>I pity anyone who has to maintain your code.

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.

--
Ian Collins.

[Richard]

Keith Thompson <ks***@mib.orgwrites:

Frederick Gotham <fg*******@SPAM.comwrites:

>Keith Thompson posted:

>>Yes, it is. And how exactly is that useful? "int unsigned" is legal,
but all it's going to do is confuse the reader.

People have different coding styles.

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

>>"unsigned int" or just "unsigned" is far more common, and won't confuse
the reader.

Is there some reason you want to confuse your readers?

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]

Frederick Gotham wrote:

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.

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

--
Ian Collins.

[Philip Potter]

"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:Pt*******************@news.indigo.ie...

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.

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.)

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;

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.

--
Philip Potter

[Racaille]

Richard Heathfield wrote:

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

--

Frederick Gotham

[Richard]

Frederick Gotham <fg*******@SPAM.comwrites:

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:

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.

[Richard Heathfield]

Racaille said:

Richard Heathfield wrote:

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

and at least one implementation does it like that.

which one ?

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Philip Potter]

"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:O8*******************@news.indigo.ie...

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.

--

Philip Potter

[Al Balmer]

On Tue, 08 Aug 2006 09:05:51 GMT, Frederick Gotham
<fg*******@SPAM.comwrote:

>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.

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;

--
Al Balmer
Sun City, AZ

[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?

--

Frederick Gotham

[Keith Thompson]

Frederick Gotham <fg*******@SPAM.comwrites:

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.

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? 8-)}

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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalidwrites:

Racaille said:

>Richard Heathfield wrote:

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

and at least one implementation does it like that.

which one ?

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.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Al Balmer]

On Tue, 08 Aug 2006 16:44:55 GMT, Frederick Gotham
<fg*******@SPAM.comwrote:

>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?

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.

--
Al Balmer
Sun City, AZ

[Keith Thompson]

Frederick Gotham <fg*******@SPAM.comwrites:

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:

[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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Keith Thompson said:

Frederick Gotham <fg*******@SPAM.comwrites:

>>
I like my style though.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Frederick Gotham]

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.

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.

--

Frederick Gotham

[Frederick Gotham]

Richard Heathfield posted:

Keith Thompson said:

>Frederick Gotham <fg*******@SPAM.comwrites:

>>>
I like my style though.

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.

<OFF-TOPIC>
I started my new style of definitions when I delved deep into template
programming in C++. Some of my definitions were three lines long (when
word-wrapped), and so I separated the lines like as follows:

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

It's a lot clearer to me like that.

It made sense to overhaul my entire style once I'd seen the light.
</OFF-TOPIC>

--

Frederick Gotham

[Ian Collins]

Frederick Gotham wrote:

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.

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.

What a load of twaddle.

Are you claiming

static inline int Func(...

is less efficient than

int inline static Func(...

Which was the style issue under discussion.

>
God forbid they might actually adopt my style.

+1 to that.

--
Ian Collins.

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalidwrites:

Keith Thompson said:

>Frederick Gotham <fg*******@SPAM.comwrites:

>>I like my style though.

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.

Absolutely. But he's shooting himself in the foot, and I have some
vague hope that I might be able to help him realize that.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Flash Gordon]

Frederick Gotham wrote:

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.

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.

Of the code I have completely rejected at review:
Some was reused and failed exactly as I said it would. I actually
rejected it before the review, then someone else reviewed it and
let it through.

Some I rewrote and the original author agreed my rewrite was better.

Code reviews do not mean the code has to be dumbed down. They are about
ensuring quality.

>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?

Where I used to work someone would sit down with you and rewrite it to
be correct, maintainable, conforming to our standard and reasonably
efficient. Of course, we would only expect to do this with someone still
learning to program and it would be quietly suggested to the technical
authority on the project that s/he should spend more time with this
person obviously still in need of lots of training.

>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.

Why should they when for so many the more common style reads more easily?
--
Flash Gordon
Still sigless on this computer.

[Frederick Gotham]

Ian Collins posted:

>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.

What a load of twaddle.

Are you claiming

static inline int Func(...

is less efficient than

int inline static Func(...

Which was the style issue under discussion.

No, I was referring to how people who work as programmers tend to suck all
the efficiency out of their code so that it will pass a code review.

--

Frederick Gotham

[Ian Collins]

Frederick Gotham wrote:

Ian Collins posted:

>>>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.

What a load of twaddle.

Are you claiming

static inline int Func(...

is less efficient than

int inline static Func(...

Which was the style issue under discussion.

No, I was referring to how people who work as programmers tend to suck all
the efficiency out of their code so that it will pass a code review.

Not in my shop.

--
Ian Collins.

[Ian Collins]

Ian Collins wrote:

>
Not in my shop.

I forgot to say we don't do code reviews.

--
Ian Collins.

[Stephen Sprunk]

"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:4Z*******************@news.indigo.ie...

Ian Collins posted:

>>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.

What a load of twaddle.

....

No, I was referring to how people who work as programmers tend to
suck all the efficiency out of their code so that it will pass a
code
review.

Efficiency only matters after you've established correctness. If I
can't determine if your code is correct, it fails. If it is correct
and the lack of clarity has measurable positive effects on efficiency,
then I'd pass it as long as it was commented well enough that another
coder would be able to maintain it later.

However, most "efficiency" claims I've seen to justify bad code are
not only unjustified (it has no positive effect on performance), but
they often tend to be _wrong_ as well, as the "efficient" coder has
managed to (a) rely on non-portable assumptions that will break when
the code is ported or under various edge cases, or (b) confuse the
compiler enough that the code is actually slower than a clearer
idiomatic implementation.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

Keith Thompson said:

Richard Heathfield <in*****@invalid.invalidwrites:

>Keith Thompson said:

>>Frederick Gotham <fg*******@SPAM.comwrites:
I like my style though.

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.

Absolutely. But he's shooting himself in the foot, and I have some
vague hope that I might be able to help him realize that.

He doesn't strike me as a learner, somehow. Let's hope we're wrong.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Al Balmer]

On Tue, 08 Aug 2006 21:01:52 GMT, Frederick Gotham
<fg*******@SPAM.comwrote:

>Ian Collins posted:

>>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.

So, you're an amateur, coding strictly for your own ends. OK, that's
fine.

>>>

What a load of twaddle.

Are you claiming

static inline int Func(...

is less efficient than

int inline static Func(...

Which was the style issue under discussion.

No, I was referring to how people who work as programmers tend to suck all
the efficiency out of their code so that it will pass a code review.

Now, just how would you know that, since you have no truck with code
reviews? In any case, it's just one more thing you "know" that isn't
true.

--
Al Balmer
Sun City, AZ

[Al Balmer]

On Wed, 09 Aug 2006 09:27:49 +1200, Ian Collins <ia******@hotmail.com>
wrote:

>Ian Collins wrote:

>>
Not in my shop.

I forgot to say we don't do code reviews.

Nor do we, on a routine basis. We do code reviews for new hires until
we gain confidence in them. That's partly a job review and partly
training, and very much to insure correctness and maintainability. In
addition, programmers review each other's code on request.

--
Al Balmer
Sun City, AZ

[Dik T. Winter]

In article <HM********************@bt.comin*****@invalid.invalid writes:

Racaille said:

Richard Heathfield wrote:

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

and at least one implementation does it like that.

which one ?

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

If I remember correctly, the standard compiler was switchable with
respect to the size of short, either 64 bits or 32 bits.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Frederick Gotham]

Al Balmer posted:

>>>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.

So, you're an amateur, coding strictly for your own ends. OK, that's
fine.

This newsgroup is comp.lang.c, not comp.lang.c.business.

I am predominantly a C++ programmer, however I can program in C.

My own code does not suffer from any restrictions which a company may
impose, and so I strive to write quality, fully-portable, Standard-
compliant, efficient code.

I am not the best C++ programmer in the world, nor am I the best C
programmer in the world; however I feel that I am up there with the best.
Perhaps I'm in the top 5% maybe?

I visit newsgroups for hours each day because I want to be a brilliant
programmer. My aspiration has nothing to do with money, nothing to do with
career, and everything to do with passion. Funny as it may sound, (and as
unhealthy as it may sound), computers are a fundamental part of my life.
From childhood, while most kids were playing with batman toys, I was busy
writing batch files. I can remember how great I felt when, at the age of
about 8, I wrote a batch file to allow the user to select their startup; I
gave them a choice of command prompt, or Windows, or Norton Commander. I
spent day after day learning the in's and out's of "config.sys" and
"autoexec.bat". I can recall the joy I had experimenting with "ansi.sys",
making colourful command prompts and so forth...

My interest in computers progressed over the years, and I took up
programming in the form of Visual Basic at the age of about 12. From there,
I moved on to C++. After a few years of programming in C++, I became
complacent with "high level" programming, and wanted to get back to some
*real* programming. That's why I post on comp.lang.c.

Posting here, and over on comp.lang.c++, I am disconcerted by the ever-
frequent mention of business. I would have thought that programmers would
be passionate about what they do, and that they would turn their back on
any prospect of perverting or dumbing down their programming to satisfy the
man in the suit. At the moment, it seems that I'm in the minority here, and
so be it. Thankfully though, twenty years down the road, still shy of
forty, I forsee myself as being a programmer of the highest proficiency. If
there's anything I can learn from these newsgroups, it's that I never want
to program as an occupation.

In the future, I think I would take great satisfaction from teaching
programming, and concurrently working voluntarily on a Standard's
Committee.

--

Frederick Gotham

[Ian Collins]

Frederick Gotham wrote:

>
I am predominantly a C++ programmer, however I can program in C.

My own code does not suffer from any restrictions which a company may
impose, and so I strive to write quality, fully-portable, Standard-
compliant, efficient code.

Commendable objectives.

It may not be popular in these parts, but I'd recommend you become
familiar with Test Driven Development as a way of enhancing the quality
of your code, both in design and implementation.

Don't just concentrate on the details of coding, keep an open mind and
investigate alternative ways of producing code.

>
Posting here, and over on comp.lang.c++, I am disconcerted by the ever-
frequent mention of business. I would have thought that programmers would
be passionate about what they do, and that they would turn their back on
any prospect of perverting or dumbing down their programming to satisfy the
man in the suit. At the moment, it seems that I'm in the minority here, and
so be it.

Unfortunately that's the real world we professional programmers inhabit,
although I've never had to, or in recent years required my staff to
"dumb down" programming. I'm not sure from where or on what basis you
make that observation.

Thankfully though, twenty years down the road, still shy of
forty, I forsee myself as being a programmer of the highest proficiency. If
there's anything I can learn from these newsgroups, it's that I never want
to program as an occupation.

Then broaden you horizons, learn as many languages and methodologies as
you can, over time you will find the path that works best for you.

--
Ian Collins.

[Keith Thompson]

Frederick Gotham <fg*******@SPAM.comwrites:

Al Balmer posted:

>>>>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.

So, you're an amateur, coding strictly for your own ends. OK, that's
fine.

This newsgroup is comp.lang.c, not comp.lang.c.business.

[snip]

I visit newsgroups for hours each day because I want to be a brilliant
programmer.

[snip]

In the future, I think I would take great satisfaction from teaching
programming, and concurrently working voluntarily on a Standard's
Committee.

Ok, you want to be the best C (<OT>and/or C++</OT>) programmer you can
be. That's terrific, and I say that without a trace of sarcasm.

What I don't understand is how this quest leads you to declare things
backwards, using "int unsigned" rather than the far more common
"unsigned int". (Note that even in English grammar, "unsigned int"
makes more sense; "unsigned" is an adjective, and "int" is a noun --
not that that's a decisive argument.)

You've invented a set of rules for how you order keywords, taking
advantage of the fact that the compiler doesn't care. The result is
difficult to read for 99% of C programmers. It's not impossible to
read, just annoyingly difficult, and for no benefit that I can see.

For myself, it makes me less inclined to spend any time reading
articles you post if they use your unconventional ordering. You're
not programming in a vacuum, you're participating in this newsgroup,
and you are, as Henry Spencer wrote, "creating beautiful new
impediments to understanding".

If there were some real benefit, I wouldn't be complaining.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Eigenvector]

"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:O8*******************@news.indigo.ie...

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?

Man I don't know where you work, but every single programmer I manage on my
system codes by the methods outlined by the customer - NOT what they feel is
appropriate. If the customer wants his int variables to be named using some
arcane mathematical formula then so be it, if they want the int variables to
be a,b,c,d,e,f,... then so be it. The coding standard is determined by the
project and the customer, never the coder - at least in my realm.

>
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

--

Frederick Gotham

[J. J. Farrell]

Frederick Gotham wrote:

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.

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.

Why should a code review result in dumbing down or reduction of
efficiency? I've never known a code review do either of these things;
more often just the opposite.

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?

Definitely not. You'd have to correct what you'd screwed up since the
first review as well as correcting what was brought up the first time.

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.

Well prayed, sir; I sincerely hope he does.

[ena8t8si]

Frederick Gotham wrote:

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?

I suspect most potential responders believe your comments wouldn't
have enough value to be worth the effort of posting.

[ena8t8si]

Keith Thompson wrote:

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? 8-)}

Excellent comment! You beat me to this one... GMTA (ASDO)

[ena8t8si]

Ian Collins wrote:

>
It may not be popular in these parts, but I'd recommend you become
familiar with Test Driven Development as a way of enhancing the quality
of your code, both in design and implementation.

Kindly take your TDD proselytizing to a newsgroup where
it's topical.

[jmcgill]

en******@yahoo.com wrote:

Ian Collins wrote:

>It may not be popular in these parts, but I'd recommend you become
familiar with Test Driven Development as a way of enhancing the quality
of your code, both in design and implementation.

Kindly take your TDD proselytizing to a newsgroup where
it's topical.

That's a bit harsh.

[Ian Collins]

en******@yahoo.com wrote:

Ian Collins wrote:

>>It may not be popular in these parts, but I'd recommend you become
familiar with Test Driven Development as a way of enhancing the quality
of your code, both in design and implementation.

Kindly take your TDD proselytizing to a newsgroup where
it's topical.

Typical knee-jerk reaction of an anonymous closed mind.

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

en******@yahoo.com wrote:

>Ian Collins wrote:

>>>It may not be popular in these parts, but I'd recommend you become
familiar with Test Driven Development as a way of enhancing the quality
of your code, both in design and implementation.

Kindly take your TDD proselytizing to a newsgroup where
it's topical.

Typical knee-jerk reaction of an anonymous closed mind.

Then tally up another knee-jerk.

Phlip in c.p has made himself a right PITN by going on and on and on about
TDD. Please don't make the same mistake. The clc group is about the C
language, not about development strategies.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[ena8t8si]

jmcgill wrote:

en******@yahoo.com wrote:

Ian Collins wrote:

It may not be popular in these parts, but I'd recommend you become
familiar with Test Driven Development as a way of enhancing the quality
of your code, both in design and implementation.

Kindly take your TDD proselytizing to a newsgroup where
it's topical.

That's a bit harsh.

What's harsh about it? It's not topical in comp.lang.c.
The word proselytize has a bad rep with some people,
but I meant it in the literal sense of the word:

To induce someone to join one's own belief or doctrine

That seems like a fair and accurate description of the
comments I was responding to.

[ena8t8si]

Ian Collins wrote:

en******@yahoo.com wrote:

Ian Collins wrote:

>It may not be popular in these parts, but I'd recommend you become
familiar with Test Driven Development as a way of enhancing the quality
of your code, both in design and implementation.

Kindly take your TDD proselytizing to a newsgroup where
it's topical.

Typical knee-jerk reaction of an anonymous closed mind.

Regardless of who is having a knee-jerk reaction or who has
a closed mind, the topic is still off-topic in comp.lang.c.

[jmcgill]

en******@yahoo.com wrote:

What's harsh about it? It's not topical in comp.lang.c.

I do a great deal of unit testing, functional testing, and acceptance
testing, and I'd like to know right now if I'm going to be abused by you
if the topic comes up with regard to programming and testing C.
In particular, I would like to know if you have some sort of moderator
authority, or if you are a major contributor to the forum, or any other
reason why I should refrain from putting you in my killfile at this time.

[Ian Collins]

Richard Heathfield wrote:

Ian Collins said:

>>en******@yahoo.com wrote:

>>>Ian Collins wrote:
It may not be popular in these parts, but I'd recommend you become
familiar with Test Driven Development as a way of enhancing the quality
of your code, both in design and implementation.
Kindly take your TDD proselytizing to a newsgroup where
it's topical.

Typical knee-jerk reaction of an anonymous closed mind.

Then tally up another knee-jerk.

Phlip in c.p has made himself a right PITN by going on and on and on about
TDD. Please don't make the same mistake. The clc group is about the C
language, not about development strategies.

I certainly wouldn't want to be tarred with that brush!

--
Ian Collins.

[Flash Gordon]

Frederick Gotham wrote:

<snip>

Posting here, and over on comp.lang.c++, I am disconcerted by the ever-
frequent mention of business.

Many of us here earn our living writing software.

I would have thought that programmers would
be passionate about what they do, and that they would turn their back on
any prospect of perverting or dumbing down their programming to satisfy the
man in the suit.

What makes you think you have to pervert or dumb down your programming
just because you are working for a company? In over 20 years I've never
had to do that. I've never had to make code less efficient due to review
although when writing assembler I did once have to add in a *lot* more
commenting because the code was too convoluted to be followed without
massive commenting (it was required to be *extremely* efficient to meet
a real time requirement).

At the moment, it seems that I'm in the minority here, and
so be it. Thankfully though, twenty years down the road, still shy of
forty, I forsee myself as being a programmer of the highest proficiency. If
there's anything I can learn from these newsgroups, it's that I never want
to program as an occupation.

You seem to have developed a very strange idea of what it is to program
for a living. Matters of company style of layout are minor and many of
us have switched between style to conform. The important thing, and the
thing of interest IMHO, is solving the problems and the satisfaction of
seeing a customer successfully using your software.

In the future, I think I would take great satisfaction from teaching
programming, and concurrently working voluntarily on a Standard's
Committee.

Fine, but you still need to know about programming in the real world, be
it the open source community or commercially. The reality is that when
more than one person works on a project it is far easier to read if
everyone uses the same coding style and in the real world the majority
of complex pieces of software are worked on by multiple people.
--
Flash Gordon
Still sigless on this computer.

[Richard Heathfield]

Flash Gordon said:

Frederick Gotham wrote:

<snip>

>Posting here, and over on comp.lang.c++, I am disconcerted by the ever-
frequent mention of business.

Many of us here earn our living writing software.

Many of us here use third-party libraries written in C. That does not mean
that third-party libraries are topical in clc.

I would have thought that programmers would
be passionate about what they do, and that they would turn their back on
any prospect of perverting or dumbing down their programming to satisfy
the man in the suit.

What makes you think you have to pervert or dumb down your programming
just because you are working for a company? In over 20 years I've never
had to do that.

I have. In one case, I was told to use a separate loop counter for each of
several (distinct) loops within a function:

int i, j, k;

for(i = 0; i < n; i++)
{
foo(p, i);
}

DoSomethingThatAffectsSomeElementsIn(p);

for(j = 0; j < n; j++)
{
bar(p, j);
}

DoSomethingThatAffectsOtherElementsIn(p);

for(k = 0; k < n; k++)
{
bar(p, k);
}

because the team leader wasn't sure whether the loop counter went out of
scope after the termination of the loop in which it was used! This, despite
the fact that the loop counters clearly had exactly the same purpose, and
affected indexing into exactly the same array.

That was a good many years ago, when I was less confident about being able
to put my case authoritatively. (I knew I was right, but couldn't prove it
to the team leader's satisfaction.)

>In the future, I think I would take great satisfaction from teaching
programming, and concurrently working voluntarily on a Standard's
Committee.

Fine, but you still need to know about programming in the real world, be
it the open source community or commercially.

How is that relevant to comp.lang.c? I understand and indeed share your
objections to Mr Gotham's style, but surely that's his problem? He's made
his bed, and appears to be happy to lie in it. As long as he doesn't need
other people to help him out when he gets stuck, why should he change it?

The reality is that when
more than one person works on a project it is far easier to read if
everyone uses the same coding style and in the real world the majority
of complex pieces of software are worked on by multiple people.

But not all. There's nothing in the rules that says one person can't write
programs on his own. The C Standard allows the syntactic flexibility that
Mr Gotham is exploiting, and that's what matters. If we don't wish to read
it, we don't have to.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[ena8t8si]

jmcgill wrote:

en******@yahoo.com wrote:

What's harsh about it? It's not topical in comp.lang.c.

I do a great deal of unit testing, functional testing, and acceptance
testing, ...

So do I ...

and I'd like to know right now if I'm going to be abused by you
if the topic comes up with regard to programming and testing C.

If the comments are specific to C, I expect I'll read them with
interest. If I think I have something to contribute, there's
a good chance I'll reply.

If the comments aren't specific to C, but labeled "OT" in the
subject line, I might read them or I might not, depending on
how much time I have etc.

If the comments aren't specific to C, and not labeled OT,
most likely I'll do nothing if they occur only occasionally.

For repeated, non-C-specific, non-OT-labelled postings,
I might respond pointing out the non-topicality and a
request to take the topic to another newsgroup.

In particular, I would like to know if you have some sort of moderator
authority, or if you are a major contributor to the forum, or any other
reason why I should refrain from putting you in my killfile at this time.

I'm a contributor. I have no official capacity, I speak
only for me.

Having said that, the reigning culture in comp.lang.c
is to remind contributors about what's considered
topical, and especially what isn't. You might want
to read for a while before deciding which people are
worth a killfile entry. But that's up to you.