DoDont series I: comment style I 
Author Message
 DoDont series I: comment style I

DoDont Series-1

Any comments, including {*filter*} threat, will be welcome.  So feel
free to make a comment regarding my following statements.

[1].  Comment Style

1. Don't use // comment style in a C program. Because // comment
style is not accepted as a standard and because, when you used
the // comment style and when you tried to print your source code
using a black and white laser printer, by the appearance of the
'//' characters, you will have a little hard time to get a notion
that the trailing char's following the '//' are the comments.  If
you use '/*' and '*/' sets instead, easily you can get a notion
that the char's between '/*' and '*/' are the comments.

For example, if you have printed following code using black/white
laser printer, I mean, you should spend a little time to
discriminate comment parts from non-comments parts due to the
intrinsic appearance of the '//' chars.

=====
//
// The strchr() function returns a pointer to the first occurrence
// of the character c in the string s.
//

char *
strchr(const char * s, int c)
{
        for(; *s != (char) c; ++s) // this is a comment
                if (*s == '\0') // this is another comment
                        return NULL;
        return (char *) s;

Quote:
}

=====
/*
 * The strchr() function returns a pointer to the first occurrence
 * of the character c in the string s.
 */
char *
strchr(const char * s, int c)
{
        for(; *s != (char) c; ++s) /* this is a comment */
                if (*s == '\0') /* this is another comment */
                        return NULL;
        return (char *) s;
Quote:
}

====

2. Dont make useless, futile, or strange looking, block comments.

I recommend the following comment style as a template.

[DO]
/*
 * The strchr() function returns a pointer to the first occurrence
 * of the character c in the string s.
 */

However, don't use tab char's in the block comment whenever
possible.  I mean you should not insert tab char before the
'The strchr() function' part of the following block comment
like following.

[DONT]
/*
 *      The strchr() function returns a pointer to the first
 *      occurrence of the character c in the string s.
 */

Also, Do make the block comment utilize the full line, usually
80-column.  By fully utilizing the 80 column, we can also use
this block comment as a separator which discriminates one function
from another function.   Therefore, I mean, dont make following
block comment.

[DONT]
/*
 * The strchr() function returns a pointer to
 * the first occurrence of the character c in
 * the string s.
 */

I met following block comments many years ago.  I hate these styles.
So I DO NOT recommend following comment styles.

[DONT]
/*
** The strchr() function returns a pointer to the first occurrence
** of the character c in the string s.
**/

[DONT]
/* */
/* The strchr() function returns a pointer to the first */
/* occurrence of the character c in the string s. */
/* */

[DONT]
/*
 The strchr() function returns a pointer to the first occurrence
 of the character c in the string s.
 */

[DONT]
/* The strchr() function returns a pointer to the first       */
/* occurrence of the character c in the string s.             */

[DONT]
/* The strchr() function returns a pointer to the first */
/* occurrence of the character c in the string s. */

[DONT]
/*
; The strchr() function returns a pointer to the first occurrence
; of the character c in the string s.
*/

[DONT]
/********************************************************/
/* The strchr() function returns a pointer to the first */
/* occurrence of the character c in the string s.       */
/********************************************************/

[DONT]
/********************************************************\
 * The strchr() function returns a pointer to the first *
 * occurrence of the character c in the string s.       *
\********************************************************/

[DONT]
/*******************************************************
 The strchr() function returns a pointer to the first
 occurrence of the character c in the string s.
*******************************************************/

[DONT]
/*=====================================================
 The strchr() function returns a pointer to the first
 occurrence of the character c in the string s.
 =====================================================*/

Let me give me a chance to talk about the 1-line comment.

I recommend following one.

[DO]
/* The strchr() returns a pointer to the first of c */

However whenever possible, dont insert tab char in above line.

[DONT]
/*      The strchr() returns a pointer to the first of c */

Please make '*/' char's follow the comment line immediately.
I mean, dont make following line.

