From: Keith Thompson on
Malcolm McLean <malcolm.mclean5(a)btinternet.com> writes:
> On Mar 3, 7:55 pm, Keith Thompson <ks...(a)mib.org> wrote:
>> Note that I also dropped some extraneous parentheses.  Too many
>> parentheses can be as confusing as too few,
>>
> I use the rule of three. Three levels of indirection, three dimensions
> in an array, or three nested parentheses. (Some people will realise
> that threse are different ways of saying the same thing).

I agree, mostly, that more than three levels of nested parentheses can
be confusing. I'm not convinced there should be a hard limit, or that
three is the right number, but I won't argue the point; you could well
be right about that.

But the code in question here only had two levels of nested
parentheses:

if ( ( pointer1 != NULL ) &&
( pointer1->field7 == 0x152 ) )
...

That's not an unreasonable depth of nesting, but IMHO the inner
parentheses still do nothing to aid legibility. I find this:

if ( pointer1 != NULL &&
pointer1->field7 == 0x152 )
...

or even this:

if ( pointer1 != NULL && pointer1->field7 == 0x152 )
...

easier to read and understand.

The point is that the number of levels of nesting shouldn't be the
*only* criterion for determining that a piece of code is difficult
to read.

The expression in question here is relatively simple. In more complex
cases, code layout can aid legibility -- or hurt it if the layout
doesn't reflect the logical structure of the code:

if( pointer1 !=
NULL&&pointer1->
field7
== 0x152)

--
Keith Thompson (The_Other_Keith) kst-u(a)mib.org <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"
From: Richard on
Malcolm McLean <malcolm.mclean5(a)btinternet.com> writes:

> On Mar 3, 3:01 pm, Lorenzo Villari <vll...(a)tiscali.it> wrote:
>>
>> I have to ask: what's the point nowadays of using a text mode only
>> editor, apart from hardware restrictions and years of use? I guess
>> that's "Masochistic answers to Stylistic questions on UNIX C coding"...
>>
> A lot of big computers still don't have windowing systems. Their
> cycles are too expensive to be used on updating GUIs.
> Someone somewhere will one day produce a client that lets you edit a
> text file, stored on a mainframe, on a PC or workstation GUI. However
> I haven't yet seen such a system. Uploading files by ftp manually is
> too much of a nuisance.
>

What on earth are you talking about?!?!?

One day you will be able to edit a text file on a mainframe??!?!?

People have been doing this since day dot.


--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
From: Malcolm McLean on
On Mar 3, 9:54 pm, Richard <rgrd...(a)gmail.com> wrote:
> Malcolm McLean <malcolm.mcle...(a)btinternet.com> writes:
>
> What on earth are you talking about?!?!?
>
> One day you will be able to edit a text file on a mainframe??!?!?
>
> People have been doing this since day dot.
>
The editor, emacs or vi, runs on the mainframe. It's not a GUI, but a
very clever way of using a text stream to create an interactive
editor.
However when you edit files ona PC you have a proper GUI, usually with
syntax highlighting, automatic function prototype popups, integrated
debugging, and all sorts of other nice things.

Someday someone will write a client that acts like Visual Studio to
the desktop, but actually executes code on the attached mainframe. In
fact such systems might exist, though I suspect it's the usual story
of someone tacking something up which superficially appears to attack
the problem, without really providing the fucntionality required. I've
certainly never used such a system.
From: Ian Collins on
Malcolm McLean wrote:
> On Mar 3, 9:54 pm, Richard <rgrd...(a)gmail.com> wrote:
>> Malcolm McLean <malcolm.mcle...(a)btinternet.com> writes:
>>
>> What on earth are you talking about?!?!?
>>
>> One day you will be able to edit a text file on a mainframe??!?!?
>>
>> People have been doing this since day dot.
>>
> The editor, emacs or vi, runs on the mainframe. It's not a GUI, but a
> very clever way of using a text stream to create an interactive
> editor.
> However when you edit files ona PC you have a proper GUI, usually with
> syntax highlighting, automatic function prototype popups, integrated
> debugging, and all sorts of other nice things.
>
> Someday someone will write a client that acts like Visual Studio to
> the desktop, but actually executes code on the attached mainframe. In
> fact such systems might exist, though I suspect it's the usual story
> of someone tacking something up which superficially appears to attack
> the problem, without really providing the fucntionality required. I've
> certainly never used such a system.

Something like

http://www.netbeans2.org/kb/docs/cnd/remotedev-tutorial.html

?

--
Ian Collins
From: Richard on
Malcolm McLean <malcolm.mclean5(a)btinternet.com> writes:

> On Mar 3, 9:54 pm, Richard <rgrd...(a)gmail.com> wrote:
>> Malcolm McLean <malcolm.mcle...(a)btinternet.com> writes:
>>
>> What on earth are you talking about?!?!?
>>
>> One day you will be able to edit a text file on a mainframe??!?!?
>>
>> People have been doing this since day dot.
>>
> The editor, emacs or vi, runs on the mainframe. It's not a GUI, but a
> very clever way of using a text stream to create an interactive
> editor.

You seem to be confusing different things. The editor is still editing
"on the mainframe".

> However when you edit files ona PC you have a proper GUI, usually with
> syntax highlighting, automatic function prototype popups, integrated
> debugging, and all sorts of other nice things.

As you do with emacs over ssh if you want too.

I think your soul issue seems to be that there is not a direct cable
from a video card to a monitor on the minframe? This is nothing new and
you can do it with PCs too - headless servers. They still generate a UI
however which is then rendered on the remote display device.

>
> Someday someone will write a client that acts like Visual Studio to
> the desktop, but actually executes code on the attached mainframe. In
> fact such systems might exist, though I suspect it's the usual story
> of someone tacking something up which superficially appears to attack
> the problem, without really providing the fucntionality required. I've
> certainly never used such a system.

You mean like x forwarding?!? What problem are you referring to? I've
used large maqinfrmes for years as well as Windows/Linux based PCs and I
really am lost as to what you're trying to say.

You do edit files "directly on the mainframe" and have been able to for
years. The mainframe provides the editing process and the client merely
display the UI generated by the servers vi/emacs client. Alternatively
you open a file via ssh edit locally and then save via ssh.


--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
First  |  Prev  |  Next  |  Last
Pages: 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
Prev: integer
Next: shared memory question