«

"io_x" <> wrote in message
news:4c1bc6dd$0$18995$ ...
>
> "Keith Thompson" <kst-> ha scritto nel messaggio
> news:...

>> I have to figure out, not just what R means, but what *you* mean
>> by R. Sure, the #define is there, but I have to spend extra time
>> finding it to make sure you didn't define it as "restrict" or
>> "register", or "(void)".
>
> you spend the extra time
> mult that for 4 or 5 (the number of the macros)
> it can be how much? 5 minuts
>
> and for the rest of the code all will be ok, no search more

My text editor is an ancient text-mode one I wrote a couple of decades ago I
think.

Yet I still managed to define the first few function keys as "return ", "for
(", "printf("" and so on. It took half a minute.

Now it is even easier to type these keywords, as you don't need to use the
shift key or follow with a space. (And you can also add " (" for for/while,
and "("" for printf, which would look terrible if you tried it with macros:
W i>0) ...

The advantage is that the result is readable by everybody, who additionally
don't have to suffer from your inability to type, or to use better tools.
(As it happens, I don't have a problem with typing out keywords in full;
it's punctuation I don't like..)

--
Bartc

On 06/17/10 09:22 PM, io_x wrote:
> "Ian Collins"<ian-> ha scritto nel messaggio
> news:...
>> On 06/16/10 09:28 PM, io_x wrote:
>>> [comp.lang.c,comp.lang.c++]
>>>
>>> what about one function that do difference of 2 dates?
>>> where date is class or struct of type
>>> int sec, min, ora, day, mese, anno;
>>> where the difference is in
>>> sec, min, ora, day, mese, anno
>>>
>>> #define R return
>>
>> Why?
>
> why not?
> "R" it is small, many spaces saved, [more code for line an better indented]
> than for read is better than return
> at last here
>
> than "#define R return" is not standard C or C++?
>
> you whoudl say not understand standard C or C++?

If you ever try and use that style on an opensource project or as part
of professional team, you will quickly be told to stop.

--
Ian Collins

On 6/18/2010 5:36 PM, Richard Heathfield wrote:
> [... `#define R return' and similar foolishness ...]
>
> Clearly he is not interested in other people's opinion of his coding
> style.[...]

What makes you think this is his coding style? Anyone who
actually used it for more than half an hour would discover its
disadvantages for himself, without help from others. It's not
his coding style at all: it's just his way of being annoying and
proving himself a half-assed half-wit.

--
Eric Sosman
lid

"io_x" <> wrote:

> "Dann Corbit" <> ha scritto nel messaggio

> > C tends to be terse enough.
>
> it is not true, nothing is enought terse

You're an idiot.

Not terse enough? How about this, then:

**** off.

Richard

Eric Sosman <> writes:
> On 6/18/2010 5:36 PM, Richard Heathfield wrote:
>> [... `#define R return' and similar foolishness ...]
>>
>> Clearly he is not interested in other people's opinion of his coding
>> style.[...]
>
> What makes you think this is his coding style? Anyone who
> actually used it for more than half an hour would discover its
> disadvantages for himself, without help from others. It's not
> his coding style at all: it's just his way of being annoying and
> proving himself a half-assed half-wit.

If he only used it in code that nobody else ever looked at, it
would be viable. After a little time, he'd get used to the idea
that P means printf, R means return, and so forth. I see no reason
to doubt that he uses it in his own code.

He just doesn't seem to understand, after repeated and clear
explanations, that it hurts his code's readability for other people.
I don't know how he can fail to understand that, but somehow he
manages.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 18 June, 20:29, "io_x" <a...@b.c.invalid> wrote:
> "Dann Corbit" <dcor...@connx.com> ha scritto nel messaggionews: nal-september.org...

<snip>

> > C tends to be terse enough.
>
> it is not true, nothing is enought terse

have you looked at APL?

On 21 June, 11:28, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:9d2df0fb-09fb-43e8-b276-...
> > On 18 June, 20:29, "io_x" <a...@b.c.invalid> wrote:
> >> "Dann Corbit" <dcor...@connx.com> ha scritto nel
> >> messaggionews: nal-september.org...

> >> > C tends to be terse enough.
>
> >> it is not true, nothing is enought terse
>
> > have you looked at APL?
>
> i did not look to APL, but know the problem
> symbols can not be so many that someone can not remember well
> what they mean

APL achieves great terseness


> but this is not again the point:
> more terse i can write one algo in one language
> more comment, more space for indentation i can use in meaningful way
> in that language

maybe if you weren't so terse you wouldn't so much comment. The aim is
clarity. I could write a large comment and encode the machine code
into some base 64 encoding. It'd be terse.


> if for example C miss the power of goto,

what? In what way does C "miss the power of goto"? Not that I agree
goto *is* powerful.

> could be some other
> language that can use that for reduce the algo size to 1/2 or 1/8
> [than the C one] and so increase the readability
> of the expanded one [the one with the spaces and comments]

well you're flying in the face of 40 years of good software
engineering practice. But good luck.

Try "Structure and Interpretation of Computer Programs"


--

I mean, if 10 years from now, when you are doing something quick and
dirty,
you suddenly visualize that I am looking over your shoulders and say
to
yourself, "Dijkstra would not have liked this", well that would be
enough
immortality for me.
-- Edsger W Dijkstra

In article <e42d7387-6c6c-47be-986c-e4f8998ce030
@z8g2000yqz.googlegroups.com>, says...
>
> On 21 June, 11:28, "io_x" <a...@b.c.invalid> wrote:
> > "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:9d2df0fb-09fb-43e8-b276-...
> > > On 18 June, 20:29, "io_x" <a...@b.c.invalid> wrote:
> > >> "Dann Corbit" <dcor...@connx.com> ha scritto nel
> > >> messaggionews: nal-september.org...
>
> > >> > C tends to be terse enough.
> >
> > >> it is not true, nothing is enought terse
> >
> > > have you looked at APL?
> >
> > i did not look to APL, but know the problem
> > symbols can not be so many that someone can not remember well
> > what they mean
>
> APL achieves great terseness
>
>
> > but this is not again the point:
> > more terse i can write one algo in one language
> > more comment, more space for indentation i can use in meaningful way
> > in that language
>
> maybe if you weren't so terse you wouldn't so much comment. The aim is
> clarity. I could write a large comment and encode the machine code
> into some base 64 encoding. It'd be terse.
>
>
> > if for example C miss the power of goto,
>
> what? In what way does C "miss the power of goto"? Not that I agree
> goto *is* powerful.
>
> > could be some other
> > language that can use that for reduce the algo size to 1/2 or 1/8
> > [than the C one] and so increase the readability
> > of the expanded one [the one with the spaces and comments]
>
> well you're flying in the face of 40 years of good software
> engineering practice. But good luck.
>
> Try "Structure and Interpretation of Computer Programs"

If terseness is the goal, then I suggest forth.
In the end, the program will be a single word.

On Jun 17, 4:22*am, "io_x" <a...@b.c.invalid> wrote:
> "Ian Collins" <ian-n...@hotmail.com> ha scritto nel messaggionews:...
>
> > On 06/16/10 09:28 PM, io_x wrote:
> >> [comp.lang.c,comp.lang.c++]
>
> >> what about one function that do difference of 2 dates?
> >> where date is class or struct of type
> >> int *sec, min, ora, day, mese, anno;
> >> where the difference is in
> >> sec, min, ora, day, mese, anno
>
> >> #define *R *return
>
> > Why?
>
> why not?

Because it is *BAD PRACTICE*. It has been my experience over the last
twenty years that replacing keywords with "shortcut" macros *always*
creates maintenance headaches. Professional C programmers expect to
see the regular complement of keywords in the code they are writing or
maintaining. It allows them to understand the code more quickly and
to modify it with some confidence that we know what they're doing.

When someone starts replacing common keywords and structures (for(),
while(), do-while(), etc.) with their own custom "shortcuts", it makes
to code harder for other people to understand and modify. We have to
go hunting for the macro definition, and once we find it, have to do
our own mental preprocessing step every time we see it.

It slows other people down, it makes it easier for mistakes to be
missed (or created), and it doesn't actually buy you anything in the
end. All you've saved is a few dozen characters in the source text,
which is *meaningless*, and in exchange you've made that same code
harder to read and maintain.

If you're going to write C code, WRITE C CODE, not some bastard
customized version that only you understand, *especially* if you
expect other people to help you. Preprocessor abuse is probably
responsible for more lost productivity than just about anything else.

On Jun 21, 4:47*pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> John Bode wrote:
>
> <snip>
>
> > Preprocessor abuse is probably
> > responsible for more lost productivity than just about anything else.
>
> WWII?
>

Yes.