Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Write int as a 4 byte big-endian to file.

Reply
Thread Tools

Write int as a 4 byte big-endian to file.

 
 
Ike Naar
Guest
Posts: n/a
 
      03-13-2012
On 2012-03-13, gwowen <(E-Mail Removed)> wrote:
[about

bytes[i] = what % 256, what /= 256;

]

> Clever people do not write code like that. Clever people *can* write
> code like that, but are clever enough not to, because they understand
> maintainance burdens, and why code clarity beats code cleverness in
> 99.9999% of cases.


There can be a good reason to write code like that.
Suppose we have variables x and y that represent the position
of a bishop on a chess board. The piece is currently on
a black square, and this is an invariant according to the rules
of the game. No legal move can put it on a white square.
Now we move it from (x, y) (black square) to (x+3, y-3) (black square).

It could be written like this:

/* initial: black square */
x = x+3;
/* intermediate: white square */
y = y-3;
/* final: black square */

but the intermediate state violates the invariant and that's ugly.
It would be cleaner to write it like this (using Python-like multiple
assignment):

/* initial: black square */
x, y = x+3, y-3;
/* final: black square */

and avoid the invalid intermediate state.
Of course C does not have multiple assignment, but this comes close:

/* initial: black square */
x = x+3, y = y-3;
/* final: black square */

I think here the use of a comma expression leads to somewhat cleaner
code: the fact that it's a single statement shows the intention
to make one legal move, instead of two illegal moves that combine
into a legal move.
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      03-13-2012
gwowen <(E-Mail Removed)> writes:

> On Mar 12, 11:01¬*pm, jacob navia <(E-Mail Removed)> wrote:
>
>> I can fully understand why you do not like clever people.

>
> Clever people do not write code like that. Clever people *can* write
> code like that, but are clever enough not to, because they understand
> maintainance burdens, and why code clarity beats code cleverness in
> 99.9999% of cases.


I fully agree about clarity, but how unclear was the code and in what
way? I don't like the idea of avoiding parts of the language because
some future reader might not might not know it. For one thing, where do
you draw the line? Who decides what's generally well understood? But
my real objection is that the lack of clarity is superficial -- a quick
look on the web, or a check in a book and everything becomes clear again.

When I was, however briefly, doing this sort of maintenance, I never
minded that sort of "clever" code. Seeing a neat way to write something
made a dull job a little more interesting. I really don't ever recall
making a mistake because of a syntactic misunderstanding, nor do recall
being significantly impeded by such a thing.

All of the hard maintenance problems I recall came from trying to
understand the dynamic behaviour of a program. The most obvious example
in C is whether allocated memory is used after it's lifetime has ended,
but there are lots of other. The worst I ever saw was an old Unix sort
utility which passed pointers around without the proper conversions. It
was almost impossible to tell if the pointer you had at some point was
really a char pointer or a struct pointer and, because this was a
word-addressed machine, that mattered. It took weeks to get it running
and I very much doubt I got all the bugs out even then. I would have
happily traded a thousand uses of the most obscure C syntax for a
clearer and better organised program.

On the use of the comma operator, I agree with Tim that it's useful when
the purpose of the expressions are closely related. I use it,
for example, when a function "returns" more than one thing:

return *reason = ZERO_DIVIDE, FAIL;

--
Ben.
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      03-13-2012
tom st denis <(E-Mail Removed)> writes:

> On Mar 11, 4:08 pm, Tim Rentsch <(E-Mail Removed)> wrote:
>> "Morris Keesan" <(E-Mail Removed)> writes:
>> > On Sat, 10 Mar 2012 14:44:13 -0500, Tim Rentsch
>> > <(E-Mail Removed)> wrote:

>>
>> >> for( i = 3; i >= 0; i-- ) bytes[i] = what % 256, what /= 256;

>>
>> > What ??? Did you do this with a comma operator just to make it hard
>> > to read?

>>
>> No, I used a comma operator because I think of the two assignments
>> as a single conceptual unit (extract the low order bits and shift
>> those bits out of the word being worked on), so it seems natural
>> to express that conceptual unit as a single statement.

>
> If you worked under me I'd make you re-write that code properly.
> "Clever" people tend to write code that holds up less under the test
> of time.


If you worked under me you would learn that different
groups have rather different ideas about what constitutes
good or readable coding style, and it's better not to
be so dogmatic about it. But then neither one of those
hypotheticals holds, does it?
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      03-13-2012
gwowen <(E-Mail Removed)> writes:

> On Mar 12, 11:01 pm, jacob navia <(E-Mail Removed)> wrote:
>
>> I can fully understand why you do not like clever people.

>
> Clever people do not write code like that. Clever people *can* write
> code like that, but are clever enough not to, because they understand
> maintainance burdens, and why code clarity beats code cleverness in
> 99.9999% of cases.


The case in question was purely an issue of coding style. Some
people (I happen to be one of them) think the particular style
used improves clarity, not reduces it. If someone prefers a
different style, I'm okay with that. But I wouldn't call it
"clever" or "not clever", just a different style.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: byte + byte -> int Lew Java 6 03-21-2009 02:22 AM
how to read/write a characters stream which is either of one byte/2 byte Deep C Programming 6 02-28-2007 01:03 PM
read/write data byte-per-byte to and from a socket crash.test.dummy Java 1 02-17-2006 06:18 AM
int main(int argc, char *argv[] ) vs int main(int argc, char **argv ) Hal Styli C Programming 14 01-20-2004 10:00 PM
dirty stuff: f(int,int) cast to f(struct{int,int}) Schnoffos C Programming 2 06-27-2003 03:13 AM



Advertisments