Re: ANSI C compliance
From: Steve Summit (scs_at_eskimo.com)
Date: 11/05/03
- Previous message: Steve Summit: "Re: ANSI C compliance"
- In reply to: Roose: "ANSI C compliance"
- Next in thread: Roose: "Re: ANSI C compliance"
- Reply: Roose: "Re: ANSI C compliance"
- Reply: Alan Balmer: "Re: ANSI C compliance"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 5 Nov 2003 01:56:01 GMT
Roose wrote:
> Writing truly standard C as valued by the "regulars" in this newsgroup
> is time-consuming if you're not experienced. And it takes time to
> accumulate the knowledge necessary to do so. Thus, in the business
> world, it is not considered good practice, since time = money.
If you stop to think about it, this is a pretty meaningless
statement. Take out the words "truly standard C as valued by the
regulars in this newsgroup" and replace them by any positive
attribute of code you can think of:
Writing functional code is time-consuming if you're not experienced.
Writing maintainable code is time-consuming if you're not experienced.
Writing compact code is time-consuming if you're not experienced.
Writing efficient code is time-consuming if you're not experienced.
Writing correct code is time-consuming if you're not experienced.
Are all of these, then, "not considered good practice" in the
business world?
The obvious solution here is to work on gaining some good
experience, so that good code (by any metric) doesn't have to be
so time-consuming to write.
> There is a notion called "speculative generality"... This is
> basically when you write code that speculates on what you may...
> need in the future. Instead of writing code that does exactly
> what you need to do, you write something that does more than that,
> potentially.
And this is a very tricky set of ideas to think properly about.
Yes, sometimes when you overengineer something you're wasting
resources which could be better spent elsewhere, no question.
But other times, a certain level of overengineering is not just
good practice, it's mandatory. In the real world, for example,
it's not "overengineering" to build a structure to withstand a
severe storm. To build a house that can withstand exactly the
weather conditions you're experiencing today, but which falls
down during the first rain or windstorm, would be folly.
> Portability is a feature of code. Thinking about portability
> to machine with 9 bit bytes or 2 stacks or no stack or 6 stacks
> is a waste of time...
I don't think anyone here is advocating always writing code which
tries to be portable to machines with 9 bit bytes. (Personally,
I don't even know how to.) Your other examples are even more
absurd, since no C program (let alone a portable one) can even
tell how many stacks there might be.
> Writing 100% ANSI C when you are not in a special circumstance
> (like the one I listed above) is considered speculative generality...
> Even if you DO have a forseeable need for it, it is considered good
> practice to solve _only the problem at hand_.
You keep saying, "is considered". Is considered by *who*?
By you? By the managers at the software companies that foist upon
the world laughably insecure, virus-infested operating systems,
and word processors that perform functions that no sane person
would require of them and ("Ford added savagely") go beep to tell
you when they've done it? They can have their opinions of what
"is considered" good practice, thank you; me, I think I'll use my own.
> Business requirements are extremely volatile. Executives are fickle.
Programmers who let executives tell them how to write their code
are jointly responsible for the unmaintainable failures they go on
to create.
Steve Summit
scs@eskimo.com
- Previous message: Steve Summit: "Re: ANSI C compliance"
- In reply to: Roose: "ANSI C compliance"
- Next in thread: Roose: "Re: ANSI C compliance"
- Reply: Roose: "Re: ANSI C compliance"
- Reply: Alan Balmer: "Re: ANSI C compliance"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|