[DONT]
/* The strchr() returns a pointer to the first of c       */



Sun, 30 Sep 2001 03:00:00 GMT  
 DoDont series I: comment style I

An interesting post, full of sense.

[snip]

Quote:
> don't use tab char's in the block comment whenever possible.

Prompted by your comment but not really in reply to it: if the program is
to be distributed for various systems, it may be a good idea to leave tab
characters out of the source code entirely. Tab stops tend to vary between
different editors and development environments. There are usually ways of
replacing a tab with the appropriate number of spaces (and converting back
again). I would say it is neater to replace tabs with spaces before
distributing source code. The source code formatting would then only go
wrong if viewed with some proportionally spaced typefaces, and these seem
to be rare for coding.

Obviously, any raw tab in a string literal should by changed to \t before
replacing tabs with spaces. \t should be used in any case, for clarity.

[snip]

Quote:
> Also, Do make the block comment utilize the full line, usually
> 80-column. By fully utilizing the 80 column, we can also use this block
> comment as a separator which discriminates one function from another
> function.

[snip]

I think there is a reasonable argument for using about 72 columns, to give
some space for margins and/or line numbers. Consider using the vi editor
with ":set number", or preparing to print with "pr -n" under Unix. If the
source code itself uses 80 columns, you'll run out of space, unless you
use a wider window for the editor or smaller font for the printout, and
neither of these is always possible.

Daniel Barker.



Sun, 30 Sep 2001 03:00:00 GMT  
 DoDont series I: comment style I

What Extreme Pleasure do u get to post this thing again and again
!!!!!!!!!!!!!!!!!!!!!

Ranjan



Sun, 30 Sep 2001 03:00:00 GMT  
 DoDont series I: comment style I

: DoDont Series-1

: [1].  Comment Style

< snip >

Comments are so few and far between in the real-world
programs I've encountered, that, personally, I welcome
them no matter what the style.  It's the content that
counts.  In my view, instead of your picayune harping
on style, you should just say, "thank you" for any
comments you get in a program.

-- Wetboy



Sun, 30 Sep 2001 03:00:00 GMT  
 DoDont series I: comment style I
hunsoo schrieb:

Quote:

> DoDont Series-1

> Any comments, including {*filter*} threat, will be welcome.  So feel
> free to make a comment regarding my following statements.

Ok, here we go:   *** I'll kill you if you post this yet again ***

Quote:
> [1].  Comment Style

> 1. Don't use // comment style in a C program. Because // comment
> style is not accepted as a standard

This should be sufficient reason, but might be expanded on: the ANSI-C
language does not support the "//" comment. It is reported as a syntax
error by many C compilers.

You might also explain that the next revision of the C language standard
(currently called C9X) will OTOH allow and support the "//" comment.

Quote:
> and because, when you used
> the // comment style and when you tried to print your source code
> using a black and white laser printer, by the appearance of the
> '//' characters, you will have a little hard time to get a notion
> that the trailing char's following the '//' are the comments.

I would not base my commenting style on the printing characteristics of
some laser printer device. Where they are allowd, in C++ for instance, the
"//" comments are a good and readable commenting tool. Especially as end
of line comments.

Quote:
> For example, if you have printed following code using black/white
> laser printer, I mean, you should spend a little time to
> discriminate comment parts from non-comments parts due to the
> intrinsic appearance of the '//' chars.

You really go off on that laser printer issue. Don't ! Get a different
printer are use a nice monospaced font.

Quote:
> char *
> strchr(const char * s, int c)
> {
>         for(; *s != (char) c; ++s) // this is a comment
>                 if (*s == '\0') // this is another comment

If you really want to use end of line comments yu will find that they
become more readable if you align them to a certain columns. Especially if
they relate to each other in some way:

 for ( ; *s != (char) c ; ++s ) // this is a comment
    if ( *s == '\0' )           // this is another comment
                                // spaces changed for improved readability

Tip: when printing code it really pays to use a monospaced font.

Quote:
> 2. Dont make useless, futile, or strange looking, block comments.

> I recommend the following comment style as a template.

> [DO]
> /*
>  * The strchr() function returns a pointer to the first occurrence
>  * of the character c in the string s.
>  */

That's ok and has a nice thin look. Here's how I would do it, though:

 /*
 ** The strchr() function returns a pointer to the first occurrence
 ** of the character c in the string s.
 */

Quote:
> However, don't use tab char's in the block comment whenever
> possible.  I mean you should not insert tab char before the
> 'The strchr() function' part of the following block comment
> like following.

Oh, this depends. Using spaces for formatting is a nice thing, but TABs
can be useful as well. But their usage must be well defined and well
documented. For instance with the current project I work on TAB positions
are defined as being every 4 characters. This is dosumented as part of the
programming styles manual. So everyone knows that the code can only be
read as expected if the viewer or editor or printer is set up with that
specific TAB setting.

Quote:
> [DONT]
> /*
>  *      The strchr() function returns a pointer to the first
>  *      occurrence of the character c in the string s.
>  */

This indeed looks silly. But it looks similarely silly if you use spaces
instead of TABs.

Quote:
> Also, Do make the block comment utilize the full line, usually
> 80-column.

I would never use the full 80 columns, because this confuses some viewers
and printers. I usually use 78 characters. Others use even less. 72
characters is quite popular.

Quote:
> By fully utilizing the 80 column, we can also use
> this block comment as a separator which discriminates one function
> from another function.

But you do not always need a brute force separator, therefore your advice
is way too strict. Format the comment as a separator *only* if you really
need a big separator at a specific point in the code.

Quote:
> [DONT]
> /*
>  * The strchr() function returns a pointer to
>  * the first occurrence of the character c in
>  * the string s.
>  */

I do not agree with the hard "DONT", as I explained above. The above form
is OK for normal in code comments, for instance when explaining the
specifics of some more complex loop.

Quote:
> I hate these styles.
> So I DO NOT recommend following comment styles.

> [DONT]
> /*
> ** The strchr() function returns a pointer to the first occurrence
> ** of the character c in the string s.
> **/

The only thing I don't like about the above comment is the "**/" line. And
maybe some advice on diplomacy is in order here. Do not try to force other
programmers to do something your way, simply because you like some things
and hate others. At least try to give good explanations. But it's even
better to leave some room for personal style. What's most important about
comments is that they have a well structures and recognizable appearance
throughout the code and (even more important) that the texts are really
good. They should explain the code, not repeat it with other words.

Quote:
> [DONT]
> /* */
> /* The strchr() function returns a pointer to the first */
> /* occurrence of the character c in the string s. */
> /* */

> [DONT]
> /*
>  The strchr() function returns a pointer to the first occurrence
>  of the character c in the string s.
>  */

> [DONT]
> /* The strchr() function returns a pointer to the first       */
> /* occurrence of the character c in the string s.             */

In all these cases I would say: and why not ? If they are used
*consistenly* in the same form they are OK and serve their purpose very
well. It just gets bad (for readability) if you start mixing different
commenting styles within one piece of code or one project.

Quote:
> [DONT]
> /* The strchr() function returns a pointer to the first */
> /* occurrence of the character c in the string s. */

That indeed looks very strange from an esthetic point of view.

Quote:
> [DONT]
> /*
> ; The strchr() function returns a pointer to the first occurrence
> ; of the character c in the string s.
> */

That a novel idea that looks quite funny. It reminds me of an assembler
programmer who has discovered C only recently :-)

[snipped the rest]

I object to most of the "DONT" qualifications that you give, because it's
way to restrictive. If someone feels happy with one of those styles and
uses it consistently throughout the code I think that is excellent. He has
understood the important concept of providing well structured comments.
Now all that remains is to hope that the texts are good.

Quote:
> Let me give me a chance to talk about the 1-line comment.

