Stylistic questions on UNIX C coding.

[James Harris]

James Harris wrote:



vi has only *one* input mode. It also has *one* command mode. That's not
too many to manage.


Yes, I remember WordStar. If you think modes are bad, try embedded dot
commands!

I agree that vi(m) is hard to learn. But it's easy to use, and I think
that is the most important criterion.

*I* didn't say that it's hard to learn! I don't think it is. However I
would say it's harder than necessary - which IMV is important.

vi also has the command mode (or whatever its correct name is) after
typing a colon and vim, at least, has macro entry mode then there's ex
mode and search modes etc but they are not too bad.

The problem I have with the two modes you mention is they look the
same. The interface isn't manifest, if you like. Also, sometimes there
is a genuine need to continually change mode such as entering
characters with short - e.g. one or two - cursor movements between
them (though the dot command can help if what's being entered is the
same in each case).

In contrast, I was thinking that an editor could/should have only one
mode: text entry. There would still be Control-[a-z] and Control-[A-Z]
for other commands without changing mode. For example, even on a
keyboard with no cursor keys the cursor movements could be generated
with single Control-<key> combination and longer commands could be
entered by Control-<key><key> where the editor brings up a menu
between the two keys. IIRC Wordstar only brought up the menu if typing
was slowish so those who remembered the second key didn't need to see
the menu and those who couldn't remember the second key got the menu
as a prompt.

Come back Wordstar, all is forgiven. Well, almost all....

James

 

[Ben Bacarisse]

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.

Have misunderstood? What you describe was commonplace when I last
used "big iron" more than a decade ago. The big servers all ran NFS
and you edited your files however you liked on your own workstation.
You don't even need NFS, but it was the standard at the time.

 

[Keith Thompson]

if ( ( pointer1 =! NULL )
&& ( pointer1->field7 = 0x152 ) ) {
return;
}

ops && ops

if ( pointer1 != NULL &&
pointer1->field7 == 0x152 )
{
return;
}

I put the opening brace on the same line as the "if" if it fits.
If it doesn't, I put it on a line by itself, so it doesn't get lost.
It's probably not entirely consistent, but it works well for me.

Note that I also dropped some extraneous parentheses. Too many
parentheses can be as confusing as too few, and I think it's
sufficiently obvious that "==" and "!=" bind more tightly than "&&".
The alignment of the subexpressions helps.

I do not suggest that my style is the only correct one.

 

[Malcolm McLean]

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).

 

[Ian Collins]

A lot of big computers still don't have windowing systems. Their
cycles are too expensive to be used on updating GUIs.

There are also a lot of small computers still don't have windowing
systems. We don't edit code on those either. We edit code on our
choice of desktop system.

 

[Ian Collins]

One point might be "screen real estate"

http://www.usabilityfirst.com/glossary/term_573.txl

aka "no clutter".

Use a bigger screen!

I'm sure the developers of Eclipse and NetBeans must all use 30" panels...

 

[Seebs]

There are also a lot of small computers still don't have windowing
systems. We don't edit code on those either. We edit code on our
choice of desktop system.

Sometimes. Actually, 99% of my editing is done remotely, so I use plain
text editors, because they let me do important things, like preserve an
editor session while travelling, or through several reboots, and so on.
Even when I'm working locally, I edit in a text editor in a shell, usually.
I find the convenience of the tools and environments and the faster interface
to be a win.

-s

 

[Keith Thompson]

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)

 

[Malcolm McLean]

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.

 

[Ian Collins]

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

?

 

[David Given]

On 03/03/10 13:38, Ersek, Laszlo wrote:
[...]

One point might be "screen real estate"

As a data point and some unashamed self-advertisement, I recently wrote
a word processor:

http://wordgrinder.sf.net/

I wrote this because I wanted to write text, that is, English text ---
fiction --- and I couldn't find anything I was happy with. I wanted
something with zero clutter, no extraneous distractions, with enough
features to encourage me to get the job done but not so many that it
would confuse. But I also wanted something that at least understands the
concept of paragraph and character styles, because I *am* writing text,
and I want to use *italics*, dammit.

What I wanted, in fact, was Word 5 for DOS (the last good piece of
software Microsoft wrote). In fact a lot of people have said that it
reminds them of WordStar, but I've never used that.

It runs in a terminal because that was the easiest way of getting the
I/O model I wanted. I could have given it a GUI, but why bother? ncurses
is easy to use, and superbly flexible, and these days it even supports
Unicode (WordGrinder has decent Unicode support, and makes heavy use of
Unicode line drawing to make it pretty). It also means that, if I want,
I can run it on minimal systems that don't have a windowing system,
although I haven't found a need to yet.

A couple of years ago I wrote 50000 words in 31 days on WordGrinder, on
an ASUS eee, with WordGrinder running full screen. With the status bar
turned off it meant that the *only* text on the screen was what I had
written. It was a supremely comfortable experience.

 

[Nicolas George]

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"...

