Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: Keith Thompson on 3 Mar 2010 14:46 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 3 Mar 2010 14:54 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 3 Mar 2010 15:24 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 3 Mar 2010 15:29 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 3 Mar 2010 15:57
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 |