code portability

[Frederick Gotham]

Richard Heathfield posted:

Keith Thompson said:


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<NumT> const &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>

 

[Ian Collins]

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.

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.

 

[Keith Thompson]

Keith Thompson said:

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.

 

[Flash Gordon]

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.

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

God forbid they might actually adopt my style.

Why should they when for so many the more common style reads more easily?

 

[Frederick Gotham]

Ian Collins posted:

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.

 

[Stephen Sprunk]

Ian Collins posted: ....
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

 

[Ian Collins]

Ian Collins posted:





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]

Not in my shop.

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

 

[Richard Heathfield]

Keith Thompson said:

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.

 

[Dik T. Winter]

> Racaille said:
>
>
> 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.

 

[Al Balmer]

Ian Collins posted:

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

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]

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.

 

[Frederick Gotham]

Al Balmer posted:

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.

 

[Ian Collins]

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.

 

[Keith Thompson]

Al Balmer posted:

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.

 

[Eigenvector]

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:

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

 

[J. J. Farrell]

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.

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

God forbid they might actually adopt my style.

Well prayed, sir; I sincerely hope he does.

 

[ena8t8si]

Al Balmer posted:



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]

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

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

 

[ena8t8si]

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.