Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: Tim Streater on 3 Mar 2010 04:41 On 02/03/2010 23:38, Branimir Maksimovic wrote: > Tim Streater wrote: >> >> I guess they must still be arguing and that this argument has now >> spread into c.l.c. I can't see the point of clunky keyboard-based >> editors on 24x80 little windows. A bit like paper tape and teletypes. >> Marvels in their day, or course, but museum pieces now. >> > Well you have to have some editor on server when you connect with ssh. Sure - under those conditions that's all you have. I just do that as little as possible and use something vastly better for code production. -- Tim "That the freedom of speech and debates or proceedings in Parliament ought not to be impeached or questioned in any court or place out of Parliament" Bill of Rights 1689
From: James Harris on 3 Mar 2010 04:42 On 3 Mar, 06:42, Richard Heathfield <r...(a)see.sig.invalid> wrote: > Ben Bacarisse wrote: > > <snip> > > > They were arguing about what editor *other* people should use and that > > is widely thought to be an argument that never ends. :-) > > s/widely/widely but wrongly/ > > Everybody should use vim, obviously. End of argument. For cleaning, you mean. :-) I use vi a lot but IMHO editors with multiple input modes should be consigned to museums. Perhaps a better editor interface would work something like the early versions of Wordstar. (Anyone remember Wordstar?) While cursor and other keys can be recognised on keyboards that have them the only *necessary* keys should be those that exist on all keyboards - letters, digits, symbols and the shift and control keys. The user would be always in input mode. Any non-input such as commands could be entered by control-key combinations that either carry out actions immediately or pop-up subcommand windows as needed. James
From: Richard Heathfield on 3 Mar 2010 04:53 James Harris wrote: <snip> > I use vi a lot but IMHO editors with multiple input modes should be > consigned to museums. vi has only *one* input mode. It also has *one* command mode. That's not too many to manage. > Perhaps a better editor interface would work something like the early > versions of Wordstar. (Anyone remember Wordstar?) 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. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: Curtis Dyer on 3 Mar 2010 06:33 On 02 Mar 2010, Nick Keighley <nick_keighley_nospam(a)hotmail.com> wrote: > On 2 Mar, 12:04, Curtis Dyer <dye...(a)gmail.com> wrote: >> On 24 Feb 2010, James Harris <james.harri...(a)googlemail.com> >> > On 24 Feb, 18:35, Poster Matt <postermatt(a)no_spam_for_me.org> <snip> >> Perhaps you >> mean object identifiers that have file scope? �If so, one >> crucial difference that stands out to me is that macros may not >> expand to lvalues. <snip code example> > well they can if you use them to alias an l-value > > int max_foo; > #define MAXFOO max_foo > > MAXFOO++ > > not a good idea but... Right, that's why I said, "...macros *may* not expand to lvalues." Although, I could have stated more clearly, it depends on the macro's definition. <snip> >> Another distinction is that you can't use macro identifiers >> exactly like function identifiers: >> >> � qsort(data, nitems, sizeof *data, compar); > > why not? I just don't follow you. I don't follow me, either. Unfortunately, I must have written that qsort() example too long after I wrote the paragraph above it, and missed making my own point in the process. Sorry about that. Here's a better example illustrating what I meant: /* potentially misleading macro */ #define foobar(x) \ do { \ /* ... */ \ } while (0) /* ... */ foobitize(someobject, foobar); I realize this is very contrived, but something to this effect is what I originally intended to demonstrate. <snip> -- "Don't worry about efficiency until you've attained correctness." ~ Eric Sosman, comp.lang.c
From: pete on 3 Mar 2010 06:47
io_x wrote: > > "Poster Matt" <postermatt(a)no_spam_for_me.org> ha scritto nel messaggio > news:ujehn.44277$Ym4.21796(a)text.news.virginmedia.com... > > Hi, > > > > I've a few questions concerning style > > when programming C on UNIX systems. I > > don't want to look like an amateur. :) > > all code here came from the poster "Peter Nilsson" from > news:f6245590-e586-4cb0-88f8-37afcebe15d4(a)s25g2000prd.googlegroups.com > > so you say the professional coder style > #include <string.h> > #include <stdlib.h> > > that can not be seen in my monitor editor, > here too in the editor of the news > is better than my amatorish stile > char* replace2(char *s, char *p, char *q) > {if(s==0||p==0||q==0) return 0; > return replace2_search(0, s, p, strlen(p), q, strlen(q)); > } > > that can be seen in one aye shot Real programmers typically write programs that can't all fit on a screen display. With that in mind, they write in such a way so that whatever can be displayed on a screen, is easiest to read. You personally io_x, will never write a program that can't all fit on one screen. -- pete |