Re: [OT?] Coding Style
> >> Then there is reasability. >> >> void ThisIsMyDumbassFunctionName >> so how many times have you typed something like ThisIsMyDumbAssFunctionName instead of ThisIsMyDumbassFunctionName >> if MUCH more difficult to read than >> >> void this_is_my_clear_and_easy_function_name > >I can certainly read the first easier than the second. > >MfG Kai -- - Check Out: http://stev.org E-Mail: [EMAIL PROTECTED] 12:10am up 10 days, 7:31, 4 users, load average: 0.16, 0.04, 0.10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Then there is reasability. void ThisIsMyDumbassFunctionName so how many times have you typed something like ThisIsMyDumbAssFunctionName instead of ThisIsMyDumbassFunctionName if MUCH more difficult to read than void this_is_my_clear_and_easy_function_name I can certainly read the first easier than the second. MfG Kai -- - Check Out: http://stev.org E-Mail: [EMAIL PROTECTED] 12:10am up 10 days, 7:31, 4 users, load average: 0.16, 0.04, 0.10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
[EMAIL PROTECTED] (Kai Henningsen) writes: > > void ThisIsMyDumbassFunctionName > > > > if MUCH more difficult to read than > > > > void this_is_my_clear_and_easy_function_name > > I can certainly read the first easier than the second. So I assume you don't approve of the new German spelling standard, where nouns with capital letters are optional (don't know if it became reality, I remember reading that Günther Grass was against it). For a Norwegian, the second variant is much more readable. -- Harald Arnesen, Apalløkkveien 23 A, N-0956 Oslo, Norway - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
[EMAIL PROTECTED] (Mike Harrold) wrote on 23.01.01 in <[EMAIL PROTECTED]>: > > I prefer descriptive variable and function names - like comments, they > > help to make code so much easier to read. > > > > One thing I wonder though... why do people prefer 'some_function_name()' > > over 'SomeFunctionName()'? I personally don't like the underscore > > character - it's an odd character to type when you're trying to get the > > name typed in, and the shifted character, I find, is easier to input. > > > > For exactly the reverse of that reason. Typing capital letters is a heck > of a lot more difficult that addint an underscore. (shift)+(-_) is a lot more more difficult than (shift)+(A)? Or do you have a keyboard layout where _ is not a shifted key? > Then there is reasability. > > void ThisIsMyDumbassFunctionName > > if MUCH more difficult to read than > > void this_is_my_clear_and_easy_function_name I can certainly read the first easier than the second. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
[EMAIL PROTECTED] (Steve Underwood) wrote on 24.01.01 in <[EMAIL PROTECTED]>: > Unfortunately the C standards people don't seem to realise there are > languages other than English. C99 had perfect timing to introduce UTF8 > Unicode as acceptable in C source. Alas they missed the boat. I have > been embedding Chinese in C source for years (mostly Big-5 - UTF8 is > more likely to be troublesome with existing compilers), and have yet to > hit a significant problem. It isn't standards compliant, though. Have you *READ* the C99 standard? According to my copy of ISO/IEC 9899:1999, chinese characters in identifiers are quite legal. And the source is not defined to be UTF8 because C has never defined the source to be any specific character set; if your character set does not include the right characters, use \u or \U. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
[EMAIL PROTECTED] (John Kodis) wrote on 23.01.01 in <[EMAIL PROTECTED]>: > On Tue, Jan 23, 2001 at 10:41:49AM -0500, Jonathan Earle wrote: > > > One thing I wonder though... why do people prefer 'some_function_name()' > > over 'SomeFunctionName()'? > > i_would_assume_that_it_is_because_the_underscore_serves_the_same_word- > seperation_role_that_a_space_does_in_normal_prose. RunningWordsAll > Together(OrShouldISay"ToGetHer"ForMaximumStudlyness)JustDoesNotParseAs > Readily, and that, rather that ease of typing is what counts. Nice example: the underscore part was in fact *much* harder to read for me. The second part read nearly exactly like normally spaced text. Maybe there is something to the thesis that it depends on what people are accustomed to: English uses far less capital letters than German, and I certainly prefer the German capitalization style. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
[EMAIL PROTECTED] (Mike Harrold) wrote on 23.01.01 in [EMAIL PROTECTED]: I prefer descriptive variable and function names - like comments, they help to make code so much easier to read. One thing I wonder though... why do people prefer 'some_function_name()' over 'SomeFunctionName()'? I personally don't like the underscore character - it's an odd character to type when you're trying to get the name typed in, and the shifted character, I find, is easier to input. For exactly the reverse of that reason. Typing capital letters is a heck of a lot more difficult that addint an underscore. (shift)+(-_) is a lot more more difficult than (shift)+(A)? Or do you have a keyboard layout where _ is not a shifted key? Then there is reasability. void ThisIsMyDumbassFunctionName if MUCH more difficult to read than void this_is_my_clear_and_easy_function_name I can certainly read the first easier than the second. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
[EMAIL PROTECTED] (Steve Underwood) wrote on 24.01.01 in [EMAIL PROTECTED]: Unfortunately the C standards people don't seem to realise there are languages other than English. C99 had perfect timing to introduce UTF8 Unicode as acceptable in C source. Alas they missed the boat. I have been embedding Chinese in C source for years (mostly Big-5 - UTF8 is more likely to be troublesome with existing compilers), and have yet to hit a significant problem. It isn't standards compliant, though. Have you *READ* the C99 standard? According to my copy of ISO/IEC 9899:1999, chinese characters in identifiers are quite legal. And the source is not defined to be UTF8 because C has never defined the source to be any specific character set; if your character set does not include the right characters, use \u or \U. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
[EMAIL PROTECTED] (Kai Henningsen) writes: void ThisIsMyDumbassFunctionName if MUCH more difficult to read than void this_is_my_clear_and_easy_function_name I can certainly read the first easier than the second. So I assume you don't approve of the new German spelling standard, where nouns with capital letters are optional (don't know if it became reality, I remember reading that Gnther Grass was against it). For a Norwegian, the second variant is much more readable. -- Harald Arnesen, Apallkkveien 23 A, N-0956 Oslo, Norway - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Apologies first... Would someone send me a way to filter mail? I REALLY DO NOT GIVE A RATS ARSE ABOUT THIS OT!! Like it or Leave it but whinning about it SUX! Regard, Cheif Whinner! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
> Too bad we can't just do a "Prince" and invent unpronouncable symbols to > use as function names... or perhaps just use something from the chinese > fonts ;o)... Sorry. You'll need to use Java if you want to use Unicode source. Brent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Unfortunately the C standards people don't seem to realise there are languages other than English. C99 had perfect timing to introduce UTF8 Unicode as acceptable in C source. Alas they missed the boat. I have been embedding Chinese in C source for years (mostly Big-5 - UTF8 is more likely to be troublesome with existing compilers), and have yet to hit a significant problem. It isn't standards compliant, though. Regards, Steve Joe deBlaquiere wrote: > > Too bad we can't just do a "Prince" and invent unpronouncable symbols to > use as function names... or perhaps just use something from the chinese > fonts ;o)... > > Mike Harrold wrote: > > >> This message is in MIME format. Since your mail reader does not understand > >> this format, some or all of this message may not be legible. > >> > >> --_=_NextPart_001_01C08552.FFC336D0 > >> Content-Type: text/plain; > >> charset="ISO-8859-1" > >> > >> I prefer descriptive variable and function names - like comments, they help > >> to make code so much easier to read. > >> > >> One thing I wonder though... why do people prefer 'some_function_name()' > >> over 'SomeFunctionName()'? I personally don't like the underscore character > >> - it's an odd character to type when you're trying to get the name typed in, > >> and the shifted character, I find, is easier to input. > >> > > > > > > For exactly the reverse of that reason. Typing capital letters is a heck > > of a lot more difficult that addint an underscore. > > > > Then there is reasability. > > > > void ThisIsMyDumbassFunctionName > > > > if MUCH more difficult to read than > > > > void this_is_my_clear_and_easy_function_name - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [OT?] Coding Style
At 10:47 AM 1/23/01 -0600, Jesse Pollard wrote: >Code is written by the few. >Code is read by the many, and having _ in there makes it MUCH easier to >read. Visual comparison of "SomeFunctionName" and "some_function_name" >is faster even for a coder where there may be a typo (try dropping a >character) >or mis identifing two different symbols with similar names: > > d_hash_mask > d_hash_shift > >This is relatively easy to read. conversely: > > DHashMask > DHashShift > >Are more difficult to spot. Depends on what you are used to. I'm used to both, being both an old-world C programmer from the very beginning (where underscore was the preferred way) and also a Pascal programmer (where the mixed-case form was the preferred way). Remember a language where dollar signs broke up words? But then again, one reason I'm so fond of structures is that you can get away from the whole thing by being able to read d.hash.mask d.hash.shift (It's really too bad that you can't have structured enum constants, isn't it?) By the way, just so everyone hates me, I would tend to key the above two names as DHash_mask DHash_shift so that, as another person has commented, you identify the class of a variable and the specifics as easily identifiable entities. That assumes that your "class" names are sufficiently different that a mis-key will be caught by that master of book-keeping, the compiler. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [OT?] Coding Style
That's just nasty! Funny, but nasty. :) Jon > -Original Message- > From: Stephen Satchell [mailto:[EMAIL PROTECTED]] > It took a while to prepare the source for this jerk. Here is > what I did to > the source I gave the guy: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
I am not sure about Linux IDEs, but when I programmed Objective-C using the OpenStep IDE, you could not only do auto-completion on those, but on any word that had been previously used. That was cool, and didn't cause wacky problems like you might think it would (auto-completing words like the, to, for, etc when trying to type something else). JBuilder comes close, so I am guessing the Klyx will also. I sent an email suggestion to Inprise, excuse me..Borland, on the subject last year. They seemed to like it. jk At 01:05 PM 1/23/01 -0500, Christopher Friesen wrote: >This is why the autocompletion of functions and struct members in VC++ is >awfully nice...hit the first few unique letters and it will complete the >rest of >the function for you, then hit tab and keep going. Is there anything with >that >functionality under Linux? > >Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
> "CF" == Christopher Friesen <[EMAIL PROTECTED]> writes: CF> This is why the autocompletion of functions and struct members in CF> VC++ is awfully nice...hit the first few unique letters and it CF> will complete the rest of the function for you, then hit tab and CF> keep going. Is there anything with that functionality under CF> Linux? Yup. Emacs users can use the mis-named dynamic abbreviation function (daddrev-expand which I have mapped to M-/). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Tue, 23 Jan 2001, Helge Hafting wrote: > Stephen Satchell wrote: > > [lots of good advice deleted] > > One goal of language designers is to REMOVE the need for comments. With a > > good fourth-generation or fifth-generation language, the need for comments > > diminishes to a detailed description of the data sets and any highly > > unusual operations or transforms on the data. > > This is but a dream. You can't "design out" the need for comments by > approaching natural language. Try reading a law book and realize that > natural language too may be twisted to the extent that it needs > extensive comments. The same goes for any computer language powerful > enough to do useful work. Actually using natural language and other such constructs may INCREASE the need for comments. For more examples, see Perl. [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
[EMAIL PROTECTED] ("Christopher Friesen") writes:
> Georg Nikodym wrote:
>
> > I think that the distinction is moot and this argument a waste of
> > time. If you are anything more than a code tourist, you should have
> > no trouble dealing with mnemonic names. So the above can become:
> >
> > /*
> > * timcaefn == this is my clear and easy function name
> > */
> > void timcaefn (void);
> >
> > If you're at all concerned about RSI, your fingers will thank you.
>
> This is why the autocompletion of functions and struct members in VC++ is
> awfully nice...hit the first few unique letters and it will complete the rest of
> the function for you, then hit tab and keep going. Is there anything with that
> functionality under Linux?
Esc-/ under emacs...
--
Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED]
Learning French is trivial: the word for horse is cheval, and
everything else follows in the same way.
-- Alan J. Perlis
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Georg Nikodym wrote: > I think that the distinction is moot and this argument a waste of > time. If you are anything more than a code tourist, you should have > no trouble dealing with mnemonic names. So the above can become: > > /* > * timcaefn == this is my clear and easy function name > */ > void timcaefn (void); > > If you're at all concerned about RSI, your fingers will thank you. This is why the autocompletion of functions and struct members in VC++ is awfully nice...hit the first few unique letters and it will complete the rest of the function for you, then hit tab and keep going. Is there anything with that functionality under Linux? Chris -- Chris Friesen| MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
At 08:28 PM 1/23/01 +0800, Steve Underwood wrote: >During a period of making a liveing out of >sorting out severly screwed up projects I made a little comment >stripper. I found comments so unreliable, and so seldom useful, I was >better off reading the code without the confusion they might cause. I >do, however, try to document the non-obvious through comments in what I >write. Ditto. Mine had the option of leaving the block comments in place (line count was a parameter) because the block comments proved to be more useful than the in-line comments. >Some people still seem to be living in the age of K C, with 6 or 7 >character variable names that demand some explanation. Maybe some day >they will awake to the expressive power of long (and well chosen) names. Actually, they are still living as though the KSR-33 and ASR-33 teletypes were the only input device. :) True story: I was retained to solve a particular problem for a company over a one-year time period. I wrote some rather nifty code to solve the problem, and was happily doing data extraction and conversion for that time period. Then there was a management turnover at the client and the new guy decided to implement a cost-cutting measure: cut out as many outsiders as possible. He decided that I should give him the code I had developed over the year (that wasn't part of the contract, of course) so that he could have in-house people do it. Not just executable programs, of course. "We bought the development of that code, so we deserve the source." The bastard backed up the demand with his lawyer. Not wanting to spend the money on the threatened lawsuit, I gave him exactly what he asked for: the source to the latest working version of the programs I wrote to do the job. It took a while to prepare the source for this jerk. Here is what I did to the source I gave the guy: 1) Used the output of CPP, which stripped out all include files and strips all comments. This had the interesting side effect of making the source compiler-dependent. 2) Stripped all newlines, and converted strings of spaces and tabs not in quotes to a single space. This made the source one line long...a VERY LONG line. 3) Converted each reasonable variable name to a string of seven random characters from the set [A-Aa-z0-9_], with the first character restricted to [A-Za-z]. A list of #define statements equated the random name to the proper library name or symbol. (Because the names included a number of internal variables in the compiler library, this was a HUGE list.) The resulting symbol table was so large that I had to use disk to keep all the names. Inadvertently I had also randomized lexical elements such as "for", "while" and so forth, but #define statements took care of that problem. 4) Determined that the output of the compiler with the mangled source was exactly the same as the output of the compiler with the original source. As you can guess, I discovered a few bugs with the compiler I was using. The compiler writer (who was just down the road) was highly amused with this and asked if they could "borrow" my mangler "for test purposes." (Just who do they think they were kiddin'?) Satch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Tue, Jan 23, 2001 at 10:41:49AM -0500, Jonathan Earle wrote: > One thing I wonder though... why do people prefer 'some_function_name()' > over 'SomeFunctionName()'? i_would_assume_that_it_is_because_the_underscore_serves_the_same_word- seperation_role_that_a_space_does_in_normal_prose. RunningWordsAll Together(OrShouldISay"ToGetHer"ForMaximumStudlyness)JustDoesNotParseAs Readily, and that, rather that ease of typing is what counts. -- John Kodis <[EMAIL PROTECTED]> Phone: 301-286-7376 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [OT?] Coding Style
"Jonathan Earle" <[EMAIL PROTECTED]>: > I prefer descriptive variable and function names - like comments, they help > to make code so much easier to read. > > One thing I wonder though... why do people prefer 'some_function_name()' > over 'SomeFunctionName()'? I personally don't like the underscore character > - it's an odd character to type when you're trying to get the name typed in, > and the shifted character, I find, is easier to input. Code is written by the few. Code is read by the many, and having _ in there makes it MUCH easier to read. Visual comparison of "SomeFunctionName" and "some_function_name" is faster even for a coder where there may be a typo (try dropping a character) or mis identifing two different symbols with similar names: d_hash_mask d_hash_shift This is relatively easy to read. conversely: DHashMask DHashShift Are more difficult to spot. In this case "The good of the many outweigh the good of the few". - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Too bad we can't just do a "Prince" and invent unpronouncable symbols to use as function names... or perhaps just use something from the chinese fonts ;o)... Mike Harrold wrote: >> This message is in MIME format. Since your mail reader does not understand >> this format, some or all of this message may not be legible. >> >> --_=_NextPart_001_01C08552.FFC336D0 >> Content-Type: text/plain; >> charset="ISO-8859-1" >> >> I prefer descriptive variable and function names - like comments, they help >> to make code so much easier to read. >> >> One thing I wonder though... why do people prefer 'some_function_name()' >> over 'SomeFunctionName()'? I personally don't like the underscore character >> - it's an odd character to type when you're trying to get the name typed in, >> and the shifted character, I find, is easier to input. >> > > > For exactly the reverse of that reason. Typing capital letters is a heck > of a lot more difficult that addint an underscore. > > Then there is reasability. > > void ThisIsMyDumbassFunctionName > > if MUCH more difficult to read than > > void this_is_my_clear_and_easy_function_name > > Regards, > > /Mike > > >> Cheers! >> Jon >> >> >>> -Original Message- >>> From: Steve Underwood [mailto:[EMAIL PROTECTED]] >> >> Some people still seem to be living in the age of K C, with 6 or 7 >> character variable names that demand some explanation. Maybe some day >> they will awake to the expressive power of long (and well chosen) names. >> >> --_=_NextPart_001_01C08552.FFC336D0 >> Content-Type: text/html; >> charset="ISO-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >> > charset=3DISO-8859-1"> >> > 5.5.2652.35"> >> RE: [OT?] Coding Style >> >> >> >> I prefer descriptive variable and function names - = >> like comments, they help to make code so much easier to read. >> >> >> One thing I wonder though... why do people prefer = >> 'some_function_name()' over 'SomeFunctionName()'? I personally = >> don't like the underscore character - it's an odd character to type = >> when you're trying to get the name typed in, and the shifted character, = >> I find, is easier to input. >> >> Cheers! >> Jon >> >> >> -Original Message- >> From: Steve Underwood [> HREF=3D"mailto:[EMAIL PROTECTED]">mailto:[EMAIL PROTECTED]]= >> >> >> >> Some people still seem to be living in the age of = >> KR C, with 6 or 7 >> character variable names that demand some = >> explanation. Maybe some day >> they will awake to the expressive power of long (and = >> well chosen) names. >> >> >> >> >> --_=_NextPart_001_01C08552.FFC336D0-- >> - >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to [EMAIL PROTECTED] >> Please read the FAQ at http://www.tux.org/lkml/ >> > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
> "MH" == Mike Harrold <[EMAIL PROTECTED]> writes: MH> For exactly the reverse of that reason. Typing capital letters is MH> a heck of a lot more difficult that addint an underscore. MH> Then there is reasability. MH> void ThisIsMyDumbassFunctionName MH> if MUCH more difficult to read than MH> void this_is_my_clear_and_easy_function_name I think that the distinction is moot and this argument a waste of time. If you are anything more than a code tourist, you should have no trouble dealing with mnemonic names. So the above can become: /* * timcaefn == this is my clear and easy function name */ void timcaefn (void); If you're at all concerned about RSI, your fingers will thank you. :-) :-) :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
> a = b + c; /* add a to b, and store it as c */ I think *this* comment is very fun, since it make me asking myself if I really know the C language :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
> > This message is in MIME format. Since your mail reader does not understand > this format, some or all of this message may not be legible. > > --_=_NextPart_001_01C08552.FFC336D0 > Content-Type: text/plain; > charset="ISO-8859-1" > > I prefer descriptive variable and function names - like comments, they help > to make code so much easier to read. > > One thing I wonder though... why do people prefer 'some_function_name()' > over 'SomeFunctionName()'? I personally don't like the underscore character > - it's an odd character to type when you're trying to get the name typed in, > and the shifted character, I find, is easier to input. > For exactly the reverse of that reason. Typing capital letters is a heck of a lot more difficult that addint an underscore. Then there is reasability. void ThisIsMyDumbassFunctionName if MUCH more difficult to read than void this_is_my_clear_and_easy_function_name Regards, /Mike > Cheers! > Jon > > > -Original Message- > > From: Steve Underwood [mailto:[EMAIL PROTECTED]] > > Some people still seem to be living in the age of K C, with 6 or 7 > character variable names that demand some explanation. Maybe some day > they will awake to the expressive power of long (and well chosen) names. > > --_=_NextPart_001_01C08552.FFC336D0 > Content-Type: text/html; > charset="ISO-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3DISO-8859-1"> > 5.5.2652.35"> > RE: [OT?] Coding Style > > > > I prefer descriptive variable and function names - = > like comments, they help to make code so much easier to read. > > > One thing I wonder though... why do people prefer = > 'some_function_name()' over 'SomeFunctionName()'? I personally = > don't like the underscore character - it's an odd character to type = > when you're trying to get the name typed in, and the shifted character, = > I find, is easier to input. > > Cheers! > Jon > > > -Original Message- > From: Steve Underwood [ HREF=3D"mailto:[EMAIL PROTECTED]">mailto:[EMAIL PROTECTED]]= > > > > Some people still seem to be living in the age of = > KR C, with 6 or 7 > character variable names that demand some = > explanation. Maybe some day > they will awake to the expressive power of long (and = > well chosen) names. > > > > > --_=_NextPart_001_01C08552.FFC336D0-- > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Tue, Jan 23, 2001 at 10:41:49AM -0500, Jonathan Earle wrote: > I prefer descriptive variable and function names - like comments, they help > to make code so much easier to read. > > One thing I wonder though... why do people prefer 'some_function_name()' > over 'SomeFunctionName()'? I personally don't like the underscore character > - it's an odd character to type when you're trying to get the name typed in, > and the shifted character, I find, is easier to input. I have a tendency to use class_functionName() where "class" represents a class of related functions. They all tend to take a point to an instance of that "class". So then you can read the code and see the "classes" in the names. And, this way, I can piss off both the anti underscore and the anti mixed case people at the same time :-) -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [OT?] Coding Style
Title: RE: [OT?] Coding Style I prefer descriptive variable and function names - like comments, they help to make code so much easier to read. One thing I wonder though... why do people prefer 'some_function_name()' over 'SomeFunctionName()'? I personally don't like the underscore character - it's an odd character to type when you're trying to get the name typed in, and the shifted character, I find, is easier to input. Cheers! Jon > -Original Message- > From: Steve Underwood [mailto:[EMAIL PROTECTED]] Some people still seem to be living in the age of K C, with 6 or 7 character variable names that demand some explanation. Maybe some day they will awake to the expressive power of long (and well chosen) names.
Re: [OT?] Coding Style
Larry McVoy wrote: > > Please don't listen to this. The only place you really want comments is > > a) at the top of files, describing the point of the file; > b) at the top of functions, if the purpose of the function is not obvious; > c) in line, when the code is not obvious. One other _very_ useful place: in header files. This is a place where a comment-per-line is appropriate. For example, include/linux/fs.h. Shame about `struct inode' though. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Larry McVoy wrote: > > On Mon, Jan 22, 2001 at 11:04:50AM -0500, Jonathan Earle wrote: > > > -Original Message- > > > From: profmakx.fmp [mailto:[EMAIL PROTECTED]] > > > > > > So, every good programmer > > > should know where to put comments. And it is unnecessary to > > > put comments to > > > explain what code does. One should see this as stated in the > > > CodingStyle doc. > > > Ok, there are points where a comment is good, but for example > > > at university > > > we are to comment on every single line of code ... > > > > WRONG!!! > > > > Not documenting your code is not a sign of good coding, but rather shows > > arrogance, laziness and contempt for "those who would dare tamper with your > > code after you've written it". Document and comment your code thoroughly. > > Do it as you go along. I was also taught to comment nearly every line - as > > part of the coding style used by a large, international company I worked for > > several years ago. It brings the logic of the programmer into focus and > > makes code maintenance a whole lot easier. It also helps one to remember > > the logic of your own code when you revisit it a year or more hence. > > Please don't listen to this. The only place you really want comments is > > a) at the top of files, describing the point of the file; > b) at the top of functions, if the purpose of the function is not obvious; > c) in line, when the code is not obvious. > > If you are writing code that requires a comment for every line, you are > writing bad, obscure, unobvious code and no amount of commenting will fix > it. > > The real reason to sparing in your comments is that code and comments are > not semantically bound to each other: the program doesn't stop working when > the comment becomes incorrect. It's incredibly frustrating to read a comment, > believe you understand what is going on, only to find out that the comment > and the code no longer match. > -- > --- > Larry McVoy lm at bitmover.com http://www.bitmover.com/lm It seems the great majority of heavily commented programs I have seen never commented anything useful. The h so useful the little snippets, like: /* Beware: The next two lines might seem weird, but they work around a bug in some revisions of XYZZY. */ were seldom there, but: a = b + c; /* add a to b, and store it as c */ were there in bundles. During a period of making a liveing out of sorting out severly screwed up projects I made a little comment stripper. I found comments so unreliable, and so seldom useful, I was better off reading the code without the confusion they might cause. I do, however, try to document the non-obvious through comments in what I write. Some people still seem to be living in the age of K C, with 6 or 7 character variable names that demand some explanation. Maybe some day they will awake to the expressive power of long (and well chosen) names. Regards, Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Stephen Satchell wrote: [lots of good advice deleted] > One goal of language designers is to REMOVE the need for comments. With a > good fourth-generation or fifth-generation language, the need for comments > diminishes to a detailed description of the data sets and any highly > unusual operations or transforms on the data. This is but a dream. You can't "design out" the need for comments by approaching natural language. Try reading a law book and realize that natural language too may be twisted to the extent that it needs extensive comments. The same goes for any computer language powerful enough to do useful work. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Stephen Satchell wrote: [lots of good advice deleted] One goal of language designers is to REMOVE the need for comments. With a good fourth-generation or fifth-generation language, the need for comments diminishes to a detailed description of the data sets and any highly unusual operations or transforms on the data. This is but a dream. You can't "design out" the need for comments by approaching natural language. Try reading a law book and realize that natural language too may be twisted to the extent that it needs extensive comments. The same goes for any computer language powerful enough to do useful work. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Larry McVoy wrote: On Mon, Jan 22, 2001 at 11:04:50AM -0500, Jonathan Earle wrote: -Original Message- From: profmakx.fmp [mailto:[EMAIL PROTECTED]] So, every good programmer should know where to put comments. And it is unnecessary to put comments to explain what code does. One should see this as stated in the CodingStyle doc. Ok, there are points where a comment is good, but for example at university we are to comment on every single line of code ... WRONG!!! Not documenting your code is not a sign of good coding, but rather shows arrogance, laziness and contempt for "those who would dare tamper with your code after you've written it". Document and comment your code thoroughly. Do it as you go along. I was also taught to comment nearly every line - as part of the coding style used by a large, international company I worked for several years ago. It brings the logic of the programmer into focus and makes code maintenance a whole lot easier. It also helps one to remember the logic of your own code when you revisit it a year or more hence. Please don't listen to this. The only place you really want comments is a) at the top of files, describing the point of the file; b) at the top of functions, if the purpose of the function is not obvious; c) in line, when the code is not obvious. If you are writing code that requires a comment for every line, you are writing bad, obscure, unobvious code and no amount of commenting will fix it. The real reason to sparing in your comments is that code and comments are not semantically bound to each other: the program doesn't stop working when the comment becomes incorrect. It's incredibly frustrating to read a comment, believe you understand what is going on, only to find out that the comment and the code no longer match. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm It seems the great majority of heavily commented programs I have seen never commented anything useful. The h so useful the little snippets, like: /* Beware: The next two lines might seem weird, but they work around a bug in some revisions of XYZZY. */ were seldom there, but: a = b + c; /* add a to b, and store it as c */ were there in bundles. During a period of making a liveing out of sorting out severly screwed up projects I made a little comment stripper. I found comments so unreliable, and so seldom useful, I was better off reading the code without the confusion they might cause. I do, however, try to document the non-obvious through comments in what I write. Some people still seem to be living in the age of KR C, with 6 or 7 character variable names that demand some explanation. Maybe some day they will awake to the expressive power of long (and well chosen) names. Regards, Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Larry McVoy wrote: Please don't listen to this. The only place you really want comments is a) at the top of files, describing the point of the file; b) at the top of functions, if the purpose of the function is not obvious; c) in line, when the code is not obvious. One other _very_ useful place: in header files. This is a place where a comment-per-line is appropriate. For example, include/linux/fs.h. Shame about `struct inode' though. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [OT?] Coding Style
Title: RE: [OT?] Coding Style I prefer descriptive variable and function names - like comments, they help to make code so much easier to read. One thing I wonder though... why do people prefer 'some_function_name()' over 'SomeFunctionName()'? I personally don't like the underscore character - it's an odd character to type when you're trying to get the name typed in, and the shifted character, I find, is easier to input. Cheers! Jon -Original Message- From: Steve Underwood [mailto:[EMAIL PROTECTED]] Some people still seem to be living in the age of KR C, with 6 or 7 character variable names that demand some explanation. Maybe some day they will awake to the expressive power of long (and well chosen) names.
Re: [OT?] Coding Style
On Tue, Jan 23, 2001 at 10:41:49AM -0500, Jonathan Earle wrote: I prefer descriptive variable and function names - like comments, they help to make code so much easier to read. One thing I wonder though... why do people prefer 'some_function_name()' over 'SomeFunctionName()'? I personally don't like the underscore character - it's an odd character to type when you're trying to get the name typed in, and the shifted character, I find, is easier to input. I have a tendency to use class_functionName() where "class" represents a class of related functions. They all tend to take a point to an instance of that "class". So then you can read the code and see the "classes" in the names. And, this way, I can piss off both the anti underscore and the anti mixed case people at the same time :-) -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --_=_NextPart_001_01C08552.FFC336D0 Content-Type: text/plain; charset="ISO-8859-1" I prefer descriptive variable and function names - like comments, they help to make code so much easier to read. One thing I wonder though... why do people prefer 'some_function_name()' over 'SomeFunctionName()'? I personally don't like the underscore character - it's an odd character to type when you're trying to get the name typed in, and the shifted character, I find, is easier to input. For exactly the reverse of that reason. Typing capital letters is a heck of a lot more difficult that addint an underscore. Then there is reasability. void ThisIsMyDumbassFunctionName if MUCH more difficult to read than void this_is_my_clear_and_easy_function_name Regards, /Mike Cheers! Jon -Original Message- From: Steve Underwood [mailto:[EMAIL PROTECTED]] Some people still seem to be living in the age of KR C, with 6 or 7 character variable names that demand some explanation. Maybe some day they will awake to the expressive power of long (and well chosen) names. --_=_NextPart_001_01C08552.FFC336D0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" HTML HEAD META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3DISO-8859-1" META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2652.35" TITLERE: [OT?] Coding Style/TITLE /HEAD BODY PFONT SIZE=3D2I prefer descriptive variable and function names - = like comments, they help to make code so much easier to read./FONT /P PFONT SIZE=3D2One thing I wonder though... why do people prefer = 'some_function_name()' over 'SomeFunctionName()'?nbsp; I personally = don't like the underscore character - it's an odd character to type = when you're trying to get the name typed in, and the shifted character, = I find, is easier to input./FONT/P PFONT SIZE=3D2Cheers!/FONT BRFONT SIZE=3D2Jon/FONT /P PFONT SIZE=3D2gt; -Original Message-/FONT BRFONT SIZE=3D2gt; From: Steve Underwood [A = HREF=3D"mailto:[EMAIL PROTECTED]"mailto:[EMAIL PROTECTED]/A]/FONT= /P PFONT SIZE=3D2Some people still seem to be living in the age of = Kamp;R C, with 6 or 7/FONT BRFONT SIZE=3D2character variable names that demand some = explanation. Maybe some day/FONT BRFONT SIZE=3D2they will awake to the expressive power of long (and = well chosen) names./FONT /P /BODY /HTML --_=_NextPart_001_01C08552.FFC336D0-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
a = b + c; /* add a to b, and store it as c */ I think *this* comment is very fun, since it make me asking myself if I really know the C language :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
"MH" == Mike Harrold [EMAIL PROTECTED] writes: MH For exactly the reverse of that reason. Typing capital letters is MH a heck of a lot more difficult that addint an underscore. MH Then there is reasability. MH void ThisIsMyDumbassFunctionName MH if MUCH more difficult to read than MH void this_is_my_clear_and_easy_function_name I think that the distinction is moot and this argument a waste of time. If you are anything more than a code tourist, you should have no trouble dealing with mnemonic names. So the above can become: /* * timcaefn == this is my clear and easy function name */ void timcaefn (void); If you're at all concerned about RSI, your fingers will thank you. :-) :-) :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Too bad we can't just do a "Prince" and invent unpronouncable symbols to use as function names... or perhaps just use something from the chinese fonts ;o)... Mike Harrold wrote: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --_=_NextPart_001_01C08552.FFC336D0 Content-Type: text/plain; charset="ISO-8859-1" I prefer descriptive variable and function names - like comments, they help to make code so much easier to read. One thing I wonder though... why do people prefer 'some_function_name()' over 'SomeFunctionName()'? I personally don't like the underscore character - it's an odd character to type when you're trying to get the name typed in, and the shifted character, I find, is easier to input. For exactly the reverse of that reason. Typing capital letters is a heck of a lot more difficult that addint an underscore. Then there is reasability. void ThisIsMyDumbassFunctionName if MUCH more difficult to read than void this_is_my_clear_and_easy_function_name Regards, /Mike Cheers! Jon -Original Message- From: Steve Underwood [mailto:[EMAIL PROTECTED]] Some people still seem to be living in the age of KR C, with 6 or 7 character variable names that demand some explanation. Maybe some day they will awake to the expressive power of long (and well chosen) names. --_=_NextPart_001_01C08552.FFC336D0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" HTML HEAD META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3DISO-8859-1" META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2652.35" TITLERE: [OT?] Coding Style/TITLE /HEAD BODY PFONT SIZE=3D2I prefer descriptive variable and function names - = like comments, they help to make code so much easier to read./FONT /P PFONT SIZE=3D2One thing I wonder though... why do people prefer = 'some_function_name()' over 'SomeFunctionName()'?nbsp; I personally = don't like the underscore character - it's an odd character to type = when you're trying to get the name typed in, and the shifted character, = I find, is easier to input./FONT/P PFONT SIZE=3D2Cheers!/FONT BRFONT SIZE=3D2Jon/FONT /P PFONT SIZE=3D2gt; -Original Message-/FONT BRFONT SIZE=3D2gt; From: Steve Underwood [A = HREF=3D"mailto:[EMAIL PROTECTED]"mailto:[EMAIL PROTECTED]/A]/FONT= /P PFONT SIZE=3D2Some people still seem to be living in the age of = Kamp;R C, with 6 or 7/FONT BRFONT SIZE=3D2character variable names that demand some = explanation. Maybe some day/FONT BRFONT SIZE=3D2they will awake to the expressive power of long (and = well chosen) names./FONT /P /BODY /HTML --_=_NextPart_001_01C08552.FFC336D0-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [OT?] Coding Style
"Jonathan Earle" [EMAIL PROTECTED]: I prefer descriptive variable and function names - like comments, they help to make code so much easier to read. One thing I wonder though... why do people prefer 'some_function_name()' over 'SomeFunctionName()'? I personally don't like the underscore character - it's an odd character to type when you're trying to get the name typed in, and the shifted character, I find, is easier to input. Code is written by the few. Code is read by the many, and having _ in there makes it MUCH easier to read. Visual comparison of "SomeFunctionName" and "some_function_name" is faster even for a coder where there may be a typo (try dropping a character) or mis identifing two different symbols with similar names: d_hash_mask d_hash_shift This is relatively easy to read. conversely: DHashMask DHashShift Are more difficult to spot. In this case "The good of the many outweigh the good of the few". - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Tue, Jan 23, 2001 at 10:41:49AM -0500, Jonathan Earle wrote: One thing I wonder though... why do people prefer 'some_function_name()' over 'SomeFunctionName()'? i_would_assume_that_it_is_because_the_underscore_serves_the_same_word- seperation_role_that_a_space_does_in_normal_prose. RunningWordsAll Together(OrShouldISay"ToGetHer"ForMaximumStudlyness)JustDoesNotParseAs Readily, and that, rather that ease of typing is what counts. -- John Kodis [EMAIL PROTECTED] Phone: 301-286-7376 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
At 08:28 PM 1/23/01 +0800, Steve Underwood wrote: During a period of making a liveing out of sorting out severly screwed up projects I made a little comment stripper. I found comments so unreliable, and so seldom useful, I was better off reading the code without the confusion they might cause. I do, however, try to document the non-obvious through comments in what I write. Ditto. Mine had the option of leaving the block comments in place (line count was a parameter) because the block comments proved to be more useful than the in-line comments. Some people still seem to be living in the age of KR C, with 6 or 7 character variable names that demand some explanation. Maybe some day they will awake to the expressive power of long (and well chosen) names. Actually, they are still living as though the KSR-33 and ASR-33 teletypes were the only input device. :) True story: I was retained to solve a particular problem for a company over a one-year time period. I wrote some rather nifty code to solve the problem, and was happily doing data extraction and conversion for that time period. Then there was a management turnover at the client and the new guy decided to implement a cost-cutting measure: cut out as many outsiders as possible. He decided that I should give him the code I had developed over the year (that wasn't part of the contract, of course) so that he could have in-house people do it. Not just executable programs, of course. "We bought the development of that code, so we deserve the source." The bastard backed up the demand with his lawyer. Not wanting to spend the money on the threatened lawsuit, I gave him exactly what he asked for: the source to the latest working version of the programs I wrote to do the job. It took a while to prepare the source for this jerk. Here is what I did to the source I gave the guy: 1) Used the output of CPP, which stripped out all include files and strips all comments. This had the interesting side effect of making the source compiler-dependent. 2) Stripped all newlines, and converted strings of spaces and tabs not in quotes to a single space. This made the source one line long...a VERY LONG line. 3) Converted each reasonable variable name to a string of seven random characters from the set [A-Aa-z0-9_], with the first character restricted to [A-Za-z]. A list of #define statements equated the random name to the proper library name or symbol. (Because the names included a number of internal variables in the compiler library, this was a HUGE list.) The resulting symbol table was so large that I had to use disk to keep all the names. Inadvertently I had also randomized lexical elements such as "for", "while" and so forth, but #define statements took care of that problem. 4) Determined that the output of the compiler with the mangled source was exactly the same as the output of the compiler with the original source. As you can guess, I discovered a few bugs with the compiler I was using. The compiler writer (who was just down the road) was highly amused with this and asked if they could "borrow" my mangler "for test purposes." (Just who do they think they were kiddin'?) Satch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Georg Nikodym wrote: I think that the distinction is moot and this argument a waste of time. If you are anything more than a code tourist, you should have no trouble dealing with mnemonic names. So the above can become: /* * timcaefn == this is my clear and easy function name */ void timcaefn (void); If you're at all concerned about RSI, your fingers will thank you. This is why the autocompletion of functions and struct members in VC++ is awfully nice...hit the first few unique letters and it will complete the rest of the function for you, then hit tab and keep going. Is there anything with that functionality under Linux? Chris -- Chris Friesen| MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
[EMAIL PROTECTED] ("Christopher Friesen") writes:
Georg Nikodym wrote:
I think that the distinction is moot and this argument a waste of
time. If you are anything more than a code tourist, you should have
no trouble dealing with mnemonic names. So the above can become:
/*
* timcaefn == this is my clear and easy function name
*/
void timcaefn (void);
If you're at all concerned about RSI, your fingers will thank you.
This is why the autocompletion of functions and struct members in VC++ is
awfully nice...hit the first few unique letters and it will complete the rest of
the function for you, then hit tab and keep going. Is there anything with that
functionality under Linux?
Esc-/ under emacs...
--
Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED]
Learning French is trivial: the word for horse is cheval, and
everything else follows in the same way.
-- Alan J. Perlis
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Tue, 23 Jan 2001, Helge Hafting wrote: Stephen Satchell wrote: [lots of good advice deleted] One goal of language designers is to REMOVE the need for comments. With a good fourth-generation or fifth-generation language, the need for comments diminishes to a detailed description of the data sets and any highly unusual operations or transforms on the data. This is but a dream. You can't "design out" the need for comments by approaching natural language. Try reading a law book and realize that natural language too may be twisted to the extent that it needs extensive comments. The same goes for any computer language powerful enough to do useful work. Actually using natural language and other such constructs may INCREASE the need for comments. For more examples, see Perl. [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
"CF" == Christopher Friesen [EMAIL PROTECTED] writes: CF This is why the autocompletion of functions and struct members in CF VC++ is awfully nice...hit the first few unique letters and it CF will complete the rest of the function for you, then hit tab and CF keep going. Is there anything with that functionality under CF Linux? Yup. Emacs users can use the mis-named dynamic abbreviation function (daddrev-expand which I have mapped to M-/). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
I am not sure about Linux IDEs, but when I programmed Objective-C using the OpenStep IDE, you could not only do auto-completion on those, but on any word that had been previously used. That was cool, and didn't cause wacky problems like you might think it would (auto-completing words like the, to, for, etc when trying to type something else). JBuilder comes close, so I am guessing the Klyx will also. I sent an email suggestion to Inprise, excuse me..Borland, on the subject last year. They seemed to like it. jk At 01:05 PM 1/23/01 -0500, Christopher Friesen wrote: This is why the autocompletion of functions and struct members in VC++ is awfully nice...hit the first few unique letters and it will complete the rest of the function for you, then hit tab and keep going. Is there anything with that functionality under Linux? Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [OT?] Coding Style
That's just nasty! Funny, but nasty. :) Jon -Original Message- From: Stephen Satchell [mailto:[EMAIL PROTECTED]] It took a while to prepare the source for this jerk. Here is what I did to the source I gave the guy: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Unfortunately the C standards people don't seem to realise there are languages other than English. C99 had perfect timing to introduce UTF8 Unicode as acceptable in C source. Alas they missed the boat. I have been embedding Chinese in C source for years (mostly Big-5 - UTF8 is more likely to be troublesome with existing compilers), and have yet to hit a significant problem. It isn't standards compliant, though. Regards, Steve Joe deBlaquiere wrote: Too bad we can't just do a "Prince" and invent unpronouncable symbols to use as function names... or perhaps just use something from the chinese fonts ;o)... Mike Harrold wrote: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --_=_NextPart_001_01C08552.FFC336D0 Content-Type: text/plain; charset="ISO-8859-1" I prefer descriptive variable and function names - like comments, they help to make code so much easier to read. One thing I wonder though... why do people prefer 'some_function_name()' over 'SomeFunctionName()'? I personally don't like the underscore character - it's an odd character to type when you're trying to get the name typed in, and the shifted character, I find, is easier to input. For exactly the reverse of that reason. Typing capital letters is a heck of a lot more difficult that addint an underscore. Then there is reasability. void ThisIsMyDumbassFunctionName if MUCH more difficult to read than void this_is_my_clear_and_easy_function_name - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Too bad we can't just do a "Prince" and invent unpronouncable symbols to use as function names... or perhaps just use something from the chinese fonts ;o)... Sorry. You'll need to use Java if you want to use Unicode source. Brent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
At 11:56 PM 1/22/01 +, Anton Altaparmakov wrote:
>At 16:42 22/01/2001, Mark I Manning IV wrote:
>>Stephen Satchell wrote:
>> > I got in the habit of using
>> > structures to minimize the number of symbols I exposed. It also
>> > disambiguates local variables and parameters from file- and program-global
>> > variables.
>>
>>explain this one to me, i think it might be usefull...
>
>What might be meant is that instead of declaring variables my_module_var1,
>my_module_var2, my_module_var3, etc. you declare a struct my_module {
>var1; var2; var3; etc. }. Obviously in glorious technicolour formatting... (-;
>That's my interpretation anyway...
The first sentence is right on the money. In addition to module variables,
I define a global structure as:
extern struct G {
/* the real globals */
} g;
and then in the main program I define the instance as "struct G g;" This
is more for apps than operating systems.
Further to the avoidance of pollution of the external global namespace, I
define local functions as static. Indeed, in one parser I had over 1400
very small functions, none of them with external scope. Instead, I defined
a structure of function pointers and exposed one name to the rest of the
world. Sound stupid? Well, that stupidity had its place: the "opcode" in
the pseudo-instruction stream was the offset into this structure of
pointers to the pointer of interest, which made the main loop for the
parser about five lines long, and not a switch statement to be seen. Three
of those lines were to handle unknown-opcodes...
I also am partial to arrays of function pointers when appropriate. Ever
think how easy it would be to implement a TCP stack that would handle the
"lamp-test packet" as a single special case? Granted, it results in a
small amount of code bloat over the traditional in-line test method, but it
does make you think about EVERY SINGLE ONE OF THE 64 COMBINATIONS of
Urg/Ack/Psh/Rst/Syn/Fin (to use the labels from the 1985 version of RFC
793) and what they really mean. Especially the combination with all bits set.
Satch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Admin Mailing Lists wrote: >hand-holding of that magnitude. We don't write code for idiots. But if you have to, you can at least enjoy it: - diversity makes life interesting: use switch() with local variables or without curly braces - de-referencing is like a hotel: the more stars, the better - observe proper punctuation: use the comma operator frequently - know thy C: few people know that 5[x] is valid, but they can usually guess what it does. They probably won't get x[5[y]], though. - know thy CPP: nest macros and exercise token-concatenation and stingification - if your code allows you to, put #define while if in some header file - Werner (couldn't resist ;-) -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Mon, Jan 22, 2001 at 11:56:40PM +, Anton Altaparmakov wrote:
> At 16:42 22/01/2001, Mark I Manning IV wrote:
> >Stephen Satchell wrote:
> > > I got in the habit of using
> > > structures to minimize the number of symbols I exposed. It also
> > > disambiguates local variables and parameters from file- and program-global
> > > variables.
> >
> >explain this one to me, i think it might be usefull...
>
> What might be meant is that instead of declaring variables my_module_var1,
> my_module_var2, my_module_var3, etc. you declare a struct my_module { var1;
> var2; var3; etc. }. Obviously in glorious technicolour formatting... (-;
> That's my interpretation anyway...
Mine too and I think it's a good idea. I have code in BitKeeper where I
both did and did not do that for command line options and I much prefer
the structure version.
Another habit I used to use and have fallen out of, which is a bad idea, is
one where you use a prefix in stucture files so that you can see
the difference between
p->st_mode
and
p->f_mode
In other words, the prefix implies the structure name. Early versions of the
C compiler had all structure fields (I mean _all_) in one name space so this
wasn't style, it was required. I must say that it makes code more readable.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
At 16:42 22/01/2001, Mark I Manning IV wrote:
>Stephen Satchell wrote:
> > I got in the habit of using
> > structures to minimize the number of symbols I exposed. It also
> > disambiguates local variables and parameters from file- and program-global
> > variables.
>
>explain this one to me, i think it might be usefull...
What might be meant is that instead of declaring variables my_module_var1,
my_module_var2, my_module_var3, etc. you declare a struct my_module { var1;
var2; var3; etc. }. Obviously in glorious technicolour formatting... (-;
That's my interpretation anyway...
Anton
--
"Education is what remains after one has forgotten everything he
learned in school." - Albert Einstein
--
Anton Altaparmakov Voice: +44-(0)1223-333541(lab) / +44-(0)7712-632205(mobile)
Christ's CollegeeMail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
Cambridge CB2 3BUICQ: 8561279
United Kingdom WWW: http://www-stu.christs.cam.ac.uk/~aia21/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
> > Please don't listen to this. The only place you really want comments is > > a) at the top of files, describing the point of the file; > b) at the top of functions, if the purpose of the function is not obvious; > c) in line, when the code is not obvious. > > If you are writing code that requires a comment for every line, you are > writing bad, obscure, unobvious code and no amount of commenting will fix > it. > or 1) your code-viewing audience is a bunch of 5 year olds 2) the person reading the code isn't a 'qualified' programmer. If they were, they'd most likely be able to understand the code without hand-holding of that magnitude. We don't write code for idiots. -Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] Intergrafix Internet Services "Dream as if you'll live forever, live as if you'll die today" http://www.asteroid-b612.orghttp://www.intergrafix.net .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Stephen Satchell wrote:
>
> One goal of language designers is to REMOVE the need for comments. With a
this is a crock of (deleted). You are chaising rainbows dood, you will
NEVER remove teh need for comments but its obvious you remove teh
comments.
> good fourth-generation or fifth-generation language, the need for comments
> diminishes to a detailed description of the data sets and any highly
> unusual operations or transforms on the data.
sorry but i could not disagree more
>
> I've even gone so far as to "invent" my own languages, and the parsers to
> go with them, to reduce the need to comment by making the code easy for
> humans to read. Not only are such systems easier to debug (with good
> language design) but are highly maintainable and usually not all that
> difficult to extend when necessary.
no lprogramming anguage can describe describe the design of the
applications written in it. you NEED to comment your code. 100% Self
commenting code is a falacy. 50% self commenting code is almost
impossible to achieve. COMMENT IT!
>
> Remember, the line-by-line commenting requirement was mandatory in
> assembler programming, because the nature of assembler made you outline
> each step by tiring step.
You talk like you dislike assembler as much as i dislike c :)
> When I worked for Rockwell, I was granted a
> partial wavier when I showed them my assembler-language commenting
> style: pseudo-code at the top of each block of assembler code.
very ugly. The S4 meter from landys and gyr (now siemens) actually uses
c code above each assembler routine as a form of commeting. using code
to comment code is fine as long as you COMMENT the comments!
> Comments do NOT make code maintenance easier. Too many comments obscure
> what is really going on.
well... i disagree, years of consulting work and having to deal with
hunks of legacy code with no comments and huge functions etc etc et
(every coders worst nightmare) has taught me that comments are very much
needed (even bad comments are preferable to none at all)
> Linus' style actually increases the
> maintainability of the code, because if the code doesn't accurately show
> how it implements the goal specified in the block comment, the coder hasn't
> done his/her job.
TRUE. Code should be written well enough that it isnt naturally
obfuscated but this does NOT remove the need for comments.
> Want to improve the maintainability of C code? Consider the following:
>
> 1) Keep functional parts small. If the code won't fit in a hundred lines
> or so of code, then you haven't factored the problem well
> enough. Functional parts != functions.
> A program with thousands of
> well-encapsulated function parts strung together into a single function is
> easier to maintain than a "well-factored" program with its parts spread all
> over hell.
Cram a gazillion simple operations into a single function and you end up
with chaos, totally unfactored code is almost impossible to read.
> Diagnostic programmers have learned the hard way that factoring
> a program can make it difficult to ensure test coverage and even more
> difficult to determine if a part of the code is buggy or whether it found a
> hardware error that it was looking for.
then they dont know how to test a program. period
> In my ANSI C code, you will see the following a lot:
>
> #define DO /*syntactic sugar */
>
> DO {
> }
>
> DO {
>}
>
>
> 2) Reduce visual complexity where possible. Instead of using nested
> if-then-else statements, consider unrolling the nested
> statement. Example: {if (a && c)...; if (b && c)...; instead of {if (c)
> {if (a)...; if(b)...;}
which is simpler...
(x + y) ^ 2
or...
(x ^2) + (Y ^2) + 2xy
> 3) Make creative use of a run-on if statement to improve error detection
> and recording. One of my tricks is to code the following statement in
> application programs:
>
> if( (err = "input file can't be opened", in = fopen(filename,
> "rb"), in == NULL)
> || (err = "output file can't be opened", out = fopen(oname, "wb"),
> out = NULL)
> ...
> )
use clever little tricks in your c so as to confuse people ? You are
obviously a very advanced c coder who knows well the intracasies of the
language. The person who has to maintain your code 10 years after you
have left may not be.
>{
>/* report the error that occurred, using the char * variable "err"
> to indicate the exact error. */
>}
granted, the above block of code was not that difficult to understand,
even tho I have never seen that particular trick used before but the
above statement still stands. (nice trick btw :)
> 4) The functional part should be contained in a reasonable number of
> lines. Large while and for loops should call functions instead of having
> bloated bodies. Large case statements should call functions instead of
> running on
RE: [OT?] Coding Style
At 11:04 AM 1/22/01 -0500, you wrote:
>WRONG!!!
>
>Not documenting your code is not a sign of good coding, but rather shows
>arrogance, laziness and contempt for "those who would dare tamper with your
>code after you've written it". Document and comment your code thoroughly.
>Do it as you go along. I was also taught to comment nearly every line - as
>part of the coding style used by a large, international company I worked for
>several years ago. It brings the logic of the programmer into focus and
>makes code maintenance a whole lot easier. It also helps one to remember
>the logic of your own code when you revisit it a year or more hence.
Oh, those who refuse to study history are doomed to repeat it.
The COBOL language was created specifically to reduce the amount of
commenting necessary in a program, because the English-like sentence
structure could be read and understood by humans. The FORTRAN language was
created so that math types could "talk" in a language more familiar to
them, letting the computer take care of the details about how to perform
the specified task step-by-step.
One goal of language designers is to REMOVE the need for comments. With a
good fourth-generation or fifth-generation language, the need for comments
diminishes to a detailed description of the data sets and any highly
unusual operations or transforms on the data.
I've even gone so far as to "invent" my own languages, and the parsers to
go with them, to reduce the need to comment by making the code easy for
humans to read. Not only are such systems easier to debug (with good
language design) but are highly maintainable and usually not all that
difficult to extend when necessary.
Remember, the line-by-line commenting requirement was mandatory in
assembler programming, because the nature of assembler made you outline
each step by tiring step. When I worked for Rockwell, I was granted a
partial wavier when I showed them my assembler-language commenting
style: pseudo-code at the top of each block of assembler code. Blindly
applying the rule to second-generation and later languages is just sloppy
management, usually by people who don't understand coding. (And yes, that
includes some professors of computer science I have known.)
Comments do NOT make code maintenance easier. Too many comments obscure
what is really going on. Linus' style actually increases the
maintainability of the code, because if the code doesn't accurately show
how it implements the goal specified in the block comment, the coder hasn't
done his/her job.
Want to improve the maintainability of C code? Consider the following:
1) Keep functional parts small. If the code won't fit in a hundred lines
or so of code, then you haven't factored the problem well
enough. Functional parts != functions. A program with thousands of
well-encapsulated function parts strung together into a single function is
easier to maintain than a "well-factored" program with its parts spread all
over hell. Diagnostic programmers have learned the hard way that factoring
a program can make it difficult to ensure test coverage and even more
difficult to determine if a part of the code is buggy or whether it found a
hardware error that it was looking for. This is why diagnostics tend to be
rather long affairs with very few functions.
In my ANSI C code, you will see the following a lot:
#define DO /*syntactic sugar */
DO {
http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Mon, 22 Jan 2001, Larry McVoy wrote: > On Mon, Jan 22, 2001 at 11:04:50AM -0500, Jonathan Earle wrote: > > > -Original Message- > > > From: profmakx.fmp [mailto:[EMAIL PROTECTED]] > > > > > > So, every good programmer > > > should know where to put comments. And it is unnecessary to > > > put comments to > > > explain what code does. One should see this as stated in the > > > CodingStyle doc. > > > Ok, there are points where a comment is good, but for example > > > at university > > > we are to comment on every single line of code ... > > > > WRONG!!! > > > > Not documenting your code is not a sign of good coding, but rather shows > > arrogance, laziness and contempt for "those who would dare tamper with your > > code after you've written it". Document and comment your code thoroughly. > > Do it as you go along. I was also taught to comment nearly every line - as > > part of the coding style used by a large, international company I worked for > > several years ago. It brings the logic of the programmer into focus and > > makes code maintenance a whole lot easier. It also helps one to remember > > the logic of your own code when you revisit it a year or more hence. > > Please don't listen to this. The only place you really want comments is > > a) at the top of files, describing the point of the file; > b) at the top of functions, if the purpose of the function is not obvious; > c) in line, when the code is not obvious. > > If you are writing code that requires a comment for every line, you are > writing bad, obscure, unobvious code and no amount of commenting will fix > it. > > The real reason to sparing in your comments is that code and comments are > not semantically bound to each other: the program doesn't stop working when > the comment becomes incorrect. It's incredibly frustrating to read a comment, > believe you understand what is going on, only to find out that the comment > and the code no longer match. > -- > --- > Larry McVoylm at bitmover.com >http://www.bitmover.com/lm Okay, I'll byte (sic)... If you are a good programmer, your code should work well and you will be writing code for new projects long before the product enters the in-production maintenance phase. This phase exists in real products during their lifetime. At this time, rather junior programmers will be required to add new capability or even fix bugs. Even excellent programmers generate bugs that are not discovered for a long time (perhaps ever). This occurs because not every code path gets tested so these bugs are not always found. For instance, the return value from a function that encounters hardware errors may not be correct because, during the entire development phase, the hardware never generated that specific error. When maintaining code, the programmer may have never seen the code before. If it takes several weeks to find the function that is returning the wrong value, and if it takes several hours to correct the problem after the function is located, then the original writer did not complete his or her job correctly. Comments should assume that the reader is expert in the language being used. No other assumptions produce useful documentation. There are many ways to document code. Not all of these ways involve comments. Examples are: (1) MACROS: Lots of programmers don't use MACROS for documentation. However they are very useful. Suppose we have a complicated single-bit sequence necessary to communicate with a SEEPROM. If the main-line code does: WRITE_SEEPROM(parameter); READ_SEEPROM(parameter); ... then the code is very clear. The MACRO can be very complicated. When it is isolated in this manner, the code both for the MACRO and the functions that expand this MACRO are better documented than just laying code. (2) Descriptive names: I don't like these myself. Often programmers get too cute. You can look at the BusLogic code and see what I am talking about. Practically every variable and function name begins with "BusLogic". However, descriptive variable and function names do help document code. This, even though many get carried away with extremes. Most everybody will recognize: for (i=0; i< LIMIT; i++) ; We don't really need: for(SimpleIntegerCount=0; SimpleIntegerCount < OneLessThanTheArraySize; SimpleIntegerCount++) ; But, when you are writing complicated code, it is often useful to use descriptive names that uniquely define several otherwise similar routines. For instance: Write_error_log(data); Append_error_log(data); Again, some carry this to the extreme, they take a good idea and corrupt it, MicroSoftSyle, into: WriteErrorLog(data); AppendErrorLog(data); (3) Comments: Comments are very useful if they convey useful information. Many comments are not useful because they seem to exist only because
RE: [OT?] Coding Style
> -Original Message- > From: Larry McVoy [mailto:[EMAIL PROTECTED]] > > On Mon, Jan 22, 2001 at 11:04:50AM -0500, Jonathan Earle wrote: > > > -Original Message- > > > From: profmakx.fmp [mailto:[EMAIL PROTECTED]] > > > > > > So, every good programmer > > > should know where to put comments. And it is unnecessary to > > > put comments to > > > explain what code does. One should see this as stated in the > > > CodingStyle doc. > > > Ok, there are points where a comment is good, but for example > > > at university > > > we are to comment on every single line of code ... > > > > WRONG!!! > > > > Not documenting your code is not a sign of good coding, but > rather shows > > arrogance, laziness and contempt for "those who would dare > tamper with your > > code after you've written it". Document and comment your > code thoroughly. > > Do it as you go along. I was also taught to comment nearly > every line - as > > part of the coding style used by a large, international > company I worked for > > several years ago. It brings the logic of the programmer > into focus and > > makes code maintenance a whole lot easier. It also helps > one to remember > > the logic of your own code when you revisit it a year or more hence. > > Please don't listen to this. The only place you really want > comments is > > a) at the top of files, describing the point of the file; > b) at the top of functions, if the purpose of the > function is not obvious; > c) in line, when the code is not obvious. > > If you are writing code that requires a comment for every > line, you are > writing bad, obscure, unobvious code and no amount of > commenting will fix > it. The point of comments is not to "fix" bad code, it's to provide understanding. As the original poster said, _you_ may understand your code, but that in no way implies that _I_ will, or your co-worker down the hall will, etc. I'm not suggesting that a statement like "counter=0;" at the start of a function be commented, but other operations should be. "Why do we want this file written in /proc - wouldn't syslog have worked better?" "Why is this loop skipping the first seven elements?" "Why is this structure used here instead of a simple array?" "What on earth does m->n->o->num represent?" > The real reason to sparing in your comments is that code and > comments are > not semantically bound to each other: the program doesn't > stop working when > the comment becomes incorrect. It's incredibly frustrating > to read a comment, > believe you understand what is going on, only to find out > that the comment > and the code no longer match. Comments should be updated when code is updated. I believe that documentation is of far greater value than code itself. Code can be changed, however, logic drives the code. Without a good understanding of the latter, the former is of little value, IMHO. Cheers! Jon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Mon, Jan 22, 2001 at 11:04:50AM -0500, Jonathan Earle wrote: > WRONG!!! > > Not documenting your code is not a sign of good coding, but rather shows > arrogance, laziness and contempt for "those who would dare tamper with your > code after you've written it". Document and comment your code thoroughly. > Do it as you go along. I was also taught to comment nearly every line - as > part of the coding style used by a large, international company I worked for > several years ago. It brings the logic of the programmer into focus and > makes code maintenance a whole lot easier. It also helps one to remember > the logic of your own code when you revisit it a year or more hence. Not wrong: You should document the interface, and any strange gotchas that you faced while writing the function (like hardware bugs, etc). Then, if the next person can't understand the code by reading it: 1. He's not qualified to change it. *OR* 2. The code is crap, it needs to be rewritten anyways, good interface documentation makes that possible. Documenting every detail just encourages people with a paper thin understanding to go and foul it up in subtile ways, it's better that they be completely clueless and screw it up obviously. Good code is simple, clean, and obvious. Sometimes, some code can't be clean because it's facing a very hard problem, all the more reason to leave it to gurus. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Mon, Jan 22, 2001 at 11:04:50AM -0500, Jonathan Earle wrote: > > -Original Message- > > From: profmakx.fmp [mailto:[EMAIL PROTECTED]] > > > > So, every good programmer > > should know where to put comments. And it is unnecessary to > > put comments to > > explain what code does. One should see this as stated in the > > CodingStyle doc. > > Ok, there are points where a comment is good, but for example > > at university > > we are to comment on every single line of code ... > > WRONG!!! > > Not documenting your code is not a sign of good coding, but rather shows > arrogance, laziness and contempt for "those who would dare tamper with your > code after you've written it". Document and comment your code thoroughly. > Do it as you go along. I was also taught to comment nearly every line - as > part of the coding style used by a large, international company I worked for > several years ago. It brings the logic of the programmer into focus and > makes code maintenance a whole lot easier. It also helps one to remember > the logic of your own code when you revisit it a year or more hence. Please don't listen to this. The only place you really want comments is a) at the top of files, describing the point of the file; b) at the top of functions, if the purpose of the function is not obvious; c) in line, when the code is not obvious. If you are writing code that requires a comment for every line, you are writing bad, obscure, unobvious code and no amount of commenting will fix it. The real reason to sparing in your comments is that code and comments are not semantically bound to each other: the program doesn't stop working when the comment becomes incorrect. It's incredibly frustrating to read a comment, believe you understand what is going on, only to find out that the comment and the code no longer match. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
> > > -Original Message- > > From: profmakx.fmp [mailto:[EMAIL PROTECTED]] > > > > So, every good programmer > > should know where to put comments. And it is unnecessary to > > put comments to > > explain what code does. One should see this as stated in the > > CodingStyle doc. > > Ok, there are points where a comment is good, but for example > > at university > > we are to comment on every single line of code ... > > WRONG!!! > > Not documenting your code is not a sign of good coding, but rather shows > arrogance, laziness and contempt for "those who would dare tamper with your > code after you've written it". Document and comment your code thoroughly. > Do it as you go along. I was also taught to comment nearly every line - as > part of the coding style used by a large, international company I worked for > several years ago. It brings the logic of the programmer into focus and > makes code maintenance a whole lot easier. It also helps one to remember > the logic of your own code when you revisit it a year or more hence. > There is an old programmer's rule. "Documentation? Too bad. If the code was damned hard to write, it should be damned hard to understand." :) /Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [OT?] Coding Style
> -Original Message- > From: profmakx.fmp [mailto:[EMAIL PROTECTED]] > > So, every good programmer > should know where to put comments. And it is unnecessary to > put comments to > explain what code does. One should see this as stated in the > CodingStyle doc. > Ok, there are points where a comment is good, but for example > at university > we are to comment on every single line of code ... WRONG!!! Not documenting your code is not a sign of good coding, but rather shows arrogance, laziness and contempt for "those who would dare tamper with your code after you've written it". Document and comment your code thoroughly. Do it as you go along. I was also taught to comment nearly every line - as part of the coding style used by a large, international company I worked for several years ago. It brings the logic of the programmer into focus and makes code maintenance a whole lot easier. It also helps one to remember the logic of your own code when you revisit it a year or more hence. Jon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [OT?] Coding Style
-Original Message- From: profmakx.fmp [mailto:[EMAIL PROTECTED]] So, every good programmer should know where to put comments. And it is unnecessary to put comments to explain what code does. One should see this as stated in the CodingStyle doc. Ok, there are points where a comment is good, but for example at university we are to comment on every single line of code ... WRONG!!! Not documenting your code is not a sign of good coding, but rather shows arrogance, laziness and contempt for "those who would dare tamper with your code after you've written it". Document and comment your code thoroughly. Do it as you go along. I was also taught to comment nearly every line - as part of the coding style used by a large, international company I worked for several years ago. It brings the logic of the programmer into focus and makes code maintenance a whole lot easier. It also helps one to remember the logic of your own code when you revisit it a year or more hence. Jon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
-Original Message- From: profmakx.fmp [mailto:[EMAIL PROTECTED]] So, every good programmer should know where to put comments. And it is unnecessary to put comments to explain what code does. One should see this as stated in the CodingStyle doc. Ok, there are points where a comment is good, but for example at university we are to comment on every single line of code ... WRONG!!! Not documenting your code is not a sign of good coding, but rather shows arrogance, laziness and contempt for "those who would dare tamper with your code after you've written it". Document and comment your code thoroughly. Do it as you go along. I was also taught to comment nearly every line - as part of the coding style used by a large, international company I worked for several years ago. It brings the logic of the programmer into focus and makes code maintenance a whole lot easier. It also helps one to remember the logic of your own code when you revisit it a year or more hence. There is an old programmer's rule. "Documentation? Too bad. If the code was damned hard to write, it should be damned hard to understand." :) /Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Mon, Jan 22, 2001 at 11:04:50AM -0500, Jonathan Earle wrote: -Original Message- From: profmakx.fmp [mailto:[EMAIL PROTECTED]] So, every good programmer should know where to put comments. And it is unnecessary to put comments to explain what code does. One should see this as stated in the CodingStyle doc. Ok, there are points where a comment is good, but for example at university we are to comment on every single line of code ... WRONG!!! Not documenting your code is not a sign of good coding, but rather shows arrogance, laziness and contempt for "those who would dare tamper with your code after you've written it". Document and comment your code thoroughly. Do it as you go along. I was also taught to comment nearly every line - as part of the coding style used by a large, international company I worked for several years ago. It brings the logic of the programmer into focus and makes code maintenance a whole lot easier. It also helps one to remember the logic of your own code when you revisit it a year or more hence. Please don't listen to this. The only place you really want comments is a) at the top of files, describing the point of the file; b) at the top of functions, if the purpose of the function is not obvious; c) in line, when the code is not obvious. If you are writing code that requires a comment for every line, you are writing bad, obscure, unobvious code and no amount of commenting will fix it. The real reason to sparing in your comments is that code and comments are not semantically bound to each other: the program doesn't stop working when the comment becomes incorrect. It's incredibly frustrating to read a comment, believe you understand what is going on, only to find out that the comment and the code no longer match. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Mon, Jan 22, 2001 at 11:04:50AM -0500, Jonathan Earle wrote: WRONG!!! Not documenting your code is not a sign of good coding, but rather shows arrogance, laziness and contempt for "those who would dare tamper with your code after you've written it". Document and comment your code thoroughly. Do it as you go along. I was also taught to comment nearly every line - as part of the coding style used by a large, international company I worked for several years ago. It brings the logic of the programmer into focus and makes code maintenance a whole lot easier. It also helps one to remember the logic of your own code when you revisit it a year or more hence. Not wrong: You should document the interface, and any strange gotchas that you faced while writing the function (like hardware bugs, etc). Then, if the next person can't understand the code by reading it: 1. He's not qualified to change it. *OR* 2. The code is crap, it needs to be rewritten anyways, good interface documentation makes that possible. Documenting every detail just encourages people with a paper thin understanding to go and foul it up in subtile ways, it's better that they be completely clueless and screw it up obviously. Good code is simple, clean, and obvious. Sometimes, some code can't be clean because it's facing a very hard problem, all the more reason to leave it to gurus. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [OT?] Coding Style
-Original Message- From: Larry McVoy [mailto:[EMAIL PROTECTED]] On Mon, Jan 22, 2001 at 11:04:50AM -0500, Jonathan Earle wrote: -Original Message- From: profmakx.fmp [mailto:[EMAIL PROTECTED]] So, every good programmer should know where to put comments. And it is unnecessary to put comments to explain what code does. One should see this as stated in the CodingStyle doc. Ok, there are points where a comment is good, but for example at university we are to comment on every single line of code ... WRONG!!! Not documenting your code is not a sign of good coding, but rather shows arrogance, laziness and contempt for "those who would dare tamper with your code after you've written it". Document and comment your code thoroughly. Do it as you go along. I was also taught to comment nearly every line - as part of the coding style used by a large, international company I worked for several years ago. It brings the logic of the programmer into focus and makes code maintenance a whole lot easier. It also helps one to remember the logic of your own code when you revisit it a year or more hence. Please don't listen to this. The only place you really want comments is a) at the top of files, describing the point of the file; b) at the top of functions, if the purpose of the function is not obvious; c) in line, when the code is not obvious. If you are writing code that requires a comment for every line, you are writing bad, obscure, unobvious code and no amount of commenting will fix it. The point of comments is not to "fix" bad code, it's to provide understanding. As the original poster said, _you_ may understand your code, but that in no way implies that _I_ will, or your co-worker down the hall will, etc. I'm not suggesting that a statement like "counter=0;" at the start of a function be commented, but other operations should be. "Why do we want this file written in /proc - wouldn't syslog have worked better?" "Why is this loop skipping the first seven elements?" "Why is this structure used here instead of a simple array?" "What on earth does m-n-o-num represent?" The real reason to sparing in your comments is that code and comments are not semantically bound to each other: the program doesn't stop working when the comment becomes incorrect. It's incredibly frustrating to read a comment, believe you understand what is going on, only to find out that the comment and the code no longer match. Comments should be updated when code is updated. I believe that documentation is of far greater value than code itself. Code can be changed, however, logic drives the code. Without a good understanding of the latter, the former is of little value, IMHO. Cheers! Jon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Mon, 22 Jan 2001, Larry McVoy wrote: On Mon, Jan 22, 2001 at 11:04:50AM -0500, Jonathan Earle wrote: -Original Message- From: profmakx.fmp [mailto:[EMAIL PROTECTED]] So, every good programmer should know where to put comments. And it is unnecessary to put comments to explain what code does. One should see this as stated in the CodingStyle doc. Ok, there are points where a comment is good, but for example at university we are to comment on every single line of code ... WRONG!!! Not documenting your code is not a sign of good coding, but rather shows arrogance, laziness and contempt for "those who would dare tamper with your code after you've written it". Document and comment your code thoroughly. Do it as you go along. I was also taught to comment nearly every line - as part of the coding style used by a large, international company I worked for several years ago. It brings the logic of the programmer into focus and makes code maintenance a whole lot easier. It also helps one to remember the logic of your own code when you revisit it a year or more hence. Please don't listen to this. The only place you really want comments is a) at the top of files, describing the point of the file; b) at the top of functions, if the purpose of the function is not obvious; c) in line, when the code is not obvious. If you are writing code that requires a comment for every line, you are writing bad, obscure, unobvious code and no amount of commenting will fix it. The real reason to sparing in your comments is that code and comments are not semantically bound to each other: the program doesn't stop working when the comment becomes incorrect. It's incredibly frustrating to read a comment, believe you understand what is going on, only to find out that the comment and the code no longer match. -- --- Larry McVoylm at bitmover.com http://www.bitmover.com/lm Okay, I'll byte (sic)... If you are a good programmer, your code should work well and you will be writing code for new projects long before the product enters the in-production maintenance phase. This phase exists in real products during their lifetime. At this time, rather junior programmers will be required to add new capability or even fix bugs. Even excellent programmers generate bugs that are not discovered for a long time (perhaps ever). This occurs because not every code path gets tested so these bugs are not always found. For instance, the return value from a function that encounters hardware errors may not be correct because, during the entire development phase, the hardware never generated that specific error. When maintaining code, the programmer may have never seen the code before. If it takes several weeks to find the function that is returning the wrong value, and if it takes several hours to correct the problem after the function is located, then the original writer did not complete his or her job correctly. Comments should assume that the reader is expert in the language being used. No other assumptions produce useful documentation. There are many ways to document code. Not all of these ways involve comments. Examples are: (1) MACROS: Lots of programmers don't use MACROS for documentation. However they are very useful. Suppose we have a complicated single-bit sequence necessary to communicate with a SEEPROM. If the main-line code does: WRITE_SEEPROM(parameter); READ_SEEPROM(parameter); ... then the code is very clear. The MACRO can be very complicated. When it is isolated in this manner, the code both for the MACRO and the functions that expand this MACRO are better documented than just laying code. (2) Descriptive names: I don't like these myself. Often programmers get too cute. You can look at the BusLogic code and see what I am talking about. Practically every variable and function name begins with "BusLogic". However, descriptive variable and function names do help document code. This, even though many get carried away with extremes. Most everybody will recognize: for (i=0; i LIMIT; i++) ; We don't really need: for(SimpleIntegerCount=0; SimpleIntegerCount OneLessThanTheArraySize; SimpleIntegerCount++) ; But, when you are writing complicated code, it is often useful to use descriptive names that uniquely define several otherwise similar routines. For instance: Write_error_log(data); Append_error_log(data); Again, some carry this to the extreme, they take a good idea and corrupt it, MicroSoftSyle, into: WriteErrorLog(data); AppendErrorLog(data); (3) Comments: Comments are very useful if they convey useful information. Many comments are not useful because they seem to exist only because somebody made a rule that said; "You have to comment your code...". An
RE: [OT?] Coding Style
At 11:04 AM 1/22/01 -0500, you wrote:
WRONG!!!
Not documenting your code is not a sign of good coding, but rather shows
arrogance, laziness and contempt for "those who would dare tamper with your
code after you've written it". Document and comment your code thoroughly.
Do it as you go along. I was also taught to comment nearly every line - as
part of the coding style used by a large, international company I worked for
several years ago. It brings the logic of the programmer into focus and
makes code maintenance a whole lot easier. It also helps one to remember
the logic of your own code when you revisit it a year or more hence.
Oh, those who refuse to study history are doomed to repeat it.
The COBOL language was created specifically to reduce the amount of
commenting necessary in a program, because the English-like sentence
structure could be read and understood by humans. The FORTRAN language was
created so that math types could "talk" in a language more familiar to
them, letting the computer take care of the details about how to perform
the specified task step-by-step.
One goal of language designers is to REMOVE the need for comments. With a
good fourth-generation or fifth-generation language, the need for comments
diminishes to a detailed description of the data sets and any highly
unusual operations or transforms on the data.
I've even gone so far as to "invent" my own languages, and the parsers to
go with them, to reduce the need to comment by making the code easy for
humans to read. Not only are such systems easier to debug (with good
language design) but are highly maintainable and usually not all that
difficult to extend when necessary.
Remember, the line-by-line commenting requirement was mandatory in
assembler programming, because the nature of assembler made you outline
each step by tiring step. When I worked for Rockwell, I was granted a
partial wavier when I showed them my assembler-language commenting
style: pseudo-code at the top of each block of assembler code. Blindly
applying the rule to second-generation and later languages is just sloppy
management, usually by people who don't understand coding. (And yes, that
includes some professors of computer science I have known.)
Comments do NOT make code maintenance easier. Too many comments obscure
what is really going on. Linus' style actually increases the
maintainability of the code, because if the code doesn't accurately show
how it implements the goal specified in the block comment, the coder hasn't
done his/her job.
Want to improve the maintainability of C code? Consider the following:
1) Keep functional parts small. If the code won't fit in a hundred lines
or so of code, then you haven't factored the problem well
enough. Functional parts != functions. A program with thousands of
well-encapsulated function parts strung together into a single function is
easier to maintain than a "well-factored" program with its parts spread all
over hell. Diagnostic programmers have learned the hard way that factoring
a program can make it difficult to ensure test coverage and even more
difficult to determine if a part of the code is buggy or whether it found a
hardware error that it was looking for. This is why diagnostics tend to be
rather long affairs with very few functions.
In my ANSI C code, you will see the following a lot:
#define DO /*syntactic sugar */
DO {
/* first functional part, with owned variables */
}
DO {
/* next functional part, with its owned variables */
}
and so forth. The "DO" is visual syntactic sugar so that the sub-blocks
have the same appearance as other blocks, such as if, while, and for. An
added bonus to this particular style element is that compilers can more
easily detect problems if you forget to initialize the local variables, or
define variables you end up not using. This has saved me hours of tedious
debugging of my own code. From the maintenance standpoint, it means that
the definition of local variables are near all usages of it, so you don't
have to continuously page up or split-screen to see the definition (and
initialization) of "foobar_at_will".
2) Reduce visual complexity where possible. Instead of using nested
if-then-else statements, consider unrolling the nested
statement. Example: {if (a c)...; if (b c)...; instead of {if (c)
{if (a)...; if(b)...;}
This doesn't have to affect performance. For example, you can have rules
such as:
ruleset = (a ? 1 : 0) | (b ? 2 : 0) | (c ? 4 : 0);
if (ruleset == 5) {
...
}
if (ruleset == 6) {
...
}
This particular method can eliminate multiple expensive tests, and can
guarantee that a, b, and c are evaluated exactly once during a cycle. This
can improve performance. Using AND, OR, and XOR can further increase the
power of the technique without a performance hit. (For understandability,
I recommend
Re: [OT?] Coding Style
Stephen Satchell wrote:
One goal of language designers is to REMOVE the need for comments. With a
this is a crock of (deleted). You are chaising rainbows dood, you will
NEVER remove teh need for comments but its obvious you remove teh
comments.
good fourth-generation or fifth-generation language, the need for comments
diminishes to a detailed description of the data sets and any highly
unusual operations or transforms on the data.
sorry but i could not disagree more
I've even gone so far as to "invent" my own languages, and the parsers to
go with them, to reduce the need to comment by making the code easy for
humans to read. Not only are such systems easier to debug (with good
language design) but are highly maintainable and usually not all that
difficult to extend when necessary.
no lprogramming anguage can describe describe the design of the
applications written in it. you NEED to comment your code. 100% Self
commenting code is a falacy. 50% self commenting code is almost
impossible to achieve. COMMENT IT!
Remember, the line-by-line commenting requirement was mandatory in
assembler programming, because the nature of assembler made you outline
each step by tiring step.
You talk like you dislike assembler as much as i dislike c :)
When I worked for Rockwell, I was granted a
partial wavier when I showed them my assembler-language commenting
style: pseudo-code at the top of each block of assembler code.
very ugly. The S4 meter from landys and gyr (now siemens) actually uses
c code above each assembler routine as a form of commeting. using code
to comment code is fine as long as you COMMENT the comments!
Comments do NOT make code maintenance easier. Too many comments obscure
what is really going on.
well... i disagree, years of consulting work and having to deal with
hunks of legacy code with no comments and huge functions etc etc et
(every coders worst nightmare) has taught me that comments are very much
needed (even bad comments are preferable to none at all)
Linus' style actually increases the
maintainability of the code, because if the code doesn't accurately show
how it implements the goal specified in the block comment, the coder hasn't
done his/her job.
TRUE. Code should be written well enough that it isnt naturally
obfuscated but this does NOT remove the need for comments.
Want to improve the maintainability of C code? Consider the following:
1) Keep functional parts small. If the code won't fit in a hundred lines
or so of code, then you haven't factored the problem well
enough. Functional parts != functions.
A program with thousands of
well-encapsulated function parts strung together into a single function is
easier to maintain than a "well-factored" program with its parts spread all
over hell.
Cram a gazillion simple operations into a single function and you end up
with chaos, totally unfactored code is almost impossible to read.
Diagnostic programmers have learned the hard way that factoring
a program can make it difficult to ensure test coverage and even more
difficult to determine if a part of the code is buggy or whether it found a
hardware error that it was looking for.
then they dont know how to test a program. period
In my ANSI C code, you will see the following a lot:
#define DO /*syntactic sugar */
DO {
/* first functional part, with owned variables */
}
DO {
/* next functional part, with its owned variables */
}
2) Reduce visual complexity where possible. Instead of using nested
if-then-else statements, consider unrolling the nested
statement. Example: {if (a c)...; if (b c)...; instead of {if (c)
{if (a)...; if(b)...;}
which is simpler...
(x + y) ^ 2
or...
(x ^2) + (Y ^2) + 2xy
3) Make creative use of a run-on if statement to improve error detection
and recording. One of my tricks is to code the following statement in
application programs:
if( (err = "input file can't be opened", in = fopen(filename,
"rb"), in == NULL)
|| (err = "output file can't be opened", out = fopen(oname, "wb"),
out = NULL)
...
)
use clever little tricks in your c so as to confuse people ? You are
obviously a very advanced c coder who knows well the intracasies of the
language. The person who has to maintain your code 10 years after you
have left may not be.
{
/* report the error that occurred, using the char * variable "err"
to indicate the exact error. */
}
granted, the above block of code was not that difficult to understand,
even tho I have never seen that particular trick used before but the
above statement still stands. (nice trick btw :)
4) The functional part should be contained in a reasonable number of
lines. Large while and for loops should call functions instead of having
bloated bodies. Large case statements should call
Re: [OT?] Coding Style
Please don't listen to this. The only place you really want comments is a) at the top of files, describing the point of the file; b) at the top of functions, if the purpose of the function is not obvious; c) in line, when the code is not obvious. If you are writing code that requires a comment for every line, you are writing bad, obscure, unobvious code and no amount of commenting will fix it. or 1) your code-viewing audience is a bunch of 5 year olds 2) the person reading the code isn't a 'qualified' programmer. If they were, they'd most likely be able to understand the code without hand-holding of that magnitude. We don't write code for idiots. -Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] Intergrafix Internet Services "Dream as if you'll live forever, live as if you'll die today" http://www.asteroid-b612.orghttp://www.intergrafix.net .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Mon, Jan 22, 2001 at 11:56:40PM +, Anton Altaparmakov wrote:
At 16:42 22/01/2001, Mark I Manning IV wrote:
Stephen Satchell wrote:
I got in the habit of using
structures to minimize the number of symbols I exposed. It also
disambiguates local variables and parameters from file- and program-global
variables.
explain this one to me, i think it might be usefull...
What might be meant is that instead of declaring variables my_module_var1,
my_module_var2, my_module_var3, etc. you declare a struct my_module { var1;
var2; var3; etc. }. Obviously in glorious technicolour formatting... (-;
That's my interpretation anyway...
Mine too and I think it's a good idea. I have code in BitKeeper where I
both did and did not do that for command line options and I much prefer
the structure version.
Another habit I used to use and have fallen out of, which is a bad idea, is
one where you use a prefix in stucture files so that you can see
the difference between
p-st_mode
and
p-f_mode
In other words, the prefix implies the structure name. Early versions of the
C compiler had all structure fields (I mean _all_) in one name space so this
wasn't style, it was required. I must say that it makes code more readable.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Admin Mailing Lists wrote: hand-holding of that magnitude. We don't write code for idiots. But if you have to, you can at least enjoy it: - diversity makes life interesting: use switch() with local variables or without curly braces - de-referencing is like a hotel: the more stars, the better - observe proper punctuation: use the comma operator frequently - know thy C: few people know that 5[x] is valid, but they can usually guess what it does. They probably won't get x[5[y]], though. - know thy CPP: nest macros and exercise token-concatenation and stingification - if your code allows you to, put #define while if in some header file - Werner (couldn't resist ;-) -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
At 11:56 PM 1/22/01 +, Anton Altaparmakov wrote:
At 16:42 22/01/2001, Mark I Manning IV wrote:
Stephen Satchell wrote:
I got in the habit of using
structures to minimize the number of symbols I exposed. It also
disambiguates local variables and parameters from file- and program-global
variables.
explain this one to me, i think it might be usefull...
What might be meant is that instead of declaring variables my_module_var1,
my_module_var2, my_module_var3, etc. you declare a struct my_module {
var1; var2; var3; etc. }. Obviously in glorious technicolour formatting... (-;
That's my interpretation anyway...
The first sentence is right on the money. In addition to module variables,
I define a global structure as:
extern struct G {
/* the real globals */
} g;
and then in the main program I define the instance as "struct G g;" This
is more for apps than operating systems.
Further to the avoidance of pollution of the external global namespace, I
define local functions as static. Indeed, in one parser I had over 1400
very small functions, none of them with external scope. Instead, I defined
a structure of function pointers and exposed one name to the rest of the
world. Sound stupid? Well, that stupidity had its place: the "opcode" in
the pseudo-instruction stream was the offset into this structure of
pointers to the pointer of interest, which made the main loop for the
parser about five lines long, and not a switch statement to be seen. Three
of those lines were to handle unknown-opcodes...
I also am partial to arrays of function pointers when appropriate. Ever
think how easy it would be to implement a TCP stack that would handle the
"lamp-test packet" as a single special case? Granted, it results in a
small amount of code bloat over the traditional in-line test method, but it
does make you think about EVERY SINGLE ONE OF THE 64 COMBINATIONS of
Urg/Ack/Psh/Rst/Syn/Fin (to use the labels from the 1985 version of RFC
793) and what they really mean. Especially the combination with all bits set.
Satch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
well, i watched monty python and the holy grail once (had to find out what everyone was all excited about) couldn't get into it, watched maybe 1/2 of it. -Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] Intergrafix Internet Services "Dream as if you'll live forever, live as if you'll die today" http://www.asteroid-b612.orghttp://www.intergrafix.net .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. On Sun, 21 Jan 2001, Mo McKinlay wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Today, Admin Mailing Lists ([EMAIL PROTECTED]) wrote: > > > > And the lord spake, saying, "First shalt thou write thy holy code. Indenting > > > shalt thou count to three, no more, no less. Three shalt be the spaces thou > > > shalt count, and the number of the counting shalt be three. Four shalt thou > > > not count, nor count thou two, excepting that thou then proceedeth to three. > > > Eight is right out. Once the number three, being the third number be > > > reached, shalt thou move towards indenting thy next line .. > > > now I know why I never read the bible. > > ..or Monty Python... > > - -- > Mo McKinlay > [EMAIL PROTECTED] > - - > GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 > > > > > > > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.4 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iEYEARECAAYFAjprZWUACgkQRcGgB3aidfnz0gCgqOGt7dg3cZH/uDz0Vpe/P9Fe > ALsAn2y2L/D9e1QRWTb6jDSM+kvsrShr > =3D28 > -END PGP SIGNATURE- > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Admin Mailing Lists ([EMAIL PROTECTED]) wrote: > > And the lord spake, saying, "First shalt thou write thy holy code. Indenting > > shalt thou count to three, no more, no less. Three shalt be the spaces thou > > shalt count, and the number of the counting shalt be three. Four shalt thou > > not count, nor count thou two, excepting that thou then proceedeth to three. > > Eight is right out. Once the number three, being the third number be > > reached, shalt thou move towards indenting thy next line .. > now I know why I never read the bible. ..or Monty Python... - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjprZWUACgkQRcGgB3aidfnz0gCgqOGt7dg3cZH/uDz0Vpe/P9Fe ALsAn2y2L/D9e1QRWTb6jDSM+kvsrShr =3D28 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Admin Mailing Lists ([EMAIL PROTECTED]) wrote: And the lord spake, saying, "First shalt thou write thy holy code. Indenting shalt thou count to three, no more, no less. Three shalt be the spaces thou shalt count, and the number of the counting shalt be three. Four shalt thou not count, nor count thou two, excepting that thou then proceedeth to three. Eight is right out. Once the number three, being the third number be reached, shalt thou move towards indenting thy next line .. now I know why I never read the bible. ..or Monty Python... - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjprZWUACgkQRcGgB3aidfnz0gCgqOGt7dg3cZH/uDz0Vpe/P9Fe ALsAn2y2L/D9e1QRWTb6jDSM+kvsrShr =3D28 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
well, i watched monty python and the holy grail once (had to find out what everyone was all excited about) couldn't get into it, watched maybe 1/2 of it. -Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] Intergrafix Internet Services "Dream as if you'll live forever, live as if you'll die today" http://www.asteroid-b612.orghttp://www.intergrafix.net .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. On Sun, 21 Jan 2001, Mo McKinlay wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Admin Mailing Lists ([EMAIL PROTECTED]) wrote: And the lord spake, saying, "First shalt thou write thy holy code. Indenting shalt thou count to three, no more, no less. Three shalt be the spaces thou shalt count, and the number of the counting shalt be three. Four shalt thou not count, nor count thou two, excepting that thou then proceedeth to three. Eight is right out. Once the number three, being the third number be reached, shalt thou move towards indenting thy next line .. now I know why I never read the bible. ..or Monty Python... - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjprZWUACgkQRcGgB3aidfnz0gCgqOGt7dg3cZH/uDz0Vpe/P9Fe ALsAn2y2L/D9e1QRWTb6jDSM+kvsrShr =3D28 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Sun, 21 Jan 2001, Admin Mailing Lists wrote: > > And the lord spake, saying, "First shalt thou write thy holy code. Indenting > > shalt thou count to three, no more, no less. Three shalt be the spaces thou > > shalt count, and the number of the counting shalt be three. Four shalt thou > > not count, nor count thou two, excepting that thou then proceedeth to three. > > Eight is right out. Once the number three, being the third number be > > reached, shalt thou move towards indenting thy next line .. > > > > now I know why I never read the bible. I thought that was the indention rules for Python. ]:> [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
We would never parody Monty Python! This is an excerpt from Judas, one of the gospels that was in dispute. I'm sorry, I must go, as there's a man in a military uniform here, shouting at me to stop being silly... -josh On Sat, 20 Jan 2001 23:58:07 Mike A. Harris wrote: > On Sun, 21 Jan 2001, Admin Mailing Lists wrote: > > >> And the lord spake, saying, "First shalt thou write thy holy code. . > If I'm not mistaken, the above is a parody on Monty Python's Holy > Grail. The Holy Hand Grenade of Antinoch if I'm correct. It's > been a while.. > . (i modified Mike's copyrighted document. do i need to get a license from all of the people he quoted as well as his? ;^) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Sun, 21 Jan 2001, Admin Mailing Lists wrote: >> And the lord spake, saying, "First shalt thou write thy holy code. Indenting >> shalt thou count to three, no more, no less. Three shalt be the spaces thou >> shalt count, and the number of the counting shalt be three. Four shalt thou >> not count, nor count thou two, excepting that thou then proceedeth to three. >> Eight is right out. Once the number three, being the third number be >> reached, shalt thou move towards indenting thy next line .. >> > >now I know why I never read the bible. > >people jsut dont know how old cryptography really is ;-) If I'm not mistaken, the above is a parody on Monty Python's Holy Grail. The Holy Hand Grenade of Antinoch if I'm correct. It's been a while.. -- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2001, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- The day Microsoft makes something that doesn't suck, is probably the day Microsoft starts making vacuum cleaners. -- Ernst Jan Plugge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Sun, 21 Jan 2001, Ragnar Hojland Espinosa wrote: > On Sat, Jan 20, 2001 at 05:19:17PM +0100, [EMAIL PROTECTED] wrote: > > I just wanted to say that Linus´ CodingStyle is the ONLY SANE style of > > writing code in bigger projects. At university we are forced to use exactly the > > And the lord spake, saying, "First shalt thou write thy holy code. Indenting > shalt thou count to three, no more, no less. Three shalt be the spaces thou > shalt count, and the number of the counting shalt be three. Four shalt thou > not count, nor count thou two, excepting that thou then proceedeth to three. > Eight is right out. Once the number three, being the third number be > reached, shalt thou move towards indenting thy next line .. > now I know why I never read the bible. people jsut dont know how old cryptography really is ;-) -Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] Intergrafix Internet Services "Dream as if you'll live forever, live as if you'll die today" http://www.asteroid-b612.orghttp://www.intergrafix.net .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Sat, Jan 20, 2001 at 05:19:17PM +0100, [EMAIL PROTECTED] wrote: > I just wanted to say that Linus´ CodingStyle is the ONLY SANE style of > writing code in bigger projects. At university we are forced to use exactly the And the lord spake, saying, "First shalt thou write thy holy code. Indenting shalt thou count to three, no more, no less. Three shalt be the spaces thou shalt count, and the number of the counting shalt be three. Four shalt thou not count, nor count thou two, excepting that thou then proceedeth to three. Eight is right out. Once the number three, being the third number be reached, shalt thou move towards indenting thy next line .. .. ;) -- /| Ragnar Højland Freedom - Linux - OpenGL Fingerprint 94C4B \ o.O| 2F0D27DE025BE2302C =(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822 U chaos and madness await thee at its end." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Hi I just wanted to say that Linus´ CodingStyle is the ONLY SANE style of writing code in bigger projects. At university we are forced to use exactly the braindamaged settings and styles that linux condemns. So, every good programmer should know where to put comments. And it is unnecessary to put comments to explain what code does. One should see this as stated in the CodingStyle doc. Ok, there are points where a comment is good, but for example at university we are to comment on every single line of code ... So back to work now! Markus -- Sent through GMX FreeMail - http://www.gmx.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
Hi I just wanted to say that Linus CodingStyle is the ONLY SANE style of writing code in bigger projects. At university we are forced to use exactly the braindamaged settings and styles that linux condemns. So, every good programmer should know where to put comments. And it is unnecessary to put comments to explain what code does. One should see this as stated in the CodingStyle doc. Ok, there are points where a comment is good, but for example at university we are to comment on every single line of code ... So back to work now! Markus -- Sent through GMX FreeMail - http://www.gmx.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Sat, Jan 20, 2001 at 05:19:17PM +0100, [EMAIL PROTECTED] wrote: I just wanted to say that Linus CodingStyle is the ONLY SANE style of writing code in bigger projects. At university we are forced to use exactly the And the lord spake, saying, "First shalt thou write thy holy code. Indenting shalt thou count to three, no more, no less. Three shalt be the spaces thou shalt count, and the number of the counting shalt be three. Four shalt thou not count, nor count thou two, excepting that thou then proceedeth to three. Eight is right out. Once the number three, being the third number be reached, shalt thou move towards indenting thy next line .. .. ;) -- /| Ragnar Hjland Freedom - Linux - OpenGL Fingerprint 94C4B \ o.O| 2F0D27DE025BE2302C =(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822 U chaos and madness await thee at its end." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Sun, 21 Jan 2001, Ragnar Hojland Espinosa wrote: On Sat, Jan 20, 2001 at 05:19:17PM +0100, [EMAIL PROTECTED] wrote: I just wanted to say that Linus´ CodingStyle is the ONLY SANE style of writing code in bigger projects. At university we are forced to use exactly the And the lord spake, saying, "First shalt thou write thy holy code. Indenting shalt thou count to three, no more, no less. Three shalt be the spaces thou shalt count, and the number of the counting shalt be three. Four shalt thou not count, nor count thou two, excepting that thou then proceedeth to three. Eight is right out. Once the number three, being the third number be reached, shalt thou move towards indenting thy next line .. now I know why I never read the bible. people jsut dont know how old cryptography really is ;-) -Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] Intergrafix Internet Services "Dream as if you'll live forever, live as if you'll die today" http://www.asteroid-b612.orghttp://www.intergrafix.net .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Sun, 21 Jan 2001, Admin Mailing Lists wrote: And the lord spake, saying, "First shalt thou write thy holy code. Indenting shalt thou count to three, no more, no less. Three shalt be the spaces thou shalt count, and the number of the counting shalt be three. Four shalt thou not count, nor count thou two, excepting that thou then proceedeth to three. Eight is right out. Once the number three, being the third number be reached, shalt thou move towards indenting thy next line .. now I know why I never read the bible. people jsut dont know how old cryptography really is ;-) If I'm not mistaken, the above is a parody on Monty Python's Holy Grail. The Holy Hand Grenade of Antinoch if I'm correct. It's been a while.. -- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2001, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- The day Microsoft makes something that doesn't suck, is probably the day Microsoft starts making vacuum cleaners. -- Ernst Jan Plugge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
We would never parody Monty Python! This is an excerpt from Judas, one of the gospels that was in dispute. I'm sorry, I must go, as there's a man in a military uniform here, shouting at me to stop being silly... -josh On Sat, 20 Jan 2001 23:58:07 Mike A. Harris wrote: On Sun, 21 Jan 2001, Admin Mailing Lists wrote: And the lord spake, saying, "First shalt thou write thy holy code. . If I'm not mistaken, the above is a parody on Monty Python's Holy Grail. The Holy Hand Grenade of Antinoch if I'm correct. It's been a while.. . (i modified Mike's copyrighted document. do i need to get a license from all of the people he quoted as well as his? ;^) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
On Sun, 21 Jan 2001, Admin Mailing Lists wrote: And the lord spake, saying, "First shalt thou write thy holy code. Indenting shalt thou count to three, no more, no less. Three shalt be the spaces thou shalt count, and the number of the counting shalt be three. Four shalt thou not count, nor count thou two, excepting that thou then proceedeth to three. Eight is right out. Once the number three, being the third number be reached, shalt thou move towards indenting thy next line .. now I know why I never read the bible. I thought that was the indention rules for Python. ]: [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
