another bizarre architecture
in [Embedded]
|
From: Jan Panteltje on 3 Feb 2007 06:38 On a sunny day (Fri, 02 Feb 2007 13:55:44 -0800) it happened John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in <4jc7s2tpog8hqspdtiheutef8r00g6q618(a)4ax.com>: >>So? > >So clean, safe, documented, bug-free code is routinely produced when >it matters. But a premise is that the people who create the code first >have to believe that clean, bug-free code is possible, and then they >have to pragmatically adopt the engineering disciplines needed to make >it so. > >It helps if they have never studied CS, and that jet engines are not >abstractions to them. > >John I can agree with that, but it gives me that sales people feeling. There was the NASA PC soft for the mars rovers, it was written in Java IIRC, and it had a 3D verison for on the PC for Linux. I installed it, and it 1) did not install (path was wrong and hardcoded IIRC), 2) got stuck after fixing that. I realized something that moment I looked at that code, and I made the statement in sci.astro, that if the same people programmed the_real_ rover, then it would be in serious problems. Of course it _WAS_ in serious problems when its directory structure filled up with too many files a week later.... (IIRC). They fixed it remotely (relief). I can feel that signature of disaster programming from just a quick look it seems. So, if you can do it, very good. But some still have a learning curve to take.
From: CBFalconer on 3 Feb 2007 06:02 Jan Panteltje wrote: > <cbfalconer(a)yahoo.com> wrote: > >> There is no need to use those continuation lines, which just >> distort your code. A '\n' is just another whitespace char. to a C >> compiler. In addition strings separated by only whitespace are >> automatically concatenated. You can be much clearer with: > > There is a problem with that, in case of text, consider this on gcc3.3: > > Try this, > #include <stdio.h> > > main() > { > fprintf(stderr, > "Hello\n > World\n"); > } You have failed to supply the closing quotes, i.e.: fprintf(stderr, "Hello\n" "World\n"); Please snip useless portions. The practice of topposting something that has a selected quote is ridiculous. Snip the irrelevant portions of the quote. -- <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt> "A man who is right every time is not likely to do very much." -- Francis Crick, co-discover of DNA "There is nothing more amazing than stupidity in action." -- Thomas Matthews
From: Jan Panteltje on 3 Feb 2007 09:07 On a sunny day (Sat, 03 Feb 2007 06:02:12 -0500) it happened CBFalconer <cbfalconer(a)yahoo.com> wrote in <45C46BB4.907620EB(a)yahoo.com>: >Jan Panteltje wrote: >> <cbfalconer(a)yahoo.com> wrote: >> >>> There is no need to use those continuation lines, which just >>> distort your code. A '\n' is just another whitespace char. to a C >>> compiler. In addition strings separated by only whitespace are >>> automatically concatenated. You can be much clearer with: >> >> There is a problem with that, in case of text, consider this on gcc3.3: >> >> Try this, >> #include <stdio.h> >> >> main() >> { >> fprintf(stderr, >> "Hello\n >> World\n"); >> } > >You have failed to supply the closing quotes, i.e.: > > fprintf(stderr, "Hello\n" > "World\n"); > >Please snip useless portions. The practice of topposting something >that has a selected quote is ridiculous. Snip the irrelevant >portions of the quote. Take your pills
From: CBFalconer on 3 Feb 2007 10:56 Jan Panteltje wrote: > .... snip ... > >> You have failed to supply the closing quotes, i.e.: >> >> fprintf(stderr, "Hello\n" >> "World\n"); >> >> Please snip useless portions. The practice of topposting something >> that has a selected quote is ridiculous. Snip the irrelevant >> portions of the quote. > > Take your pills PLONK. -- <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt> "A man who is right every time is not likely to do very much." -- Francis Crick, co-discover of DNA "There is nothing more amazing than stupidity in action." -- Thomas Matthews
From: Robert Adsett on 3 Feb 2007 17:54
In article <eq1re6$odg$1(a)news.datemas.de>, Jan Panteltje says... > On a sunny day (Fri, 2 Feb 2007 17:57:30 -0500) it happened Robert Adsett > <sub2(a)aeolusdevelopment.com> wrote in > <45c3b541$0$16384$88260bb3(a)free.teranews.com>: > > >In article <epv7ja$jea$1(a)news.datemas.de>, Jan Panteltje says... > >> On a sunny day (Thu, 1 Feb 2007 20:38:15 -0500) it happened Robert Adsett > >> <sub2(a)aeolusdevelopment.com> wrote in > >> <45c2896a$0$16406$88260bb3(a)free.teranews.com>: > >> > >> >I use C, it's now probably my 'mother tongue' for programming and I > >> >have to agree with John on this. The comments are too sparse and > >> >worse in the one other function I looked at (to see if more complex > >> >functions were done better), the file header comment was completely > >> >wrong. It's the sort of file where if you already know what's > >> >happening and what it's supposed to do you can follow it but if you > >> >are new to it or have been away for a long enough period to have > >> >forgotten then you will be in for a hard time. The functions assume a > >> >lot of knowledge that is not in the files and there are no pointers > >> >external references containing the missing information. > >> > > >> >Robert > >> > >> I agree that more comments helps. > >> But in spite of that, a deeper knowledge of the various interconnects > >> is required, that cannot be put even in several pages of text (and who > >> would read these). > > > >Before interactions get that complex I'm usually questioning the > >approach. If the interconnects are that complex they really do need to > >be documented. > > > >However, that didn't even approach being an issue in the given example. > >It could have been raised to adequate commenting level with only a few > >comments (2 or 3 lines). Something to indicate what the function was > >supposed to do, some to document arguments/return and maybe a quick line > >outlining the main loop. > > > >As I said the other example I looked at from the same page was even > >worse, even the file header was completely wrong. This should just be > >basic code hygiene. John's original comments were correct and the > >response that he should just learn C was off the mark. The issue wan't > >a language issue but inadequate commenting. The original routine he was > >pointed to was quite straightforward, not a lot in the way of > >interconnects requiring a lot of 'deeper knowledge', but the commenting > >practice appears to extend beyond it, consistent with the view that if > >you don't handle the simple cases properly it's unlikely the more > >complex ones will be handled correctly. It's basic discipline. > > > >Robert > > No, the code rules (always) because that is what the processor ultimately > executes. > Up until this day at least, processors do not read books. So what? Comments aren't executed. Comments are for conveying to the human reader the reasons for the instructions used. Justifications for decisions taken, limitations of the routine/approach. To let the reader know what is supposed to happen and how ro use the routines in question. Sometimes the explanation will, of course, be too involved to include in the comments in its entirety and in that case they may refer to external references such as standards texts and of course lab book derivations. > So, many funny comments have been written, and sometimes not releated to what > a function does at all. And banks are robbed. Theft is however, still illegal. Just because people don't take the discipline to do something properly does not mean it should not be done. And I don't intend to hold myself up as a paragon of virtue in that regard either, part of the discipline of programming is continually correcting bad habits. And comments must be maintained just as the code does. A source code file more nearly resembles a schematic than it resembles a layout. It's at least as much about communicating intent to the human as it is about communicating to the compiler. > I understand and appreciate your post, but in the simple example that John gave > the C code says it all, at least for me, so I even skip the comments. So can I. That doesn't mean they shouldn't be there. And part of his complaint as well as a big part of mine is that the larger more complex functions are even worse. As an example the header in one file contains the following * FILE: lib/crtdll/conio/kbhit.c * PURPOSE: Checks for keyboard hits And the first function starts as int fflush(FILE *f) Now either they've used very bad practice and fflush check for keyboard hits, or the header is completely at odds with the body. It would be laughable it it weren't tragic. If it were an isolated case it could be just a simple error and would hardly be worth this complaint, although it should still be corrected. It is not isolated though. <snip> > So, I am not shy with comments :-) I'm not saying you are. Just that the commenting in the example John was given was poor. Unfortunately it appears the other examples on the same site are worse. Not much wonder John dislikes C if that's what he's got to go on. Robert -- Posted via a free Usenet account from http://www.teranews.com |