ddb@mrvax.DEC (DAVID DYER-BENNET MRO1-2/L14 DTN 231-4076) (02/02/85)
I think that the second quote below may indicate where the bad "Joe-Code" that the people saw came from... Message 1: > One argument against C that I have heard A LOT is that it isn't >structured or that it's hard to program readable code in C. This is a >bunch of B*LL. The fact is that who-ever said that either does not >or has not programmed in C, or saw a bunch of Joe-Code by some-one-else >who wasn't a very good programmer. > >Path: decwrl!ucbvax!dillon Message 2: ><MILD FLAME slightly relevant to subject> >I am appalled at the consistently low quality of most of the UNIX >utility source code. Functions that run for pages and pages, few >comments, many traps like the one above just waiting for someone >to add a line of code, lint output that is longer than the source >code itself, etc, etc, etc. There may be some neat algorithms >buried in there somewhere but I am tired of wading through the >slop looking for them. If AT&T doesn't want to take the time to >clean them up why don't they commission someone to do it for them? ><FLAME OFF> > >-Fred >Path: decwrl!decvax!bellcore!allegra!ulysses!mhuxr!ihnp4!zehntel!dual!unisoft!fnf In other words, if those who write Unix utilities, surely the top level of C hackers, routinely write bad code -- maybe some sort of restrictions in the language are necessary to help people? Now, personally I haven't seen the insides of any unix stuff, not having a source license and all that. But the opinion expressed in the second message has been repeated MANY times on the net over the past year, and I've never seen it challenged with regard to unix code taken as a whole. -- David Dyer-Bennet -- ...decwrl!dec-rhea!dec-mrvax!ddb
kupfer@ucbvax.ARPA (Mike Kupfer) (02/02/85)
> In other words, if those who write Unix utilities, surely the > top level of C hackers, routinely write bad code -- maybe some sort > of restrictions in the language are necessary to help people? Restrictions in the language (at least the ones I've seen talked about in this group) aren't going to force people to comment their code, nor will it force them to use nice long mnemonic variable names, nor will it keep them from writing 10-page functions (my 3 major complaints about the Berkeley kernel). -- Mike Kupfer kupfer@Berkeley ...!ucbvax!kupfer "He says, 'Thank you very much, but you can have the bottle back.'"
arnold@ucsfcgl.UUCP (Ken Arnold%CGL) (02/02/85)
In article <4541@ucbvax.ARPA> kupfer@ucbvax.ARPA (Mike Kupfer) writes: >> In other words, if those who write Unix utilities, surely the >> top level of C hackers, routinely write bad code -- maybe some sort >> of restrictions in the language are necessary to help people? > >Restrictions in the language (at least the ones I've seen talked about >in this group) aren't going to force people to comment their code, nor >will it force them to use nice long mnemonic variable names, nor will >it keep them from writing 10-page functions (my 3 major complaints >about the Berkeley kernel). Or, as I put in "fortune" for the edification of humankind: There will never be a programming language in which it is the least bit difficult to write bad code. Also, there are a large number of readable formats for code, and forcing you to use the same one as me would annoy you out of any language. -- Ken Arnold ================================================================= Of COURSE we can implement your algorithm. We've got this Turing machine emulator...
zarth@drutx.UUCP (CovartDL) (02/05/85)
I will agree that some of the UNIX source code is rather dificult to read. On the other hand, the programs I write in C are rather easy to read. I have had people who don't even know C be able to tell me the general logic of my programs because of the STRUCTURE, small size of my routines, inteligent names for routines, variables, etc... and commenting. I believe C is like any other programming language in that it is the programmer not the language(for the most part) that makes programs complex and difficult to read. Zarth Arn
jss@sjuvax.UUCP (J. Shapiro) (02/06/85)
[Aren't you hungry...?] > Restrictions in the language (at least the ones I've seen talked about > in this group) aren't going to force people to comment their code, nor > will it force them to use nice long mnemonic variable names, nor will > it keep them from writing 10-page functions (my 3 major complaints > about the Berkeley kernel). > > Mike Kupfer > kupfer@Berkeley > ...!ucbvax!kupfer In particular, limiting the length of externals to 8 characters (or 6, or *anything*) isn't real helpful in this regard. One day I am going to teach a programming style course at Berkeley... Jon Shapiro Haverford College ..!allegra!sjuvax!jss ----------------------- Flames to /dev/null...
gino@voder.UUCP (Gino Bloch) (02/06/85)
[line saver] > Also, there are a large number of readable formats for code, and forcing > you to use the same one as me would annoy you out of any language. One problem though - my format is very readable to me, but I might not be able to read yours easily (and vice versa, of course). As a result I don't want to maintain your code (again, vice versa too - and I am speaking generically as a rhetorical device). For instance, I CANNOT, without great effort, read code in the white book style. My style is a remnant of my ALGOL days is why. -- Gene E. Bloch (...!nsc!voder!gino)
geoff@desint.UUCP (Geoff Kuenning) (02/06/85)
>In other words, if those who write Unix utilities, surely the >top level of C hackers, routinely write bad code -- maybe some sort >of restrictions in the language are necessary to help people? There is an unfortunate assumption here, and that is that the Unix utilities were written by a bunch of superprogrammers who were C experts. But in fact, the utilities show a wild variation in the abilities of their authors. Some of the code is indeed superb, but most of it is an example of how to write unreadable C. This is entirely to be expected. Bell Labs is a research organization; most people were not especially interested in writing the most maintainable code possible. Many utilities were written by someone who needed them to get a bigger job done; frequently that person did not take the time to coordinate their design decisions with the people down the hall (cf. join, cut, paste, sort, grep, uniq, and comm). Others were written as an exercise in learning C, or by people who were not full-time professional programmers. It is possible to write bad code in any language. C is perhaps more conducive to this than other languages, and perhaps could stand improvement in this area. But please don't use the Unix sources as an example of what really well-written C can look like. Contrast the recently-posted public-domain terminfo sources for a look at what a conscientious programmer produced. -- Geoff Kuenning Unix Consultant ...!ihnp4!trwrb!desint!geoff
ndiamond@watdaisy.UUCP (Norman Diamond) (02/08/85)
> [L]imiting the length of externals to 8 characters (or 6, > or *anything*) isn't real helpful in this regard. > > One day I am going to teach a programming style course at Berkeley... > > Jon Shapiro Sorry Jon, by now you probably think I'm picking on you. This is not a flame. (At least, it's not directed at you.) ..... You'll have to teach a programming style course at IBM, and DEC, and Honeywell, and AT&T Bell Labs, and all those other places who developed linkers that won't accept longer external names, and who do not upgrade their linkers to accept them. -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."
henry@utzoo.UUCP (Henry Spencer) (02/08/85)
> One day I am going to teach a programming style course at Berkeley...
A single course wouldn't suffice; you'd need a whole degree program in
Remedial Programming.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryfnf@unisoft.UUCP (Fred Fish) (02/12/85)
Gene Bloch writes: > One problem though - my format is very readable to me, but I might not > be able to read yours easily (and vice versa, of course). As a result I > don't want to maintain your code (again, vice versa too - and I am speaking > generically as a rhetorical device).... Good point Gene. What would really help is a "trainable" C beautifier. I would train it to my style by feeding it lots of my programs, run yours through it, and presto ... now I have your code in my style. When I'm done with it, you do the reverse and we're both happy. And while we're at it, how about a "cdiff" program that compares programs at the parse tree level so that comment changes, variable renamings, etc get ignored. Now I can make all sorts of improvements (from my point of view :-) to your N line program without having diff spit out 2N lines of changes. Gee, I just gave away two good ideas for a commercial product ... argh!
bsa@ncoast.UUCP (Brandon Allbery) (02/12/85)
> Article <4541@ucbvax.ARPA>, from kupfer@ucbvax.ARPA (Mike Kupfer) +---------------- | > In other words, if those who write Unix utilities, surely the | > top level of C hackers, routinely write bad code -- maybe some sort | > of restrictions in the language are necessary to help people? | | Restrictions in the language (at least the ones I've seen talked about | in this group) aren't going to force people to comment their code, nor | will it force them to use nice long mnemonic variable names, nor will ---------------------------------^ IDENTIFIER TOO LONG | it keep them from writing 10-page functions (my 3 major complaints | about the Berkeley kernel). PLEASE try to remember that not all of us run Berkeley Unix, and not all of us can *afford* to run Berkeley Unix. Our compiler routinely chokes on long identifiers in Berzerker programs. Long is OK, IF YOU KEEP THEM DISTINCT WITHIN SOME NUMBER OF CHARACTERS -- the minimum being 6, and 7 to be compatible with v7 sites (8, - 1 for the _ prepended by the compiler). Brandon (bsa@ncoast.UUCP) -- Brandon Allbery, decvax!cwruecmp!ncoast!bsa, "ncoast!bsa"@case.csnet (etc.) 6504 Chestnut Road, Independence, Ohio 44131 +1 216 524 1416 (or what have you)
robert@gitpyr.UUCP (Robert Viduya) (02/16/85)
>< Posted from bsa@ncoast.UUCP (Brandon Allbery) > PLEASE try to remember that not all of us run Berkeley Unix, and not > all of us can *afford* to run Berkeley Unix. Our compiler routinely > chokes on long identifiers in Berzerker programs. > I was browsing through the System V Release 2.0 Programming Guide last night and they say that an the C compiler for Vax-11 and their 3B20 both support external name sizes of ">100 characters, 2 cases". So it isn't just Berkeley that supports long identifiers. robert -- Robert Viduya Georgia Institute of Technology ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
guy@rlgvax.UUCP (Guy Harris) (02/16/85)
> PLEASE try to remember that not all of us run Berkeley Unix, and not > all of us can *afford* to run Berkeley Unix. Our compiler routinely > chokes on long identifiers in Berzerker programs. Now that System V Release 2 also supports long variable names (and hooray for that!), this warning should be reiterated - long variable names are *very* nice, but if you want your software to run on most of the UNIX machines out there, keep them unique in the first 6 characters. On the PDP-11, even S5R2 has the 7-character limitation. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy