Source code isn't executed, either. A computer program is an interface between a human programmer and two destinations: downward, to the instruction set of a CPU: upward, to the author himself and to other programmers who need to understand, now and in the future, what is being done and why. The code tells what is being done, and the comments tell why.
The very act of commenting forces a programmer to explain the program to himself, sometimes with novel results.
It's shocking how many programmers and CS teachers don't understand this, or do and can't be bothered.
gave
Skipping comments is reasonable if what's going on is totally obvious, like a nicely-contained Linux file operation. But an embedded systen connects to real-world hardware external to the cozy world of computer languages and operating systems, so some context can be mighty helpful.
I dislike the language because I think it's ugly, but that's a personal affectation. I dislike the culture of C because it so often creates crap products. Fortunately, roughly half of C code, the really bad stuff, never makes it to the street; the projects, or the companies, fail.
You're right although I was referring to the larger sense in which source code does describe the instructions to the micro wheras comments are solely for human consumption :)
Those with a CS inheritance aren't the only ones, just the ones with the least excuse.
gave
I'm not sure I completely agree. The commenting can be a lot lighter though if you can refer to a well defined definition. As you can for much of the standard library.
Indeed, especially since some people have been known to produce functions that look like the standard functions but are either incomplete or behave slightly differently. (maybe we can call those homonym functions?)
I can't fault you for the results reasoning although I suspect that has as much or more to do with it's popularity than anything inherit in it. I've seen similar with C++ and Java at the very least.
Robert
--
Posted via a free Usenet account from http://www.teranews.com
I did not realize this was not a common truth/practice for all programmers nowadays until not so long ago...
Not that one cannot comment each line (or few characters...) in C, Basic or whatever, but HLLs are designed following a "no comment necessary" ideology, which is a major weakness they all have. Obviously trying to communicate a software project without using English is doomed; so people do use some minimized comments, which results in minimized code quality. Other than in HLLs, writing comments using 68k (and perhaps some others in this particular context) assembler is a de facto part of the language, not a result of discipline.
On a sunny day (Sat, 3 Feb 2007 17:54:47 -0500) it happened Robert Adsett wrote in :
You are partly right in my view. If I buy a book in English (I am Dutch), can I require that plent of Ducth lines are inserted so I can read it if my English is broken?
If you are going to do some reading of C files, do you not think you should _AT_LEAST_ be able to read the language fluently? Even more when writing in C. C, written in the right way, other then if cryptic use of variables and functions in made, is very readable. I have worked myself throught tons of sourcefiles that had zero comments, something you learn when using open source..... Sometimes comments just distract.
The reliability of teranews (I once payed for lifetime access to it) is such that I stay clear of it.
While people do work that way, I don't think any HLLs have been designed that way.
Well, I think maybe English is necessary if you are communicating with English readers ;)
Now her I'll disagree. I've certainly seen uncommented and poorly commented assembly code. No assembler I've seen encouraged comments any more than most HLLs.
The prevalance of commenting, especially meaningful commenting, appears to have to do far more with the people writing the code than the language they are using to write it. The exception might be graphical languages which in my limited experience do not seem to have developed clear commenting techniques.
Robert
--
Posted via a free Usenet account from http://www.teranews.com
In case of read() there is an other problem, that the higher level 'fread()' protected us from, and a frequent make mistake is not to call read() again if it returns EAGAIN (and lose data), from libc.info:
- Function: ssize_t read (int FILEDES, void *BUFFER, size_t SIZE) The ead' function reads up to SIZE bytes from the file with descriptor FILEDES, storing the results in the BUFFER. (This is not necessarily a character string, and no terminating null character is added.)
The return value is the number of bytes actually read. This might be less than SIZE; for example, if there aren't that many bytes left in the file or if there aren't that many bytes immediately available. The exact behavior depends on what kind of file it is. Note that reading less than SIZE bytes is not an error.
A value of zero indicates end-of-file (except if the value of the SIZE argument is also zero). This is not considered an error. If you keep calling ead' while at end-of-file, it will keep returning zero and doing nothing else.
If ead' returns at least one character, there is no way you can tell whether end-of-file was reached. But if you did reach the end, the next read will return zero.
In case of an error, ead' returns -1. The following rrno' error conditions are defined for this function:
AGAIN' Normally, when no input is immediately available, ead' waits for some input. But if the NONBLOCK' flag is set for the file (*note File Status Flags::), ead' returns immediately without reading any data, and reports this error.
*Compatibility Note:* Most versions of BSD Unix use a different error code for this: WOULDBLOCK'. In the GNU library, WOULDBLOCK' is an alias for AGAIN', so it doesn't matter which name you use.
On some systems, reading a large amount of data from a kernel cannot find enough physical memory to lock down the user's pages. This is limited to devices that transfer with direct memory access into the user's memory, which means it does not include terminals, since they always use separate buffers inside the kernel. This problem never happens in the GNU system.
Any condition that could result in AGAIN' can instead result in a successful ead' which returns fewer bytes than requested. Calling ead' again immediately would result in AGAIN'.
BADF' The FILEDES argument is not a valid file descriptor, or is not open for reading.
INTR' ead' was interrupted by a signal while it was waiting for input. *Note Interrupted Primitives::. A signal will not necessary cause ead' to return INTR'; it may instead result in a successful ead' which returns fewer bytes than requested.
IO' For many devices, and for disk files, this error code indicates a hardware error.
IO' also occurs when a background process tries to read from the controlling terminal, and the normal action of stopping the process by sending it a IGTTIN' signal isn't working. This might happen if the signal is being blocked or ignored, or because the process group is orphaned. *Note Job Control::, for more information about job control, and *Note Signal Handling::, for information about signals.
Please note that there is no function named ead64'. This is not necessary since this function does not directly modify or handle the possibly wide file offset. Since the kernel handles this state internally, the ead' function can be used for all cases.
This function is a cancellation point in multi-threaded programs. This is a problem if the thread allocates some resources (like memory, file descriptors, semaphores or whatever) at the time ead' is called. If the thread gets cancelled these resources stay allocated until the program ends. To avoid this, calls to ead' should be protected using cancellation handlers.
The ead' function is the underlying primitive for all of the functions that read from streams, such as getc'.
This is a bit out of context for these newsgroups, and more for comp dot os dot linux dot development dot apps and related.
Perhaps this explains much of the difference; hardware designers like to design, but due to the discipline forced upon us by the task, we ojnly design new subsystems *when we must*.
When we need a function that already exists (whether from elsewhere or our own library) , there has to be a compelling reason not to use it, in contrast with the comment above where programmers will re-invent it almost every time with all the attendant issues of something new.
Commenting code *properly* requires a certain discipline. I comment my code as accurately as possible (and reference the original requirement if possible) for many reasons, not least when I go back to it in 6-12 months and wonder why the F*** I did something.
Proper comments in code are a requirement for proper development just as proper documentation in hardware design is necessary.
The fact that many lack discipline in no way changes the requirement.
And because of the cost and turnaround time of an assembly, we check our work carefully before we commit it to copper. Software, because it can be changed in minutes, without making pads fall off boards, usually doesn't get checked at all before it's run. So the bugs you fix are the bugs you find.
I like to design new circuits, but that increases the obligation to check/breadboard/simulate them before commiting them to layout.
Precisely. Rather than finding the bugs that exist.
I love to design new things, but I must minimise risk as must you. So I design the new stuff (and have great fun doing it) while re-using as much as I can for the boring 'already done this' stuff.
This might need to be a new thread: Why hardware designers have more discipline and fewer bugs.
That can be made to work well in embedded systems, i have seen them that do it that way, i have even written some very small ones. It does not work well when there are a multitude of programs that run frequently to rarely in response to any of several users discretion. YMMV
--
JosephKK
Gegen dummheit kampfen die Gotter Selbst, vergebens.
--Schiller
John, this is comp.arch.embedded - the answer is *always* "it depends". For some products, it is vital to hit the schedule - even if there are known bugs or problems. Perhaps you ship the hardware now, and upgrade the software later - perhaps you ship the whole thing even with its outstanding problems. For other products, you have to set the highest possible standards, and quality cannot be lowered for any purpose. I have no idea what sort of systems VV works with - they could well be of the sort where issues such as cost and timing are more important than quality and reliability.
Gov'ts subsidize , so they dont need to compete , so they make errors . But the world has ARM competition , forcing ARM to give more performance , thus ARM will beat out all mcu/cpu in the next 4 years . MicroChip-PIC , Zilog , Intel , will all be history . Im not saying i approve , im saying its way too powerful for any detours or surprises . so if you talk 8051 or PIC , you wont have anyone to talk to , in the future .
Im doin free software . Tiny Op System that loads and assembles and debugs , all in 10K B8s . I redefined Bytes and bits ! .... dont use U.C. nor L.C. use only U.C. and place an 8 as suffix , to mean bytes .
Bytes = B8 , 32bits is B32 ... bit number 1 thru 7 is [B1...B7] [B1-B7] [B1-7] . B32.6 is the 6th bit . B32.6H is bit #6 = High B32.6 GTE B32.2 "GreaterThanEqual"
My free OpSys , will not use text , one can program it from softkeys , in seconds . You learn it by displaying and dumping RAM and registers , but images , not text . The first image shows where each key is , that you press , and what code frags , it links and makes them pulse and throb as synapses in human brain do .
People will be forced to use it , because it clears up everything in the software .
Anyone interested in joining ? for starts . ill call it ForthRite ( a forth right method ). If it is tiny , elegant , highly structured and intuitive , it may have a place in ForthRite ......and free to the public. Since it has only images , it will be self Documenting .
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.