I think the reason a lot of hackers still use text-mode programs is just
because they find them more ergonomic.

GUI applications have often an erratic behaviour, even with a
well-configured window manager. A lot of application think they are smarter
than the user's window manager (and, for most users, they are probably
right) and try to steal the focus, raise themselves or override their
placement. When you expect a very accurate behaviour from your windows to
achieve maximum efficiency, such nonsense is very irritating. Text mode
applications do not do any of this.

The keyboard focus inside the application is also a significant factor. If
you have a good memory and a good habit of the keyboard, keystrokes are so
much faster than using the mouse. Even with good toolkits, there are times
where the keyboard focus gets lost, and even when it does not, GUI
applications rarely optimize the keyboard navigation between widgets.

 

[Ersek, Laszlo]

Use a bigger screen!

If I do, then I'd like to spend the increased screen real estate on
*content*, not fluff. (That is, you're joking, right?)

Cheers,
lacos

 

[Ian Collins]

If I do, then I'd like to spend the increased screen real estate on
*content*, not fluff. (That is, you're joking, right?)

There is only so much content you can read! I use 24 and 30" panels and
I'm reluctant to use something like Eclipse or NetBeans on the smaller
panel, but they are OK on the larger one.

Generally I'm not that bothered whether I use emacs or NetBeans, I tend
to switch between the two depending on the job at hand.

 

[Ersek, Laszlo]

On 03/03/10 13:38, Ersek, Laszlo wrote:
[...]

One point might be "screen real estate"

As a data point and some unashamed self-advertisement, I recently wrote
a word processor:

http://wordgrinder.sf.net/

Great screen shots.

What I wanted, in fact, was Word 5 for DOS (the last good piece of
software Microsoft wrote). In fact a lot of people have said that it
reminds them of WordStar, but I've never used that.

When I saw the screen shots, I was immediately reminded of Word for DOS
-- I used to see a translator working with that, about 16 years ago.

A couple of years ago I wrote 50000 words in 31 days on WordGrinder, on
an ASUS eee, with WordGrinder running full screen. With the status bar
turned off it meant that the *only* text on the screen was what I had
written. It was a supremely comfortable experience.

Very nice. Thank you for releasing it as free software.

I can also see that WordGrinder is in Debian, starting with lenny, and
that you are its maintainer. Hats off!

Cheers,
lacos

 

[Vladimir Jovic]

if ( pointer1 != NULL &&
pointer1->field7 == 0x152 )
{
return;
}

I put the opening brace on the same line as the "if" if it fits.
If it doesn't, I put it on a line by itself, so it doesn't get lost.
It's probably not entirely consistent, but it works well for me.

Note that I also dropped some extraneous parentheses. Too many
parentheses can be as confusing as too few, and I think it's
sufficiently obvious that "==" and "!=" bind more tightly than "&&".
The alignment of the subexpressions helps.

I do not suggest that my style is the only correct one.

Yes, you missed the point. I prefer this way :

if ( NULL != pointer1 &&
0x152 == pointer1->field7 )
{
return;
}

Can save you some debugging time

 

[Casper H.S. Dik]

Yes, you missed the point. I prefer this way :

if ( NULL != pointer1 &&
0x152 == pointer1->field7 )
{
return;
}

Can save you some debugging time

But it makes the code much more difficult to read.

You're not testing that NULL now has a different value or that
0x152 has a different value.


Casper

 

[John Gordon]

When discussing vars in computing it is normal to discuss the variables
b name.

You dont say "if pi is larger than p".You say "if p is larger than
pi". You're style is nothing more than fancy for fancy's sake IMO.

No, it does actually do something: it will throw a compile error if you
mistype == as =.

To demonstrate, imagine that you intended to type this:

if (x == 7)

But you mistakenly typed this:

if (x = 7)

This is legal code but will not behave in the way you intended.

But if you had typed it this way:

if (7 = x)

The compiler will throw an error.

 

[Casper H.S. Dik]

To demonstrate, imagine that you intended to type this:

if (x == 7)

But you mistakenly typed this:

if (x = 7)

This is legal code but will not behave in the way you intended.

But if you had typed it this way:

if (7 = x)

The compiler will throw an error.

But leaves you with unreadable code.

You are using the wrong tools; proper tools will detect this.

lint:

(4) warning: assignment operator "=" found where "==" was expected

and gcc:

foo.c:4: warning: suggest parentheses around assignment used as truth value


Casper

 

[ImpalerCore]

No, it does actually do something: it will throw a compile error if you
mistype == as =.

To demonstrate, imagine that you intended to type this:

  if (x == 7)

But you mistakenly typed this:

  if (x = 7)

This is legal code but will not behave in the way you intended.

But if you had typed it this way:

  if (7 = x)

The compiler will throw an error.

I prefer readability over a marginal technique to reduce bugs.
English is meant to be read left to right, and is how I prefer to read
code, not the Yoda style '7 == x'. If the potential bug really causes
you grief, maybe pass a flag that makes the compiler flag 'x = 7' as
warnings?