Nope. I think I've had it with comments. The form is not as important as
you may feel. You seem to put more emphasis on the form than on the
contents. That's not good.

Stephan
(initiator of the campaign against grumpiness in c.l.c)
(-: A brandnew excellent FAQ version has been released !!! :-)
(-: Get it: http://www.*-*-*.com/ ~scs/C-faq/versions.html :-)



Sun, 30 Sep 2001 03:00:00 GMT  
 DoDont series I: comment style I

  >> and because, when you used the // comment style and when you tried
  >> to print your source code using a black and white laser printer, by
  >> the appearance of the '//' characters, you will have a little hard
  >> time to get a notion that the trailing char's following the '//'
  >> are the comments.

  sw> I would not base my commenting style on the printing
  sw> characteristics of some laser printer device.

Indeed!  How ludicrous.

If you're concerned about this simply go get any one of a number of
excellent, _free_ tools for pretty-printing code, like genscript (GNU
enscript) or a2ps (also a GNU tool).  Then your comments will all appear
in an italic variable-width font or something, and it's simple to see
them.

  ftp://ftp.gnu.org/gnu/

--
-------------------------------------------------------------------------------

 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.



Sun, 30 Sep 2001 03:00:00 GMT  
 DoDont series I: comment style I
: hunsoo schrieb:
: >
: > DoDont Series-1
: >
: > Any comments, including {*filter*} threat, will be welcome.  So feel
: > free to make a comment regarding my following statements.

: Ok, here we go:   *** I'll kill you if you post this yet again ***

: > [1].  Comment Style
: >
: > 1. Don't use // comment style in a C program. Because // comment
: > style is not accepted as a standard

: This should be sufficient reason, but might be expanded on: the ANSI-C
: language does not support the "//" comment. It is reported as a syntax
: error by many C compilers.

And they are a royal pain to convert.  I keep meaning to write a
script to do it.

Will



Sun, 30 Sep 2001 03:00:00 GMT  
 DoDont series I: comment style I
I'm not really sure why you wrote this.  In at least one place, you clearly
say, "I hate these styles.  So I DO NOT recommend following comment
styles..."  Everyone has a style preference and I consistently use 3 that
you hate.

/* ------------------------------------------------------
   I use this style with dashes going to the 70th column
   to comment on my functions.
   ------------------------------------------------------ */

/* I use this style which I like very  */
/* much.  Also I usually extend this   */
/* from the current indentation to the */
/* 70th column.  I usually use this    */
/* inside program functions.           */

/* I've been playing around with this style
 * for a while to see how I like it. */

For those of you wondering about the 70th column thing, that's just my
preference.  There's no real logic to it at all.

What is pleasant to one, is not pleasant to another.  Personally, I don't
care which style most people use.  I have far more complaints about the
placement of braces, spacing within statements, and using the tab character
instead of spaces.  If I could get programmers to do one thing (related to
style) it would be for them to turn off tab insertion as soon as they get a
new text editor.  Better still, I would make the default for all text
editors to insert spaces instead of tabs.  Also, pick and indentation scheme
and stick with it.

--
Increase the Peace!
Charles LaCour

Quote:

>DoDont Series-1

>Any comments, including {*filter*} threat, will be welcome.  So feel
>free to make a comment regarding my following statements.

>[1].  Comment Style

>1. Don't use // comment style in a C program. Because // comment
>style is not accepted as a standard and because, when you used
>the // comment style and when you tried to print your source code
>using a black and white laser printer, by the appearance of the
>'//' characters, you will have a little hard time to get a notion
>that the trailing char's following the '//' are the comments.  If
>you use '/*' and '*/' sets instead, easily you can get a notion
>that the char's between '/*' and '*/' are the comments.

>For example, if you have printed following code using black/white
>laser printer, I mean, you should spend a little time to
>discriminate comment parts from non-comments parts due to the
>intrinsic appearance of the '//' chars.

>=====
>//
>// The strchr() function returns a pointer to the first occurrence
>// of the character c in the string s.
>//

>char *
>strchr(const char * s, int c)
>{
>        for(; *s != (char) c; ++s) // this is a comment
>                if (*s == '\0') // this is another comment
>                        return NULL;
>        return (char *) s;
>}

>=====
>/*
> * The strchr() function returns a pointer to the first occurrence
> * of the character c in the string s.
> */
>char *
>strchr(const char * s, int c)
>{
>        for(; *s != (char) c; ++s) /* this is a comment */
>                if (*s == '\0') /* this is another comment */
>                        return NULL;
>        return (char *) s;
>}
>====

>2. Dont make useless, futile, or strange looking, block comments.

>I recommend the following comment style as a template.

>[DO]
>/*
> * The strchr() function returns a pointer to the first occurrence
> * of the character c in the string s.
> */

>However, don't use tab char's in the block comment whenever
>possible.  I mean you should not insert tab char before the
>'The strchr() function' part of the following block comment
>like following.

>[DONT]
>/*
> *      The strchr() function returns a pointer to the first
> *      occurrence of the character c in the string s.
> */

>Also, Do make the block comment utilize the full line, usually
>80-column.  By fully utilizing the 80 column, we can also use
>this block comment as a separator which discriminates one function
>from another function.   Therefore, I mean, dont make following
>block comment.

>[DONT]
>/*
> * The strchr() function returns a pointer to
> * the first occurrence of the character c in
> * the string s.
> */

>I met following block comments many years ago.  I hate these styles.
>So I DO NOT recommend following comment styles.

>[DONT]
>/*
>** The strchr() function returns a pointer to the first occurrence
>** of the character c in the string s.
>**/

>[DONT]
>/* */
>/* The strchr() function returns a pointer to the first */
>/* occurrence of the character c in the string s. */
>/* */

>[DONT]
>/*
> The strchr() function returns a pointer to the first occurrence
> of the character c in the string s.
> */

>[DONT]
>/* The strchr() function returns a pointer to the first       */
>/* occurrence of the character c in the string s.             */

>[DONT]
>/* The strchr() function returns a pointer to the first */
>/* occurrence of the character c in the string s. */

>[DONT]
>/*
>; The strchr() function returns a pointer to the first occurrence
>; of the character c in the string s.
>*/

>[DONT]
>/********************************************************/
>/* The strchr() function returns a pointer to the first */
>/* occurrence of the character c in the string s.       */
>/********************************************************/

>[DONT]
>/********************************************************\
> * The strchr() function returns a pointer to the first *
> * occurrence of the character c in the string s.       *
>\********************************************************/

>[DONT]
>/*******************************************************
> The strchr() function returns a pointer to the first
> occurrence of the character c in the string s.
>*******************************************************/

>[DONT]
>/*=====================================================
> The strchr() function returns a pointer to the first
> occurrence of the character c in the string s.
> =====================================================*/

>Let me give me a chance to talk about the 1-line comment.

>I recommend following one.

>[DO]
>/* The strchr() returns a pointer to the first of c */

>However whenever possible, dont insert tab char in above line.

>[DONT]
>/*      The strchr() returns a pointer to the first of c */

>Please make '*/' char's follow the comment line immediately.
>I mean, dont make following line.

>[DONT]
>/* The strchr() returns a pointer to the first of c       */



Sun, 30 Sep 2001 03:00:00 GMT  
 DoDont series I: comment style I

| DoDont Series-1
|
| Any comments, including {*filter*} threat, will be welcome.  So feel
| free to make a comment regarding my following statements.
|
| [1].  Comment Style

      /*                  ###
     #   #   #             #             #    #    ##    #    #  ######
    #     # #              #             #    #   #  #   #    #  #
   #    #######            #             ######  #    #  #    #  #####
  #       # #              #             #    #  ######  #    #  #
 #       #   #             #             #    #  #    #   #  #   #
#                         ###            #    #  #    #    ##    ######

         #   #           #    #   #   #           ####   #    #  #    #
          # #            ##  ##    # #           #    #  #    #  ##   #
        #######          # ## #     #            #    #  #    #  # #  #
          # #            #    #     #            #    #  # ## #  #  # #
         #   #           #    #     #            #    #  ##  ##  #   ##
                         #    #     #             ####   #    #  #    #

         #   #           #####   ######  #####    ####    ####   #    #
          # #            #    #  #       #    #  #       #    #  ##   #
        #######          #    #  #####   #    #   ####   #    #  # #  #  #####
          # #            #####   #       #####        #  #    #  #  # #
         #   #           #       #       #   #   #    #  #    #  #   ##
                         #       ######  #    #   ####    ####   #    #

         #   #             ##    #                ####    #####   #   #  #
          # #             #  #   #               #          #      # #   #
        #######          #    #  #                ####      #       #    #  E
          # #            ######  #                    #     #       #    #  
         #   #           #    #  #               #    #     #       #    #  
                         #    #  ######           ####      #       #    ######

         #   #            ####   ######          #####   #        ####    ####
          # #            #    #  #               #    #  #       #    #  #    #
        #######          #    #  #####           #####   #       #    #  #
          # #            #    #  #               #    #  #       #    #  #
         #   #           #    #  #               #    #  #       #    #  #    #
                          ####   #               #####   ######   ####    #### K

         #   #            ####    ####   #    #  #    #  ######  #    #   #####
          # #            #    #  #    #  ##  ##  ##  ##  #       ##   #     #
        #######          #       #    #  # ## #  # ## #  #####   # #  #     #
          # #            #       #    #  #    #  #    #  #       #  # #     #
         #   #           #    #  #    #  #    #  #    #  #       #   ##     #
                          ####    ####   #    #  #    #  ######  #    #     #

         #   #             ##    #       #####   ######    ##    #####    #   #
          # #             #  #   #       #    #  #        #  #   #    #    # #
        #######          #    #  #       #    #  #####   #    #  #    #     #
          # #            ######  #       #####   #       ######  #    #     #
         #   #           #    #  #       #   #   #       #    #  #    #     #
                         #    #  ######  #    #  ######  #    #  #####      # ,

         #   #            #####  #    #    ##    #    #  #    #   ####
          # #               #    #    #   #  #   ##   #  #   #   #
        #######             #    ######  #    #  # #  #  ####     ####
          # #               #    #    #  ######  #  # #  #  #         #
         #   #              #    #    #  #    #  #   ##  #   #   #    #
                            #    #    #  #    #  #    #  #    #   ####

                      #
         #   #       #
          # #       #
        #######    #
          # #     #
         #   #   #
               */



Sun, 30 Sep 2001 03:00:00 GMT  
 DoDont series I: comment style I

         /*                  ###
        #   #   #             #             #    #    ##    #    #  ######
       #     # #              #             #    #   #  #   #    #  #
      #    #######            #             ######  #    #  #    #  #####
     #       # #              #             #    #  ######  #    #  #
    #       #   #             #             #    #  #    #   #  #   #
   #                         ###            #    #  #    #    ##    ######
[...]

Cool.  Do you have that available as an extension to Emacs C-mode?
--
(supporter of the campaign for grumpiness where grumpiness is due in c.l.c)

Please: do not email me copies of your posts to comp.lang.c
        do not ask me C questions via email; post them instead



Sun, 30 Sep 2001 03:00:00 GMT  
 DoDont series I: comment style I
On Wed, 14 Apr 1999 18:31:42 GMT, Charles LaCour vouchsafed:

Quote:
>What is pleasant to one, is not pleasant to another.  Personally, I don't
>care which style most people use.  I have far more complaints about the
>placement of braces, spacing within statements, and using the tab character
>instead of spaces.  If I could get programmers to do one thing (related to
>style) it would be for them to turn off tab insertion as soon as they get a
>new text editor.  Better still, I would make the default for all text
>editors to insert spaces instead of tabs.  Also, pick and indentation scheme
>and stick with it.

Just out of curiosity, why is it that people are so dead-set against
tabs?

I use them in my code because when I'm inside four or so levels of
indentation, it's far easier for me to hit tab four times than to have
to either count out 32 (or 16, or 8, or whatever) spaces.  And I don't
have to change any default settings in vi[0] to do that, so it works on
any workstation I sit down at.

If the reason is the one I've heard before, about how tabs fsck up
printouts, I have issues with people who insist upon requiring printouts
of code, so I don't buy that one.

[0] Cue vi/emacs flame war[1]
[1] And codgerly rants about "when I was a young coder we used cat"[2].
[2] generally followed by "and liked it!".

--
Carl Jacobs - Software Engineer by title, SysAdmin by fait accompli,
ASR's Chief Bastard of Odd Religious Lore by acclamation.
Opinions expressed are not those of Raytheon Systems Company.
cjacobs at fallschurch.esys.com, darian at rtfm.netset.com (munged)



Sun, 30 Sep 2001 03:00:00 GMT  
 DoDont series I: comment style I
Tabs are really a pain.  Anyone that programs on multiple platforms with GUI
and non-GUI editors with proportional and non-proportional fonts will agree.
Even sending source code with tabs in it through e-mail will be screwed up
on most e-mail readers.  As for printing code, a code walkthrough meeting is
pretty tough without printouts.

A good editor will allow you to auto-indent and will use spaces instead of
tabs.  I can't tell you how many times I had to reformat a program that had
tabs in it.  I am sure that the code looked great to the programmer that
created it... but in my editor the tabstops and fonts are different.  It is
even worse when there is a mix of tabs and spaces.... then a global search
and replace fails.

--
****************************************
Richard Armstrong
State Of The Art Consulting, Inc.
http://www.stateoart.com
****************************************

Quote:
> On Wed, 14 Apr 1999 18:31:42 GMT, Charles LaCour vouchsafed:

> >What is pleasant to one, is not pleasant to another.  Personally, I don't
> >care which style most people use.  I have far more complaints about the
> >placement of braces, spacing within statements, and using the tab
character
> >instead of spaces.  If I could get programmers to do one thing (related
to
> >style) it would be for them to turn off tab insertion as soon as they get
a
> >new text editor.  Better still, I would make the default for all text
> >editors to insert spaces instead of tabs.  Also, pick and indentation
scheme
> >and stick with it.

> Just out of curiosity, why is it that people are so dead-set against
> tabs?

> I use them in my code because when I'm inside four or so levels of
> indentation, it's far easier for me to hit tab four times than to have
> to either count out 32 (or 16, or 8, or whatever) spaces.  And I don't
> have to change any default settings in vi[0] to do that, so it works on
> any workstation I sit down at.

> If the reason is the one I've heard before, about how tabs fsck up
> printouts, I have issues with people who insist upon requiring printouts
> of code, so I don't buy that one.

> [0] Cue vi/emacs flame war[1]
> [1] And codgerly rants about "when I was a young coder we used cat"[2].
> [2] generally followed by "and liked it!".

> --
> Carl Jacobs - Software Engineer by title, SysAdmin by fait accompli,
> ASR's Chief Bastard of Odd Religious Lore by acclamation.
> Opinions expressed are not those of Raytheon Systems Company.
> cjacobs at fallschurch.esys.com, darian at rtfm.netset.com (munged)



Sun, 30 Sep 2001 03:00:00 GMT  
 DoDont series I: comment style I
On Wed, 14 Apr 1999 15:33:18 -0600, Richard Armstrong vouchsafed:

Quote:
>Tabs are really a pain.  Anyone that programs on multiple platforms with GUI
>and non-GUI editors with proportional and non-proportional fonts will agree.
>Even sending source code with tabs in it through e-mail will be screwed up
>on most e-mail readers.  

I suppose I'll be labelled a fascist for this, but I refuse to feel
sorry for alignment problems anyone has, if they're using a proportional
font for code.

Yeah, yeah, ok, so I code exclusively in a vi session in an xterm.  Or
just at a text-only console.  Curmudgeonly, perhaps, but I find that I
put together tighter, more stable code that way than using GUI-based
we'll-sweat-the-details-for-you environments.

And I'm faster with vi and the O'Reilly books than most of my cow orkers
are with Builder Xcessory.  Also my programs compile, which can't always
be said for BX-generated stuff.

Quote:
>As for printing code, a code walkthrough meeting is
>pretty tough without printouts.

Walkthroughs.  You said the W word.  I have participated in walkthroughs
many times here at VBC, but I've never been at a code-level walkthrough
that was actually beneficial.  Design-level ones, sure, they're great,
but code-level ones too often devolve into "don't use the ternary
operator, because it's scary"-type {*filter*}ing.  YMMV, of course.  I *like*
the ternary operator, dammit!

Quote:
>A good editor will allow you to auto-indent and will use spaces instead of
>tabs.  I can't tell you how many times I had to reformat a program that had
>tabs in it.  I am sure that the code looked great to the programmer that
>created it... but in my editor the tabstops and fonts are different.  It is
>even worse when there is a mix of tabs and spaces.... then a global search
>and replace fails.

Autoindent rarely knows where *I* want things indented.  

My solution to this problem (since my company's coding style standards
and I don't quite see eye-to-eye) is that I code however the heck I feel
like coding, and when the thing is ready for others to see, I run it
though a nice little filter program which automagically indents things
the way they want them indented, and puts brackets where they want them,
and so forth.

Usually people complain more about my bizarre algorithms than they do
about my formatting, anyway.

I discourage visitors to my cube for this very reason.

--
Carl Jacobs - Software Engineer by title, SysAdmin by fait accompli
Opinions expressed are not those of Raytheon Systems Company.
cjacobs at fallschurch.esys.com, darian at rtfm.netset.com (munged)

   "You're not me.  Therefore you're irrelevant." -Dogbert



Sun, 30 Sep 2001 03:00:00 GMT  
 DoDont series I: comment style I

Quote:

>If I could get programmers to do one thing (related to
>style) it would be for them to turn off tab insertion as soon as they get a
>new text editor.

If you could get all programmers to agree on one thing, you'd deserve a
Nobel prize.


Sun, 30 Sep 2001 03:00:00 GMT  
 DoDont series I: comment style I
On Wed, 14 Apr 1999 23:00:52 +0100, Richard Heathfield vouchsafed:

Quote:

>>If I could get programmers to do one thing (related to
>>style) it would be for them to turn off tab insertion as soon as they get a
>>new text editor.

>If you could get all programmers to agree on one thing, you'd deserve a
>Nobel prize.

ObQuote:  "Managing programmers is like herding cats."

Unfortunately I don't have an attribution for it.

--
Carl Jacobs - Software Engineer by title, SysAdmin by fait accompli
Opinions expressed are not those of Raytheon Systems Company.
cjacobs at fallschurch.esys.com, darian at rtfm.netset.com (munged)
"Two rocks to bang together sucks less than Windows 95."
                    -Alan J Rosenthal in the Scary Devil Monastery



Sun, 30 Sep 2001 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. DoDont series 1: comment style I

2. DoDont Series 2 : #include, #define

3. DoDont Series 4 - semicolons

4. DoDont Series 3 : struct

5. Commenting style (was: Call for folklore)

6. javadoc style commenting for C code

7. Style comments for beginner

8. Commenting Styles

9. Request for comment; Re: Coding style

10. Commenting style

11. Comments wanted: iostream code style

12. A new C comment style

 

 
Powered by phpBB® Forum Software